window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-110469859-1');
WordPress Nginx

Indice NDT

(N)iveau requis, de l’utilisateur à l’expert.
(D)ifficulté : Simple, Moyenne, Complexe.
(T)emps estimé pour la réalisation.

Utilisateur Technicien Expert
Niveau
Simple Moyenne Complexe
Difficulté
– d’une heure + de 5 heures 12 heures et +
Temps

OcM

Objectif de l’article.
Contexte de la réalisation.
Modalité de l’éxécution.

Site web avec WordPress et PHP à jour.

Comme les paquets DSM6 sont trop anciens, on réalise une installation manuelle.

Marche à suivre

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 :



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

  1. après installation de MariaDB on spécifie le mot de passe de root
  2. accès en SSH ou Telnet au NAS et passage en root
  3. Interpréteur de commandes Mysql de MariaDB10
  4. création de la base de données et de l’utilisateur
  5. 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é:

  1. Changement du mot de passe (de root)
  2. Réinitialisation du mot de passe (de root)
  3. 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.

  1. Activer connexion distante Telnet ou SSH (Admin du NAS Panneau de configuration)
  2. Se connecter via Terminal ou Putty sur PC avec l’admin
  3. passer en root

COPIER

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 :

COPIER

–> Créer la base BDmonsite

Création de l’administrateur de la base


Dans l’interpréteur de commande mysql de MariaDB saisir :

COPIER

–> Créer l’utilisateur BDmonsite_admin autorisé à se connecter QUE depuis le NAS avec 123 comme mot de passe (à adapter..)

A noter : on peut créer un utilisateur, permettant un accès depuis une machine autre que le NAS (Mac ou Pc avec requeteur SQL par exemple) ou quelque soit son origine :

    • 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’;

Élévation des droits


Dans l’interpréteur de commande mysql de MariaDB saisir :

COPIER

–> 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 :

COPIER

Vérification


Dans l’interpréteur de commande mysql de MariaDB saisir :

COPIER

–> Affiche les bases existantes :

Dans l’interpréteur de commande mysql de MariaDB saisir :

COPIER

–> 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.

    1. Paramètres PHP
    2. Modifier le profil par défaut
    3. Onglet coeur
    4. filtrer sur mysqli
    5. 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.

  1. Admin du NAS
  2. panneau configuration
  3. sécurité
  4. onglet certificat
  5. Configurer
  6. 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 :

  1. régler les autorisations sur le dossier WordPress installé
  2. créer un fichier de configuration pour les permaliens
  3. localiser le dossier créé par Webstation pour le VirtualHost
  4. copier le fichier de configuration au bon endroit
  5. redémarrer le serveur NGINX
Pour que WordPress puisse correctement faire les mises à jour sans nécessiter un accès ftp ou ssh il faut :

A – que le groupe http soit en lecture/écriture sur le dossier web

    1. Admin du NAS
    2. Panneau de configuration
    3. Groupe
    4. modifier http
    5. 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

    1. Activer connexion distante Telnet ou SSH (Admin du NAS Panneau de configuration)
    2. Se connecter via Terminal ou Putty sur PC avec l’admin
    3. passer en root

COPIER

si le dossier web est sur volume 1 (cas par défaut)

COPIER

puis saisir la ligne suivante :

COPIER
Afin que WordPress et NGINX cohabitent bien notamment pour la gestion des permaliens et des redirections (404 par exemple), il faut ajouter un fichier dans le dossier créé par le NAS lors de la création du Virtual Host.

Le fichier

  • de type texte sans extension format UTF-8
  • nom : user.conf.wordpress-permalink
  • contenu :
COPIER

Conseil

Isoler le fichier sur le NAS

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 :

  1. se connecter sur le NAS via Telnet ou SSH en tant qu’admin
  2. passer en root
Depuis la version DSM7 le chemin pour localiser le fichier server.webstation-vhost.conf est : /usr/local/etc/nginx/sites-enabled
COPIER
  1. afficher les dernières ligne du paramètrage du Virtual Host (faire un CAT ou MORE si plusieurs hôtes virtuels présents)
COPIER
  1. 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 :

Copy to Clipboard

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.2

C’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.

  1. se déplacer dans le dossier identifié du Virtual Host
  1. utiliser le fichier mise en réserve ainsi  :

La copie de ces blocs n’est pas possible car il s’agit d’exemples

  1. redémarrer le serveur NGINX
COPIER

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.

COPIER

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 :

COPIER

Le monde SQL est grand…
Exemple de requête permettant sur une base WordPress de supprimer les versions des publications historiées.

