WordPress Nginx
Indice NDT
(D)ifficulté : Simple, Moyenne, Complexe.
(T)emps estimé pour la réalisation.
| Utilisateur | Technicien | Expert |
| Simple | Moyenne | Complexe |
| – d’une heure | + de 5 heures | 12 heures et + |
OcM
Contexte de la réalisation.
Modalité de l’éxécution.
Face à l’absence de mises à jour des paquets Synology concernant WordPress et PHP, il est préférable de faire une installation manuelle lorsqu’on souhaite utiliser ce CMS sur un NAS Synology.
Objectifs du document, expliquer la marche à suivre pour ces 8 grandes étapes :
- Installer MariaDB et créer un utilisateur
- Installer WebStation & PHP version 7
- Installer WordPress version 5
- Créer le VirtualHost et les paramètres associés
- SSL associé pour le VirtualHost
- adapter les paramètres pour NGINX
- Gérer la base sous requêteur SQL [facultatif]
- Configurer WordPress et vérifier
- Questions Fréquentes
Prérequis
- disposer d’un NDD avec un certificat SSL (c’est plus pratique pour tout le monde)
- disposer de connaissances techniques tant en base de données (au moins les grands principes)
- disposer de compétences pour un accès en ligne de commande sur la NAS via SSH ou Telnet
- des routages idoines minimaux réalisés et autorisations FireWall
- un NAS Synology sous DSM6…
AVERTISSEMENTS
- Il est possible d’éviter ces manipulations et de passer par l‘installation des paquets officiels fournis par Synology. (WordPress, PHP5 et serveur Apache).
- Il n’y pas de modifications des règles de copyright et les mises à jour de de DSM demeurent opérationnelles sans engendrer d’anomalie remettant en cause le paramétrage manuel.
- Le support Synology est assuré y compris dans la mise en place manuelle décrite dans cet article.
Vous demeurez libres et responsables dans l’exécution de vos actions. Disponible pour tout support associé,
je ne suis pas responsable des effets de bord et des erreurs potentielles engendrés par vos actions sur vos données.
A – MariaDB et un jumeau de root
MariaDB est requis pour gérer un site web avec un CMS comme WordPress.
Il faut une base de données avec à minima un utilisateur admin de cette base.
Or,
- root n’accède à la base qu’à partir du NAS
Deux solutions possibles : le recours à l’interpréteur de commande Mysql de MariaDB ou l’utilisation du paquet PhpMyAdmin le temps de faire la création d’un utilisateur semblable à root qui pourra être sollicité via une machine du réseau local hors le NAS.(localhost).
Ici sont décrites les étapes à suivre via l’interpréteur de commande Mysql de MariaDB10
Les étapes
- après installation de MariaDB on spécifie le mot de passe de root
- accès en SSH ou Telnet au NAS et passage en root
- Interpréteur de commandes Mysql de MariaDB10
- création de la base de données et de l’utilisateur
- au delà… Via l’intérpréteur mysql en ligne de commande
Mot de passe MariaDB
Après installation du paquet MariaDB, en tant qu’admin sur le NAS on peut accéder à 3 fonctions via l’icône ajouté:
- Changement du mot de passe (de root)
- Réinitialisation du mot de passe (de root)
- Suppression des bases existantes (RAZ)
Le port d’adressage est le 3307 et le chemin socket : /run/mysqld/mysqld10.sock.
On coche la connexion TCP/IP.
Lors du premier paramétrage du profile PHP il faut préciser ces informations.
- Activer connexion distante Telnet ou SSH (Admin du NAS Panneau de configuration)
- Se connecter via Terminal ou Putty sur PC avec l’admin
- passer en root
Saisir à nouveau le mot de passe de l’utilisateur admin concerné.
Interpréteur de commande SQL MariaDB10
Saisir la ligne suivante en accès SSH/TELNET où :
- -u = utilisateur ici root
- -p invite, à la validation de la ligne, à saisir le mot de passe définit pour administration de MariaDB (cf étape 1)
Depuis la version DSM7 le chemin pour localiser le fichier server.webstation-vhost.conf est : /usr/local/etc/nginx/sites-enabled
Cela permet l’entrée dans l’interpréteur de commande Mysql de MariaDB10. (retour d’écran comme suit)
Comme indiqué, à de rares exceptions, toutes les commandes saisies dans cet interpréteur doivent se terminer par « ; »
Création de la base
Dans l’interpréteur de commande mysql de MariaDB saisir :
–> Créer la base BDmonsite
Création de l’administrateur de la base
Dans l’interpréteur de commande mysql de MariaDB saisir :
–> Créer l’utilisateur BDmonsite_admin autorisé à se connecter QUE depuis le NAS avec 123 comme mot de passe (à adapter..)
-
- depuis une ip fixe (locale ou externe)–>
CREATE USER ‘BDmonsite_admin’@‘192.168.1.100‘ IDENTIFIED BY ‘123’; - depuis un réseau local –>
CREATE USER ‘BDmonsite_admin’@‘192.168.1.%‘ IDENTIFIED BY ‘123’; - de n’importe où –>
CREATE USER ‘BDmonsite_admin’@‘%‘ IDENTIFIED BY ‘123’;
- depuis une ip fixe (locale ou externe)–>
Élévation des droits
Dans l’interpréteur de commande mysql de MariaDB saisir :
–> Donne TOUS les droits à mon utilisateur BDmonsite_admin depuis le NAS à la base de données BDmonsite.
On doit parfois forcer la mise à jour des droits en saisissant en sus cette commande :
Vérification
Dans l’interpréteur de commande mysql de MariaDB saisir :
–> Affiche les bases existantes :
Dans l’interpréteur de commande mysql de MariaDB saisir :
–> Affiche les utilisateurs existants :
Au delà
Différentes commandes SQL pour :
- SUPPRIMER une base : COPIER
- SUPPRIMER un utilisateur : COPIER
- Donner TOUS les droits à un utilisateur : COPIER
On peut aussi via l’interpréteur exporter ou importer une base de données. A voir ICI.
B – WebStation & PHP 7
Webstation
- Installation du paquet
- sitôt installé, un dossier web est créé (dossier réservé par le NAS) ainsi que le groupe http dans l’admin du NAS sans utilisateur.
- tout fichier déposé sur ce dossier peut être accessible en protocole http.
i.e. : un fichier test.txt peut être récupéré si on connait l’adresse NDD sur NAS et que les ports idoines sont routés. (80 443 selon protocole http/https)
https://NDD/test.txt
PHP 7
- Installation du paquet
- Une fois le virtualHost créé et MariaDB installés on adapte les paramètres du profil par défaut, cf § D VirtualHost onglet 3 PHP
C – WordPress
Comme on utilise pas le paquet WordPress fourni par Synology, il convient d’aller le récupérer chez l’éditeur.
- Le copier vers le dossier web
- Le décompresser
Si plusieurs sites WordPress prévus, alors penser à renommer le dossier WordPress par site (wp1 site 1 wp2 site 2…)
D – Créer le VirtualHost
WebStation et ses paramètres
Écran principal
- Statut : information générale sur les serveurs et services opérationnels
- Paramètres Généraux : les services par défaut serveur web et version de php
- Paramètres PHP ; le profil par défaut pour PHP
- Virtual Host : les hôtes créés
Paramètres Généraux
Les valeurs doivent être :
- Serveur NGINX
- PHP 7
Paramètres PHP
Le paramétrage du profil PHP
-
- On adapte le profil par défaut pour tous les hôtes
Sauf cas particulier pour un thème avancé si plusieurs sites WordPress, et dans ce cas il faut pour chaque hôte, spécifier le profile PHP utilisé.
Adaptation du profil PHP
Il faut préciser le port et le chemin de la pile utilisée par MariaDB.
-
- Paramètres PHP
- Modifier le profil par défaut
- Onglet coeur
- filtrer sur mysqli
- saisir les valeurs
- mysqli.default_port –> 3307
- mysqli.default_socket –> /run/mysqld/mysqld10.sock
Création
On précise 
- le nom d’hôte : le NDD du site
- les ports par défaut 80/443
- la racine du site : web/wordpress
- les paramètres HSTS et HTP/2 cochés
(compression du protocole https) - les profils retenus : NGINX & PHP
E – Mise en conformité du certificat
Lors de la création de l’hôte virtuel, le certificat par défaut du NAS est associé.
si le NDD du site est différent du NDD du NAS il faut associer le certificat SSL en conséquence.
- Admin du NAS
- panneau configuration
- sécurité
- onglet certificat
- Configurer
- associer site avec son certificat
i.e : mon nas est mondomaine.com, mon site web siteweb.mondomaine.com. Mon certificat mondomaine.com est associé à siteweb.mondomaine.com. Dans la sécurité je vais associer le bon certificat avec le bon domaine.
F – Adaptation des paramètres
Comme on n’utilise pas les paquets Synology et les scripts associés, il faut intervenir manuellement au cœur du NAS pour :
- régler les autorisations sur le dossier WordPress installé
- créer un fichier de configuration pour les permaliens
- localiser le dossier créé par Webstation pour le VirtualHost
- copier le fichier de configuration au bon endroit
- redémarrer le serveur NGINX
A – que le groupe http soit en lecture/écriture sur le dossier web
-
- Admin du NAS
- Panneau de configuration
- Groupe
- modifier http
- cocher lecture et écriture sur dossier web
B – que la propriété du dossier soit au groupe http
Possible via FileStation en rendant les permissions explicites sur le dossier et ses sous-dossiers… mais je préfère la commande en ligne
-
- Activer connexion distante Telnet ou SSH (Admin du NAS Panneau de configuration)
- Se connecter via Terminal ou Putty sur PC avec l’admin
- passer en root
si le dossier web est sur volume 1 (cas par défaut)
puis saisir la ligne suivante :
Le fichier
- de type texte sans extension format UTF-8
- nom : user.conf.wordpress-permalink
- contenu :
Conseil
Comme en cuisine, on le réserve pour plus tard.
On peut le déposer par exemple sur :
- home de l’admin dans un sous dossier a_garder ce qui partant du principe que les HOMES sont sur volume1 :
- /volume1/homes/admin/a_garder
Localiser le dossier VirtualHost :
- se connecter sur le NAS via Telnet ou SSH en tant qu’admin
- passer en root
- afficher les dernières ligne du paramètrage du Virtual Host (faire un CAT ou MORE si plusieurs hôtes virtuels présents)
- affiche ce genre de résultat :
Depuis la version 7.2 de DSM : chaque fichier de configuration du VirtualHost se trouve dans /usr/local/etc/nginx/sites-enabled.
Il convient de localiser le fichier de configuration associé qui lui se trouvera dans /user/local/etc/nginx/conf.d.
Ici plusieurs serveurs virtuels de présents.
Le début du fichier permet de repérer le VirtualHost concerné ou pas par un serveur wrodpress (selon votre configuration).
Puis à la fin de ce fichier le nom du fichier de configuration qui contient le paramètrage pour ce host.
se rendre dans ce dossier
Les fichiers de configuration pour les VirtualHosts sont cachés (début par .)
on retrouve entres autres :
On peut vérifier le contenu de la dernière ligne du fichier de configuration concerné
Le dossier étant créé on peut effectuer la copie comme indiqué plus bas.
Version DSM < à 7.2C’est une partie de la ligne 4 qui nous intéresse, elle représente le chemin de localisation pour y placer notre fichier de paramètre.
Dans cet exemple : usr/local/etc/nginx/conf.d/642225-dc68-6513-8d42-ed4428a5c2ba
Il faut noter, retenir, copier cette information pour se rendre dans ce dossier et y copier/créer le fichier.
- se déplacer dans le dossier identifié du Virtual Host
- utiliser le fichier mise en réserve ainsi :
La copie de ces blocs n’est pas possible car il s’agit d’exemples
- redémarrer le serveur NGINX
et voilà !
G – Gérer la base sous requêteur SQL [facultatif]
Le recours à un requeteur est facultatif puisqu’on peut accéder aux commandes SQL via l’interpréteur de commande MySQL de MariaDB en accès SSH/TELNET sur nos NAS. Cependant, c’est plus pratique et moins rugueux d’accès via ce type de logiciel.
Un logiciel requêteur est un outil avec interface graphique permettant d’accéder à une base de données à partir d’un ordinateur Windows/Linux/macOS.
Il offre la possibilité de faire des requêtes SQL et autres actions sur la base. Exemples pour Windows HeidiSql ou pour macOS Sequel Pro.
En l’absence de logiciel client SQL, la base et/ou les utilisateurs peuvent être créés avec l’interpréteur de commande Mysql de MariaDB via un accès SSH/TELNET ou via PhpMyAdmin…
Quelque soit la solution logicielle retenue, elle permet en général de :
- Créer un accès à la base de données
- Permettre un query, une interrogation en langage SQL pour créer une base et un utilisateur par exemple
- Bien d’autres possibilités selon les schémas de bases connus.
Via l’interface du logiciel, on initialise une connexion en précisant :
- l’adresse du NAS (ip locale ou ip publique ou NDD si accès externe)
- le port : 3307
- l’utilisateur autorisé
- son mot de passe
On utilise ici un utilisateur créé au préalable disposant d’une autorisation d’exécution hors localhost et des privilèges pour la ou les bases souhaitées.
Une fois connecté sur la base MariaDB on peut créer une base, un utilisateur etc.
Dans la commande suivante on créé une base et un utilisateur disposant des droits d’admin de cette base.
Créer la base mabase avec l’utilisateur toto et son mot de passe est 1 (-c’est pour l’exemple…)
Pour supprimer une base de données :
Le monde SQL est grand…
Exemple de requête permettant sur une base WordPress de supprimer les versions des publications historiées.
H – Configurer WordPress et vérifier
Via un navigateur internet saisir l’adresse web https://NDD, WordPress propose l’installation du site.
On y paramètre alors :
- Lien avec la base de données
- Site et administration
- Puis connexion en tant qu’admin
- On précise le nom de la base de données créée : mabase
- le nom de l’utilisateur créé pour cette base : toto
- son mot de passe : 1 (sic)
- on laisse le reste : localhost c’est sur le NAS que s’exécutent les actions
- préfixe : à changer en cas de multisites sur une même base
Identité du propriétaire du site web
La page de connexion au portail du site web maintenant installé
Vérifications
Au delà de l’accès au site web ainsi créé on vérifie que :
- on peut ajouter un article ou une page
- on peut changer les permaliens et toujours accéder au site
- on peut faire une réinstallation de wordpress par wordpress
Ajouter un article
- Menu Article
- Choix Ajouter
- Saisir un titre
- Saisir un contenu
- Publier
Changer les permaliens
- Réglages
- choisir Permaliens
- par défaut ils sont sur le numéro de l’article, le but est de les changer pour vérifier que notre fichier permalink fait son job
Il suffit d’en choisir un dans les propositions faites.
Mise à jour de WordPress
- Tableau de bord
- Mise à jour
- Réinstaller WordPress
Vérifier que les droits sur le dossier WordPress de web sont fonctionnels pour ce genre d’opération qui doit être automatique.
Idem pour l’installation d’extensions et/ou de thèmes
FAQ
Les principales/pertinentes questions/réponses suscitées par cet article.
Par défaut tous les modules PHP peuvent être activés. Or au delà du fait que certains ne sont pas requis pour un site sous WordPress, ils représentent une charge machine inutile et un potentiel risque en cas de brèche sur l’un des modules.
Pour disposer des modules à minima pour un site sous WordPres (or extension qui nécessiterait une routine associée à l’un de ses modules désactivé), il suffit de modifier le profil par défaut ou à défaut… Celui associé pour le site virtuel créé pour WordPress.
- Accès à DSM via un utilisateur disposant des autorisations
- WebStation
- Paramètres PHP
- Modifier
On ne laisse cocher que les modules suivants :
Cela permet un gain notable pour l’accès au site web sous WordPress hébergé sur le NAS.
Un logiciel requêteur est un outil avec interface graphique permettant d’accéder à une base de données à partir d’un ordinateur Windows/Linux/macOS.
Il offre la possibilité de faire des requêtes SQL et autres actions sur la base. Exemples pour Windows HeidiSql ou pour macOS Sequel Pro.
Chaque saisie en ligne de commande sous MariaDB amène un retour du type :
Query OK, 0 rows affected (0.001 sec)
En cas d’erreur de saisie on peut perdre le prompte (MariaDB [(none)]>) et se retrouver comme suit (exemple avec un oubli de ; en fin de ligne)
MariaDB [(none)]> select user,host from mysql.user
->
CTRL + C permet de sortir de l’interpréteur de commande MariaDB et revenir à la ligne de commande Telnet/SSH linux du NAS.
Une erreur fréquente en ligne de commande Mysql de MariaDB est d’oublier le commutateur -u et d’accéder malgré tout à l’interpréteur de commande…
Exemple :
la syntaxe précise pour accéder à l’ensemble des bases en tant que root est la suivante :
Sauvegarde de MariaDB
Il est conseillé d’utiliser HyperBackup de Synology pour sauvegarder la base de données MariaDB.
Démarche
Pour le dossier web et son/ses dossier(s) WordPress ainsi que les bases de données associés.
- Hyperbackup
- +
- choisir une destination disque mono-version
- destination :dossier d’un disque/volume local ou USB
- Sauvegarde de fichiers : on pointe le dossier web
- En application : on sélectionne MariaDB
A noter que toutes les bases sont ainsi sauvegardées. On ne peut restaurer que l’ensemble et pas une base associée à un site.
Dans le cas d’une utilisation d’un CMS comme WordPress par exemple, il faut procéder à un dump de la base de données (SQL) ou utiliser des outils tiers intégrables à WordPress comme BackWPuP
L’accès SSH permet un accès sécurisé aux arcanes d’un système. L’ensemble de la connexion est chiffrée. Ce protocole requiert le partage d’une clé publique et une clé privé (ie la machine doit être connue du système hôte).
Selon le logiciel utilisé, la première connexion est plus ou moins simplifiée. Sur macOs avec Terminal ou sous Windows avec Putty, la première connexion atteste d’un enregistrement d’autorisation. Sitôt fait chaque connexion par la suite se réalise simplement (saisie du mot de passe de l’admin).
Via Telnet l’accès est non chiffré et plus basique. Un logiciel de connexion TTY classique (Terminal sur macOS jusqu’à macOS Sierra) Putty sur PC – voir Telnet en ligne de commande sous Windows -.
Quelque soit le protocole utilisé
- Il faut éviter de le laisser ouvert en permanence sauf utilisation courante requise.
- Ne pas router vers l’extérieur le port concerné (22) – sauf si requis selon l’utilisation de chacun
Personnellement je n’utilise pas de service RSYNC ou autre FTPS qui requiert le routage du port SSH 22. Mon accès demeure uniquement local et ponctuel (je désactive l’accès sitôt les actions faites).
A noter depuis Windows 10 version 1709, un accès ssh est possible, directement en ligne de commande. ( cf article lié )
Il est possible de procéder ainsi pour installer plusieurs sessions WordPress sur nos NAS (différent d’une installation multi-sites WordPress). dans cette optique on isole les processus, les NDD, et les données.
L’isolation de chaque est garantie par :
- un sous domaine du NDD (avec son certificat SSL)
- un dossier WordPress sur le dossier web (attention à bien les nommer et les ponter dans WebStation – site1 wp1 site2 wp2 etc…)
- une base par site
Un des intérêts que je trouve à cette technique, au delà de cloisonner des sites web clients, est de pouvoir à loisirs faire des tests, notamment dans l’utilisation de plugins ou de thèmes sophistiqués (DIVI AVADA etc..). Bref cela permet d’imaginer un environnement de PROD, de FORMATION, de TEST etc…
Ce genre d’installation répétée n’est souvent pas possible chez les hébergeurs qui ne proposent qu’une instance WordPress…
C’est un des atouts d’avoir un NAS perso !
Merci à Oliv66 pour le REX associé.
Le dossier homes sur un NAS Synology contient le home de chaque utilisateur du NAS. Sauf à se connecter avec un utilisateur du groupe Administrator (ou d’en avoir expressément ajouter les droits), un utilisateur ne voit QUE son home et jamais le dossier homes contenant les dossiers des autres utilisateurs.
L’exécution d’un script « maison » est réalisée avec des droits d’administrateurs. (dans le planificateur des tâches).
C’est pourquoi, sauf sur site distant, pointer un dossier home d’un utilisateur dans le fichier de paramètrage, param.txt, doit être écrit en tenant compte de l’arborescence complète.
Pour le paramètrage en local, la syntaxe « arborescence complète » se présente ainsi :
→ Exemple local : utilisateur toto son home en local est sur le /volumex(x=1 à n selon le nombre de volume présent)/homes/toto.
Dans le cadre de SyncDoss, la connexion au site distant ne se réalise pas avec les mêmes prérogatives (et c’est normal).
→ Exemple distant : pour mon utilisateur toto son home en local sur le site distant est sur le /home/toto.
Cette fois-ci , je me connecte en tant que toto, mon home dans le fichier de paramétrage, param.txt, est à écrire avec l’arborescence simplifiée.
Pour pouvoir modifier un fichier texte directement depuis File Station sous DSM sur un NAS Synology, il faut ajouter le paquet Editeur de Texte (section utilitaire dans l’ajout des paquets).
Par la suite sous File Station, bouton droit sur un fichier texte permet son ouverture pour modification.
Pratique on peut ajouter les n° des lignes et ainsi mieux gérer les modifications dans le fichier de paramètrage.
Attention à la page de code (en général il faut une page de code UTF-8).
Dans le fichier de paramètrage on doit renseigner les chemins complets selon les volumes existants sur le NAS. Ainsi un dossier cargo dans le dossier partagé web est en fait : /volume_n (où est n est le numéro du volume)/web/cargo.
A partir de FileStation on obtient dans les propriétés du dossier ce chemin complet comme sur l’image à gauche.
Le script ne réalise pas de changement sur les éléments constituant l’environnement logiciel du NAS Synology. Il automatise une action qui peut être faite manuellement par l’utilisateur.
En conséquence, le script ne représente ni un risque de sécurité ni une atteinte aux éléments techniques et juridiques du NAS.
Un shell est un programme qui fait office d’interface entre vous et l’ordinateur sous la forme d’un interpréteur de commandes.
Le Shell est le programme qui fait office entre nous et l’ordinateur. C’est l’intrèpréteur de commandes de base sous le système d’exploitation. Sous linux/Unix il en existe plusieurs :
- Almquist shell (ash) : écrit en remplacement du Bourne Shell, sous licence BSD ; souvent utilisé dans des environnements aux ressources limitées. Les sh de FreeBSD, NetBSD (et leurs dérivés) sont basés sur des cendres qui ont été améliorées pour être conformes à POSIX. (présent sur le NAS Synology)
- Bourne Shell (sh) : Le shell Bourne était le shell par défaut de la version 7 d’Unix. De nombreux systèmes de type Unix continuent à avoir /bin/sh – qui est l’interpréteur de commandes Bourne, ou un lien (symbolique ou en dur) vers un interpréteur de commandes compatible. (par défaut sur le NAS Synology)
- Bourne-Again shell (bash) : écrit dans le cadre du projet GNU pour fournir un sur-ensemble de fonctionnalités du Bourne Shell. Ce shell est souvent pré-installé et est le shell interactif par défaut pour les utilisateurs sur la plupart des systèmes Linux et macOS (jusqu’à Catalina macOS 10.15)
- C shell (csh) : Shell Unix créée par Bill Joy alors qu’il était étudiant à l’Université de Californie, Berkeley, à la fin des années 1970. Il a été largement distribué, à commencer par la version 2BSD de la Berkeley Software Distribution (BSD) pour la première fois en 1978.
- Debian Almquist shell (dash) : un remplacement moderne du shell ash dans Debian et Ubuntu
- Korn shell (ksh) : écrit par David Korn à partir des sources du shell Bourne alors qu’il travaillait aux Bell Labs
- Public domain Korn shell (pdksh) : Shell Unix qui a été développé par David Korn aux Bell Labs au début des années 1980 et annoncé sur USENIX le 14 juillet 1983. Le développement initial était basé sur le code source du shell Bourne.
- MirBSD Korn shell (mksh): un descendant du ksh d’OpenBSD et de pdksh, développé dans le cadre de MirOS BSD
- TENEX Shell (tcsh): Shell Unix basé sur et compatible avec csh. Il s’agit essentiellement d’un interpréteur de commandes C avec une complétion en ligne de commande programmable, une édition en ligne de commande et quelques autres fonctionnalités. Il s’agit de l’interpréteur de commandes racine natif pour les systèmes basés sur BSD comme FreeBSD.
- Z shell (zsh): une coquille relativement moderne qui est rétrocompatible avec le bash. C’est le shell par défaut dans macOS depuis la version 10.15 de Catalina . Présent aussi sur le NAs Synology DSM6.
Quel shell ai-je par défaut ?
D’autres SHELL présents ?
Changer le shell par défaut ?
Sortir du mode Terminal et se reconnecter pour constater que désormais c’est ce shell qui est appliqué par défaut.
Bravo !
Tout est dit et clairement documenté.
J’ai suivi à la lettre sans trébucher et mieux, je crois que j’ai compris ce que faisais et pourquoi il fallait le faire.
Content d’y être parvenu.
Merci.
Bonjour,
content que cela soit utile et compréhensible.
Merci
Je suis tombé sur ce site en allant sur le forum de Synology, super pour le moment tout fonctionne correctement (j’ai pas fini le tuto)
Dans le tutoriel il est fait mention de php 7 mais sans précisé car dans le centre de paquet j’ai le choix entre php 7 et php 7.2
Y’a une importance ? La logique voudrait de prendre le plus récent mais on sait jamais
Bonjour,
Merci.
A ce jour (03/2019) malgré la dernière MAJ de WebStation de la part de Synology, PHP 7.2 n’est pas totalement opérationnel. Cela peut fonctionner mais le lien avec la fonction phpmail est KO..; du coup adieu commentaire (enfin, l’alerte par mail d’un ajout de commentaire pour être précis) ou envoi de formulaire (toujours par mail). Donc pour l’heure PHP7.0Correctifs apportés avec la version 2.1-0148 de WebStation, PHP 7.3 bien géré, mail envoyé par php opérationnel !