Ça y est, c’est fait. Si vous pouvez lire ceci, c’est que personne n’a encore fait tomber mon serveur, et que la connexion internet tient bon. Oui, vous êtes chez moi, dans mon salon, à coté de ma télé : J’ai quitté le mutualisé pour Yunohost ; Ce blog est maintenant auto-hébergé 🙂

meuble-pi

Vous êtes là, dans le Raspberry rose ^^

Bon forcément si vous êtes ici, c’est que vous voulez en savoir plus. Voyons comment j’ai migré mon blog en mutualisé pour Yunohost.

Quitter le mutualisé pour Yunohost

Si j’en parle ici, c’est que ça ne me paraît pas aussi banal que ça en a l’air.
Je ne suis pas sysadmin, je n’avais jamais géré de serveur auparavant, je découvre en même temps que je fais. Pour tout vous avouer, j’ai envoyé mes premiers fichiers avec sftp via le terminal il y a moins de 72 heures. Non, je ne m’étais jamais aventuré à quitter Filezilla pour le Shell.

Ça fait une petite dizaine d’années maintenant que j’ai mis mon premier site en ligne, et depuis tout ce temps, je n’ai jamais utilisé que du mutualisé. Je n’ai pas beaucoup de trafic, ni besoin de grosse architecture, ni de gros besoin d’ailleurs, alors le mutualisé me suffit.
En plus c’est simple, tout en interface graphique sur un navigateur, pas à se faire chier sur les DNS ou les ports etc. Alors devoir tout gérer par la console en accès distant, ça déroute.
Et si ça n’a pas été clair pour moi dès le début, j’ose imaginer que ce le sera également pour d’autres.

Ce que j’ai

Posons le problème. J’ai un hébergement sur un mutualisé avec un nom de domaine à moi. Dessus je n’ai qu’un blog sous WordPress et sa base de données.
Je souhaite basculer ça sur un Yunohost qui tourne déjà. Bien entendu, il faut que le site soit le moins indisponible possible.
Voyons comment faire cela.

Créer le domaine

Tout d’abord, il faut créer le nom de domaine sur Yunohost. Il ne sera pas fonctionnel tout de suite, nous verrons ça plus tard.
Pour ma part, je créé donc le domaine max-koder.fr, que je veux récupérer de mon hébergeur.

Webapp

Ensuite, au lieu d’installer l’application WordPress officielle de Yunohost, j’ai préféré installer une Custom Webapp, qui offre une DB si besoin et un accès FTP, bien plus pratique si on veut faire joujou avec ses fichiers.

 

migration-blog-install

Notez le mot de passe FTP, il sera utile.

Étant donné que je souhaite avoir mon blog sur le domaine max-koder.fr et non pas sur un sous domaine, j’ai mis simplement / dans le chemin.
Il ne sera donc plus possible d’installer d’autres applications sur le domaine :

migration-blog-no-more-app

Récupération des fichiers du mutualisé

J’en parle vite fait, bien que ce soit logique : Il faut avant tout récupérer les fichiers de votre site qui sont chez l’hébergeur, afin de les balancer sur Yunohost.
En plus ça fera office de sauvegarde si une coquille se passe 😉

Pour ma part, j’ai choisi d’installer un plugin afin d’afficher une maintenance sur le site lors du transfert.
Ce n’est pas très utile, mais ça peut éviter que quelqu’un ne poste un commentaire sur l’ancien domaine pendant la propagation des DNS. Je ne l’ai pas activé de suite pour avoir une disponibilité du blog la plus longue possible, mais installé pour avoir ce plugin dans ma sauvegarde, que je basculerai sur Yunohost, afin d’avoir exactement les mêmes fichiers sur les 2 serveurs.

La sauvegarde de la base de données se fera le plus tard possible pour tuiler au maximum.

Modification du /etc/hosts

Pour pouvoir mettre les fichiers sur Yunohost, il va falloir se connecter au FTP de votre serveur, et plus précisément le FTP de la Custom Webapp.
Pour cela vous pouvez indiquer l’adresse IP du serveur si celle-ci est fixe, ou mettre le nom de domaine affecté.

Le problème, c’est que les DNS ne pointent toujours pas vers votre serveur Yunohost. Si c’est déjà le cas, vous avez été plus vite que la musique, et votre blog est certainement indisponible.
De plus, si vous mettez les fichiers par FTP avec pour hôte l’IP du serveur, le transfert fonctionnera, mais pas le blog : Tous vos liens internes pointent vers votre domaine et non l’IP.