COPIER

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 :

  1. Lien avec la base de données
  2. Site et administration
  3. Puis connexion en tant qu’admin

Vérifications

Au delà de l’accès au site web ainsi créé on vérifie que :

  1. on peut ajouter un article ou une page
  2. on peut changer les permaliens et toujours accéder au site
  3. on peut faire une réinstallation de wordpress par wordpress

Ajouter un article

  1. Menu Article
  2. Choix Ajouter
  3. Saisir un titre
  4. Saisir un contenu
  5. Publier

Changer les permaliens

  1. Réglages
  2. choisir Permaliens
  3. 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

  1. Tableau de bord
  2. Mise à jour
  3. 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.

Modules PHP pour WordPress2021-01-11T18:38:37+01:00

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.

  1. Accès à DSM via un utilisateur disposant des autorisations
  2. WebStation
  3. Paramètres PHP
  4. Modifier
    On ne laisse cocher que les modules suivants :
  • curl
    Protocole requis pour la récupération de données en http par exemple

  • exif
    Capacité à intégrer les méta data des images/photos (données exif telles que l’ouverture, la date de prise de vue, l lieu etc..)

  • ftp
    Protocole client pour récupérer des versions de WordPress/Modules/Thèmes sur serveurs FTP

  • iconv
    Permettre la bonne gestion des caractères unicodes (emojii et autres)

  • imagick
    (dispo depuis la version PHP 7.4 et WebStation 2.1.9) – Module permettant la bonne gestion des transformations d’images ( exemple lors d’une intégration d’une image, WP et/ou le thème peut redimensionner les images)

  • GD
    module permettant la gestion des images JPEG,GIF, BMP, JPG (création taille etc..) — Non requis pour un site WP simple mais dépend du thème ou requis pour un site Web autre utilisant une bibliothèque type HTML2PDF.

  • mysqli
    Requis pour l’accès à une base de données Mysql/MariaDB et autres Mysql Forks

  • openssl
    Implémentation de la couche réseau permettant une bonne gestion des échanges chiffrées en SSL

  • PDO_mysql
    pilote qui implémente l’interface PHP Data Object (PDO) pour un autre site web que WordPress accédant à une base de données MySql/MariaDB.

  • zip
    (dispo depuis la version PHP 7.4 et WebStation 2.1.9) – Module gérant les fichiers d’archives (ZIP) – requis pour les récupération de module/thèmes etc..

  • Zlib
    Module gérant les fichiers d’archives Gzip – requis pour une utilisation avec certains thèmes/extensions (Elementor Builder pour le thème DIVI par exemple)

Cela permet un gain notable pour l’accès au site web sous WordPress hébergé sur le NAS.

Requeteur SQL2020-02-24T16:40:29+01:00

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.

Sortir en cas d’erreur2020-02-24T16:35:54+01:00

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.

Ignoring query to other database2020-02-24T16:27:34+01:00

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 :

COPIER

Sauvegarde MariaDB2020-02-24T16:27:46+01:00

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.

  1. Hyperbackup
  2. +
  3. choisir une destination disque mono-version
  1. destination :dossier d’un disque/volume local ou USB
  1. Sauvegarde de fichiers : on pointe le dossier web
  1. 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

Accès SSH2021-01-05T10:34:59+01:00

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é )

Plusieurs WordPress2019-03-04T15:52:05+01:00

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é.

un homes des home ?2020-03-10T18:56:26+01:00

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.

Modifier un fichier texte avec le NAS2020-03-10T15:58:10+01:00

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).

Obtenir le chemin complet2020-03-10T19:00:17+01:00

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.

Autorisation de Synology2020-03-10T15:58:41+01:00

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.

Shell Linux2020-03-10T15:57:52+01:00

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 ?


COPIER

D’autres SHELL présents ?


COPIER

Changer le shell par défaut ?


COPIER

Sortir du mode Terminal et se reconnecter pour constater que désormais c’est ce shell qui est appliqué par défaut.

2023-08-04T10:47:33+02:0001 Mar 2019|Archives, Archives 2019, SYNO|

Envie de partager cet article ...

4 Commentaires

  1. Coriolys 22 mars 2019 à 8 h 59 min

    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.

    • Daffy 22 mars 2019 à 10 h 11 min

      Bonjour,
      content que cela soit utile et compréhensible.
      Merci

  2. Rinchama 22 mars 2019 à 17 h 49 min

    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

    • Daffy 23 mars 2019 à 0 h 10 min

      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.0

      Correctifs apportés avec la version 2.1-0148 de WebStation, PHP 7.3 bien géré, mail envoyé par php opérationnel !

Les commentaires sont fermés.

Aller en haut