Synology : Blog WordPress avec un sous-domaine (DSM 5 – DSM 6)

Blog WordPress avec un sous-domaine

blog WordPress avec un sous-domaineLes articles précédents nous ont montrés comment mettre en place simplement un blog WordPress sur notre NAS Synology DSM version 5. Depuis, DSM 6 est arrivé et l’expérience m’a convaincu de ne plus utiliser la version packagée de WordPress ! Ce billet vous donnera un aperçu de divers problèmes que j’ai rencontrés. Le mieux est donc d’installer soit même un WordPress comme le présente cet article. L’objectif de ce billet est simplement d’accéder de façon élégante à votre blog WordPress avec un sous-domaine, blog.thorpora.fr pour l’exemple. La démarche à suivre est simple, une quinzaine de minutes suffisent !

Update DSM 6

Avec l’arrivée de la version 6, les interfaces permettent directement de créer des vhosts et cela fonctionne aussi pour les sous domaines, en HTTP et HTTPS. Cependant, une fois encore, l’expérience m’a amené à revoir ma configuration et à finalement ne plus utiliser ces IHM car trop restrictives. Cet article présente la démarche à suivre pour avoir pleinement la main sur la configuration.

Prérequis

Pour accéder à votre blog WordPress avec un sous-domaine nous supposerons que vos domaines et sous-domaines sont déjà configurés et pointent vers votre NAS, que vous disposez d’une connexion SSH à votre NAS, que votre blog est déjà accessible depuis votre domaine principal, par exemple http://thorpora.fr/wordpress. Vous avez un minimum de connaissances sur le fonctionnement des virtual hosts.

Création d’un dossier partagé

Cette partie est optionnelle, vous pouvez directement créer vos vhosts dans le répertoire /etc/nginx/sites-enabled. Personnellement, j’ai opté pour la création d’un répertoire partagé etc qui rassemble beaucoup de configurations du système, notamment les virtual hosts. L’idée est simplement 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/blog.thorpora.conf
$cd /etc/nginx/sites-enabled
$ln -s /volume1/etc/vhost/blog.thorpora.conf
$ls -l
blog.thorpora.conf -> /volume1/etc/vhost/blog.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)

Précédemment dans cet article je préconisais de modifier 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 /volume1/etc/vhost/blog.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

Dernière étape : configuration de WordPress (fin de l’article).

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.

Tout d’abord, nous allons créer un virtual host pour le port HTTP en éditant le fichier /etc/httpd/sites-enabled-user. Pensez à faire une sauvegarde de votre configuration actuelle avant d’effectuer des modifications. Ajouter les lignes ci-après.

Notez qu’un alias www a été ajouté puisque par convention ces www font références à un site Internet (un sous domaine avec www doit également être configuré sur votre DNS).
Redémarrez votre serveur Apache : httpd -k restart.
Vous pouvez aussi ne simplement que recharger la configuration à chaud avec cette commande : /usr/syno/sbin/synoservicecfg –restart httpd-user

Virtual host HTTPS

Si vous souhaitez offrir l’accès à votre blog en HTTPS, il est nécessaire de configurer un second virtual host, en éditant /etc/httpd/sites-enabled-user/httpd-ssl-vhost.conf-user.

Redémarrez Apache.

Configuration de WordPress

La dernière étape pour accéder à votre blog WordPress avec un sous-domaine consiste à avertir WordPress que notre url de base à changée depuis l’installation. Connectez vous à WordPress et dans Réglages > Général modifier l’Adresse web du site (URL) avec comme valeur http://blog.thorpora.fr. Ainsi les liens WordPress se construirons à partir de cette base.
Vérifier que tout fonctionne pour votre blog WordPress avec un sous-domaine :

Enjoy 🙂

5 réponses

  1. Scorpdragon dit :

    Bonjour
    J’ai tenté votre tuto car dans mon dossier web j’ai un petit site dans un dossier que je nomme « siteperso » j’ai un sous domaine qui pointe bien vers mon adresse ip.J’ai donc créé le fichier vhost en remplaçant par les bons noms.Le problème c’est que mon sous domaine pointe toujours sur la page de base est pas dans le siteperso.Je ne vois pas où ça cloche.Merci de votre aide.

    • Hello, j’aimerais bien pouvoir t’aider mais la il manque beaucoup d’informations 🙂 Pour ce genre problème je te conseillerai de revérifier :
      – ton fichier vhost, notamment au niveau de sa syntaxe
      – ton lien symbolique, est-il bien correcte ? (cat /etc/nginx/sites-enabled/_ton_lien_ pour vérifier)
      – un oubli du reload de la conf nginx ? (nginx -s reload)
      – n’y a t-il pas des infos intéressantes dans les logs nginx ? (tail /var/log/nginx/error.log)

      • Scorpdragon dit :

        Merci de me répondre en effet j’avais fait une petite erreur pour le lien symbolique.
        Par contre quand je fais nginx -s reload j’ai un message d’erreur concernant la ligne 15 : »invalid number of arguments in root directive…… » j’ai pourtant vérifié avec l’exemple et je n’ai pas vu de différence.
        Encore merci pour l’aide et les tutos qui m’aident à y voir plus clair (si je peux me permettre il serait bon d’ajouter des infos pour expliquer les lignes du Vhost pour les non initiés)

        • Scorpdragon dit :

          En fait j’ai trouvé il suffisait d’écrire les lignes 14 et 15 comme ça :
          root /volume1/web/_mon_dossier_cible;

          #index index.html index.htm index.cgi index.php index.php5; il semble que cette ligne ne soit pas utile.

          • En effet il manque un point virgule à la fin de la ligne ^^
            Concernant la ligne d’index, c’est plus une convention qu’autre chose mais tu as raison, le config du try_files fait que ce n’est pas utile.
            Content d’avoir pu t’aider en tout cas et merci pour tes remarques, je vais corriger 🙂

Laisser un commentaire

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