Pour cela, il suffit de modifier le fichier hosts de votre machine (pas du serveur hein, votre ordinateur). Il existe sous Linux, Windows et Mac et permet de faire une correspondance entre un nom de domaine et une IP, avant d’aller chercher sur les serveurs DNS.
Nous allons donc pouvoir duper le navigateur et logiciel FTP, afin de diriger chaque requête à votre domaine sur l’adresse IP du serveur. Cette modification n’affectera bien sûr que votre ordinateur, les utilisateurs continueront d’avoir accès au mutualisé.

En fonction de votre OS, ouvrez votre fichier hosts avec les droits requis. Sous Linux, il se trouve à l’emplacement /etc/hosts.
Puis ajoutez une nouvelle ligne avec l’IP et votre nom de domaine :

Sauvegardez, et testons cela. En ouvrant le navigateur avec un onglet privé (pour éviter le cache), puis en tapant votre nom de domaine, vous devriez être redirigé vers une page blanche avec une photo de chaton, si si.
Sur cette même page, vous trouverez l’utilisateur associé au compte FTP, généralement webapp1.

Envoi des fichiers sur le FTP

Bon je ne vais pas vous expliquer comment on balance les fichiers du blog sur votre nouveau FTP. Mais sachez qu’avec Yunohost il faut travailler en SFTP, sur le port 22 par défaut. L’identifiant est celui que vous avez dû voir affiché sur la page web à l’étape juste au dessus, et le mot de passe est celui définit à l’installation de la Custom Webapp.

En revanche pour l’hôte, je vous conseille de travailler comme suit :
Pour ma part, j’ai créé 2 sites dans Filezilla. Le premier a pour hôte max-koder.fr, pour gérer mes fichiers lorsque je suis au boulot, en week-end etc. En revanche, j’ai créé un second site, dont l’hôte est l’IP locale du serveur, soit 192.168.0.34. Cela me permet de travailler directement sur le serveur en local, qui est bien plus rapide que de passer par internet quand je suis chez moi.

Une fois connecté au FTP, vous verrez un dossier www, c’est là dedans qu’il faudra envoyer les fichiers.
A la racine toujours se trouve un fichier db_access.txt. Les informations relatives à la base de données créée pour l’application se trouvent à l’intérieur, gardez les précieusement.

Balancez donc les fichiers du blog sur votre serveur, supprimez le fichier index.html (qui affiche le chaton et les infos FTP, dans le dossier www) et passons à la suite.

Modification de la config du blog

Sur WordPress, la configuration de la base de données se trouve dans le fichier wp-config.php, présent à la racine du blog. C’est dans ce fichier que les identifiants de la DB se trouvent.
Ouvrez donc ce fichier (celui du serveur Yunohost), et intéressons nous à ces lignes :

Ce code PHP définit des constantes qui sont utilisées dans tout le code de WordPress :

  • DB_NAME : Nom de la base de données. Il correspond au champ ‘name’ dans le fichier db_access.txt, généralement my_webapp.
  • DB_USER : Nom de l’utilisateur de la DB. Il correspond au champ ‘user’ dans le fichier db_access.txt, et porte le même nom que la DB.
  • DB_PASSWORD : Mot de passe de la DB. Se trouve à la dernière ligne du même fichier, champ ‘pass’.
  • DB_HOST : Hôte de la base. Mettre ‘localhost’.

Puis sauvegardez.

Base de données

Est venu le temps de basculer les données.

Dump du mutualisé

En premier lieu, nous allons effectuer un backup de la base de données du mutualisé. Pour cela, le plus simple est de passer par PhpMyAdmin de votre ancien serveur (si besoin, modifiez votre fichier hosts pour pouvoir accéder à nouveau au mutualisé).
Sélectionnez la base de données de votre blog, et allez dans l’onglet Exporter :

Dump SQL

Laissez les options par défaut, et faites Exécuter, puis enregistrez le fichier SQL.
Si la base est importante, vous pouvez cependant personnaliser l’exportation et sélectionner une compression en gzip par exemple afin de limiter le temps de téléchargement mais surtout d’upload.

Une fois l’export fait, vous pouvez aller sur votre blog fonctionnel (mutu), et activer la maintenance, pour éviter des commentaires par exemple qui ne seront pas transférés vers l’autre serveur.

Importer la base

Il va falloir maintenant importer la base de votre blog sous le serveur Yunohost.
Si ce n’est pas encore fait, installez l’application PhpMyAdmin, qui va nous permettre d’importer la DB.

Une fois dans PhpMyAdmin sur le Yunohost, sélectionnez votre base de données créée pour l’application (my_webapp), puis allez dans l’onglet Importer.
Sélectionnez la sauvegarde SQL que nous venons de récupérer, puis exécutez en laissant les paramètres par défaut.

NGINX, 404 not found

