Installer WordPress sur Synology (DSM 5 – DSM 6)

Synology : hébergement multi-sites

Installer WordPress sur Synology

Les billets précédents nous ont montrés comment installer WordPress sur Synology de façon standard : ce que je ne conseille pas ! L’expérience m’a prouvée qu’il était bien plus agréable d’installer soit même WordPress et d’avoir pleinement la main sur sa configuration et les mises à jour. Nous allons configurer notre NAS pour qu’il puisse gérer autant de sites que l’on souhaite.

L’objectif de ce billet sera donc d’ajouter un site WordPress, dans le répertoire désiré et accessible via un domaine ou sous-domaine de notre choix. De plus, vous aurez les mises à jour automatiques (ou pas) d’activées grâce au FTP.

Pour une configuration de plusieurs sites : répétez cette manipulation autant de fois que vous avez de sites à mettre en place.

Prérequis

Nous supposons que vous disposez déjà de votre domaine et que vos sous-domaines pointent vers votre NAS. Votre routeur est déjà configuré pour la redirection des ports 80 et 443. Vous avez déjà MariaDB et PhpMyAdmin d’installés. Vous disposez d’une connexion SSH à votre NAS. Vous avez un minimum de connaissances sur le fonctionnement des virtual hosts.

MariaDB - Installer WordPress sur Synology

PhpMyAdmin - Installer WordPress sur Synology

Installer WordPress sur Synology

Commencez par créer l’arborescence de votre choix dans le dossier partagé /web prévu à cet effet. Pour cet exemple, nous allons créer un répertoire /web/dev. Vous pouvez faire toutes les actions depuis l’IHM, plus besoin de la console/ssh avec la version 6 de DSM ! Force est de constater que bidouiller les droits en mode console peut cassé l’héritage des droits gérés nativement via les IHM.

Vous devez télécharger WordPress et décompresser l’archive dans le répertoire /web/dev. Le document root de notre site devient donc /web/dev/wordpress. Modifiez les permissions du dossier /web/dev en fonction de vos besoins, voici un exemple de configuration :

  • le owner en admin, seul lui possède tous les droits
  • le groupe http en lecture, c’est impératif
  • le groupe users en lecture (nécessaire au moment de la configuration du document root dans l’IHM de gestion des vhosts)
  • cocher les deux cases à cocher pour que la sous-arborescence dispose des mêmes droits

Ce qu’il faut retenir c’est que le groupe http doit avoir les droits en lecture pour que votre site fonctionne correctement, pour des raisons de sécurité il vaut mieux en revanche ne pas lui donner les droits en écriture, sauf cas particuliers :

  • le dossier upload doit-être accessible en écriture pour des raisons évidentes
  • d’autres dossiers peuvent avoir la nécessité de laisser le groupe HTTP en écriture, par exemple pour l’écriture de logs dans le cadre du plugins UpDraftPlus.

Créer une BDD et un utilisateur

Comme indiqué sur le site de WordPress, vous devez maintenant créer une base de données et un utilisateur pour votre futur site. Cet utilisateur sera notamment utilisé pour créer les tables internes nécessaires au fonctionnement du CMS, dans la base de données indiquée.

PhpMyAdmin (package Synology) permet d’effectuer ces actions très rapidement :

  • Créez une nouvelle base de données
  • Cliquez dessus dans l’arborescence à gauche, puis sur privilèges dans le menu en haut
  • Cliquez sur Ajouter un utilisateur (le fait d’avoir sélectionnée la base juste avant fait que nous n’avons aucune option à modifier, l’utilisateur aura les droits d’actions uniquement les droits nécessaires, sur la base en question)

Configurer votre serveur HTTP

Depuis la version DSM 6, la configuration (icône WebStation) vous offre la possibilité de choisir entre Apache et Nginx. Si vous hésitez : prenez Nginx ! Il est toujours préférable de suivre les recommandations et outils conseillés par l’éditeur d’une plateforme. De plus Nginx est plus performant et surtout moins gourmand en mémoire. Enfin, il faut savoir que de toute façon Synology utilise Nginx comme serveur HTTP principal et la cohabitation des deux peut amener quelques difficultés supplémentaires de configuration (non abordées dans cet article).

Création d’un dossier partagé de configuration

Cette partie est optionnelle. L’idée ici est de disposer d’un répertoire partagé etc qui rassemble les quelques config système gérer par nos soins, notamment les virtual hosts. Cela permet notamment de se prémunir d’éventuels changements de config de Syno et le cas échéant de simplement mettre à jour des liens symboliques.

Si vous n’êtes pas à l’aise avec l’éditeur en mode console (vi), cette configuration vous permettra d’éditer vos fichiers directement via votre poste personnel avec l’éditeur de texte de votre choix 🙂

La création d’un répertoire partagé ce fait depuis l’IHM : Panneau de configuration > Dossier partagé > créé (droits r/w admin).

Une fois cela fait, vous pouvez créer vos répertoires et fichiers (sudo -i pour passer root) :

$whoami
root
$mkdir /volume1/etc/vhost
$touch /volume1/etc/vhost/thorpora.conf
$cd /etc/nginx/sites-enabled           # ou /etc/httpd/sites-enabled si vous utilisez Apache
$ln -s /volume1/etc/vhost/thorpora.conf
$ls -l
thorpora.conf -> /volume1/etc/vhost/thorpora.conf

Voila, notre vhost est créé et sera automatiquement chargé par Nginx, il ne reste plus qu’à le mettre à jour !

Virtual host avec Nginx (DSM 6)

Avec l’arrivée de la version 6, la création des virtual hosts est devenue triviale : l’interface de Web Station le permet de façon intuitive n’est toujours pas suffisante et il est préférable de ne pas l’utiliser. Précédemment dans cet article je préconisais de générer les vhosts depuis l’IHM puis de modifier manuellement le fichier des vhosts gérés par Synology : /etc/nginx/app.d/server.webstation-vhost.conf. En réalité ce n’est pas une bonne pratique puisque Synology est susceptible de régénérer ce fichier et même sans aucune action humaine ! La solution est donc de ne plus utiliser ce fichier mais simplement d’ajouter un vhost dans le répertoire initialement fait pour cela : /etc/nginx/sites-enabled.

Mise à jour du vhost thorpora.conf :

La configuration SSL requise par notre vhost est héritée par celle déjà existante dans le fichier de configuration principal : /etc/nginx/nginx.conf. Si vous disposez de vos propres certificats vous pouvez mettre à jour les deux lignes commentées. Cet autre article explique comment générer ces fichiers. Autrement, vous aurez l’alerte classique de sécurité du navigateur, par très sympa pour vos internautes 🙂

Un rechargement de Nginx est nécessaire : nginx -s reload

Virtual host avec Apache (DSM 5)

Cette section est ancienne et a été écrite pour DSM 5, je ne garantie pas qu’elle soit correcte avec un système DSM 6 + Apache.

Pour cet exemple, l’objectif sera d’accéder à thorpora.fr. Pensez également à modifier le DocumentRoot en fonction de votre arborescence.
Mettre à jour /etc/httpd/sites-enabled-user :

Mettre à jour /etc/httpd/sites-enabled-user/httpd-ssl-vhost.conf-user :

Redémarrer Apache :  httpd -k restart

Configuration du site

Vous pouvez dès à présent vous connecter à votre domaine ou sous-domaine, thorpora.fr pour cet exemple, afin d’effectuer la dernière étape de configuration de votre site web, suivez simplement les instructions WordPress !

Configuration du FTP

Prérequis : vous avez déjà configuré votre serveur FTP sur votre NAS.

Afin de faciliter l’ajout d’extensions WordPress et des mises à jour automatiques, il est pratique de configurer le FTP directement dans WordPress.

La première étape consiste à créer un utilisateur spécial multi-sites (ou un par site) qui sera utilisé par vos blogs pour les connexions FTP. Pour ce faire, ajouter simplement un nouvel utilisateur dans le panneau de configuration avec les permissions minimales dont nous avons besoin :

  • Permissions : lecture+écriture sur le dossier web (ou plus précisément, sur un sous répertoire)
  • Autorisation d’application : FTP

Editez ensuite le fichier /web/dev/wordpress/wp-config.php pour ajouter :

Les lignes 2 et 3 ne sont pas nécessaire si vous conservez une arborescence type. Vous trouverez plus d’informations sur cette configuration sur le codex de WordPress. En plus de mettre à jour les informations sur l’utilisateur et des chemins, pensez également à mettre à jour le port de votre serveur FTP.

Je vous conseille de vérifiez l’acces en lecture/écriture avec un client FTP classique dans un premier temps. En effet, sur la version DSM 5 j’ai constaté parfois quelques difficultés à gérer les droits correctement. La version 6 est meilleure à ce niveau et évite les bidouilles en mode console. Personnellement j’ai ajouté les droits r/w de l’utilisateur FTP via le panneau de propriétés du dossier racine du site (pensez bien à cocher les 2 cases à cocher pour transmettre les droits à sous arborescence).

C’est tout pour l’essentiel ! Finalement installer WordPress sur Synology est devenu vraiment simple et la portée de tous. Encore une fois, je vous déconseille vivement d’utiliser la version packagée avec Synology, potentiellement source de problèmes comme en témoigne cet autre article.

Vous pouvez donc tester et recommencer la manipulation autant de fois que vous avez de domaine ou sous domaine.

HF & GL