Vous avez maintenant accès à votre blog. Si la page d’accueil et l’administration fonctionnent, vous verrez qu’il y a de fortes chances que vous ne puissiez plus accéder à vos articles.
En effet, beaucoup d’hébergeurs mutualisés proposent un serveur Apache, sur lequel il est très simple de modifier la réécriture des URL, grâce à un fichier .htaccess présent normalement à la racine de votre blog.
Mais Yunohost a fait le choix de proposer un serveur NGINX pour les applications web, qui se fiche totalement du fichier .htaccess et donc, ne redirige pas bien les URL de WordPress.
Il va donc falloir modifier la configuration de NGINX pour l’adapter à notre besoin.

Connectez vous sur le serveur, et éditez le fichier conf de NGINX relatif à votre nom de domaine :

Remplacez max-koder.fr par votre domaine bien sûr.
Pour plus de sécurité, faites-en une copie avant 😉

Supprimez tout le contenu du fichier, et collez-y ceci :

Enregistrez (Ctrl + O), Enter et quittez (Ctrl + X).
Puis arrêtez et relancez Nginx :

DNS

Maintenant que le site est théoriquement prêt, il faut tester avant d’ouvrir les portes au public. Si vous ne l’aviez pas encore fait, c’est le moment de modifier votre hosts (voir plus haut) pour accéder à votre domaine sans modifier les DNS.
Si votre site fonctionne, on peut alors modifier les DNS.

Chez mon hébergeur, rien de plus facile. Il suffit de se rendre dans la gestion du domaine, et de modifier l’entrée par défaut, pour avoir ceci :

Migration DNS

Pour le moment, seule la première ligne est importante.
En gros, on redirige chaque appel au domaine max-koder.fr à l’IP de mon serveur, avec un enregistrement de type A.
Vous pouvez à présent supprimer la modification du fichier hosts de votre machine.

Une fois les DNS propagés (quelques heures au max), vous aurez accès au serveur avec votre nom de domaine.

HTTP, HTTPS

À partir de maintenant, le blog sous Yunohost doit être fonctionnel. Mais lorsque vos visiteurs arriveront sur votre blog, ils auront une belle alerte de sécurité, car le certificat mis en place par défaut par Yunohost est auto-signé.
Nous allons remédier à cela grâce aux certificats Let’s Encrypt.

Let’s Encrypt et Yunohost

Lorsque vous utilisez un sous domaine fourni par Yunohost (sub.nohost.me ou sub.noho.st), il est relativement facile d’installer un certificat Let’s Encrypt, qui vous permet d’afficher fièrement un cadenas vert sur vos pages 🙂
Il suffit pour ça d’aller, depuis l’interface graphique, sur un domaine et cliquer sur le bouton Installer un certificat Let’s Encrypt.

En revanche, pour un vrai nom de domaine, j’avais ce résultat :

Migration certificat lets encryptJ’ai un certificat auto-signé, mais impossible d’installer un certificat Let’s Encrypt, même une fois les DNS propagés.

En cherchant un peu, j’ai trouvé sur le forum une parade. Une fois connecté en SSH sur le serveur, il suffit de lancer la commande suivante :

Remplacez bien sûr max-koder.fr par votre nom de domaine 😉
L’option –no-checks va permettre de strapper les vérifications DNS qui faisaient défaut dans l’interface graphique.
Et c’est tout, votre domaine possède maintenant un certificat Let’s Encrypt valide pour 3 mois, censé se renouveler automatiquement.

Liens en HTTP

J’étais en HTTP avec mon mutualisé, et je passe maintenant en HTTPS. Forcément, mes liens internes ne fonctionnent plus.

Adresse du site

Sous WordPress, dans le menu Réglages -> Général, il va falloir indiquer que le site se trouve désormais à l’adresse https://max-koder.fr, et non plus http. Cela évitera de se faire renvoyer vers la version HTTP du site :

Migration adresse wordpressPensez bien à modifier les 2 champs.

En réalité, vous n’accéderez plus jamais à la version HTTP du site, car la conf Nginx redirige les appels à l’adresse http://domain.tld vers https://domain.tld.

Liens internes

Sur chaque page, je n’ai pas le petit cadenas vert, qui indique que toute la page est sécurisée. Non, j’ai le cadenas jaune, qui démontre que certaines ressources sont chargées en HTTP. Il s’agit surtout des images internes au site.

Pour rectifier cela, sans pour autant me taper tous les articles à la main, j’ai trouvé un petit plugin, Better Search Replace, qui va aller chercher dans la base de données et modifier ce que je veux.

Une fois lancé, il suffit d’indiquer l’ancien texte à remplacer, donc votre nom de domaine en http, le texte de remplacement, le NDD en https donc, de sélectionner les tables à modifier (toutes pour ma part), et de lancer la recherche :

Migration blog Replace

La dernière option permet, si elle est cochée, de simuler le remplacement, afin de voir combien de fois et comment le texte demandé sera remplacé.

Et voilà, mon blog est fin prêt à vous accueillir !