13 réponses

  1. Cedric dit :

    Ca a l’air simple et plutôt pas mal fait comme NAS 🙂
    Bon article en tout cas ! Et comme toujours c’est complet et bien expliqué.
    On essaie de se boire une biere ce week end ?

  2. lol oué ça change d’une Debian unstable ^^
    Avec plaisir pour la bière ce week end 🙂

  3. Matt dit :

    merci pour cet article, et cool d’avoir fait la distinction DSM 5/6 c’est bien pratique !

  4. lericain dit :

    Merci encore pour ces infos sur les vhost… j’avais fait la modif comme décrit initialement via l’IHM puis la modif dans le fichier qui va bien, mais je me suis bien rendu compte malgré moi que ce n’était pas durable, vu que qq jours plus tard des erreurs 404 sont apparues… bon vu que j’avais tenté un passage du blog en https (via modif des liens dans la base de données) entre temps, j’avais pas réalisé que mon fichier de config avait été ‘réinitialisé’ sans manip de ma part (merci syno !). Du coup retour sur ton blog et j’ai trouvé la solution.
    Au passage je suis un peu irrité par ce passage à DSM6 + nginx, c’est un peu chaotique mais heureusement qu’il y a des personnes comme toi qui s’y connaissent bien et surtout qui partagent les solutions!
    Retour à mon sujet initial, passage du blog en full https: là j’ai rajouté les lignes suivantes dans mon fichier de config vhost:
    if ($scheme = http) {
    return 301 https://$server_name$request_uri;
    }
    est-ce la bonne méthode? d’après ce que j’ai vu il y a plusieurs façon de le faire, mais n’étant pas un spécialiste des réseaux, je m’y perds un peu !

    • Salut et merci pour ton commentaire 🙂 Oui ta solution devrait très bien marcher ! Je ne suis pas non plus ‘expert’ mais je pense que le puristes tenteront de limiter l’ajout de clauses conditionnelles dans les fichiers de config, plus il y en a moins c’est moins lisible. Tu peux aussi faire 2 sections dans ton même fichier vhost, une pour le http et l’autre pour le https (stackoverflow).

  5. Sébr dit :

    Bonjour,
    J’ai suivi ton tuto pour le problème de DMS 6 et wordpress mais j’ai eu une chose « bizarre » en effet après avoir ajouter mon fichier .conf dans le dossier sites-enabled mon Nas et passé en alerte orange avec comme message « Votre nas ne pourra plus redémarrer normalement contacter le support ». Là panique, et si je veux créer un vhost par l’IHM echec. En supprimant le .conf c’est résolu.
    Ma question et es que cela peut être du au fait que j’ai laissé les vhost dans l’IHM, dois-je supprimer les vhost avant de faire à ta façon ?

    J’ai du mal à suivre ton tuto, car à un moment tu dis qu’il faut créer son vhost dans « /volume1/etc/vhost/thorpora.conf » et après de le mettre dans « /etc/nginx/sites-enabled » il faut le mettre à 2 endroits ?

    Merci pour ton tuto et ton éclaircissement.
    Merci

  6. Salut, étrange ton affaire !
    Concernant le répertoire sites-enabled, il faut que tu comprennes ce que signifie la commande « ln -s » 🙂 Les vhost doivent bien se situer dans le répertoire sites-enabled, mais tu peux les mettre ailleurs et simplement faire un lien symbolique (un raccourcis en gros) dans le répertoire sites-enabled. Il y a bien des fichiers au final dans sites-enabled, mais ce sont juste des raccourcis.
    Pour ton alerte orange je n’ai jamais eu ça, essaie dans un premier temps :
    – de faire un fichier vide dans sites-enabled
    – de déplacer ce fichier vide ailleurs et faire un raccourcis de ce fichier dans sites-enabled
    Si au redémarrage tu n’as pas d’alerte c’est que le contenu de ton fichier vhost est probablement le problème.

    • Et pour ce qui est des vhosts via l’IHM, ce n’est pas pratique il manque beaucoup trop d’options. Il me parait plus prudent de ne pas l’utiliser et d’effacer tous les vhosts créer via l’IHM avant de se lancer dans la création de vhost à la mano !

  7. Sébr dit :

    Tout d’abord merci pour ta réponse rapide, j’avais regardé pour la commande ln -s mais ce n’était pas clair, je viens de refaire une recherche et je suis tomber sur un autre site là c’est plus clair.
    Je vais me repencher sur ton tuto, merci pour tes explications.

  1. 5 avril 2016

    […] Le mieux est donc d’installer soit même un WordPress comme le présente cet article. […]

  2. 6 avril 2016

    […] si vous avez un minimum de connaissances techniques mieux vaut installer un WordPress soit même, sans utiliser le packaging Synology, comme le présente cet autre article mise à jour pour DSM6. […]

  3. 19 avril 2016

    […] Installer WordPress sur Synology (DSM 5 – DSM 6) […]

  4. 20 avril 2016

    […] vhost créer manuellement et se situant dans le répertoire site-enabled (en savoir plus grâce à cet article) […]

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *