Carnet 4 – Migration

J’ai migré hier soir unicoda.com vers un nouveau VPS, toujours chez OVH, dans leur centre de données de Strasbourg. J’ai réalisé l’installation complète à partir d’un script ansible qui réinstalle le site à partir de la sauvegarde quotidienne stockée dans le cloud et reconfigure automatiquement le processus de sauvegarde.

L’ancien serveur va continuer de fonctionner encore quelques jours, le temps de s’assurer que la propagation des DNS aura eu lieu pour la plupart des lecteurs. La sauvegarde est désormais désactivée sur ce serveur.

Au passage, j’en ai profité pour récupérer une sauvegarde locale du site sur mon poste. On est jamais trop prudent. Il restera à vérifier dans quelques semaines que le renouvellement du certificat aura été effectué correctement de manière automatique. Il n’y a priori pas de raison que cela ne fonctionne pas, mais étant donné que j’utilise désormais le client acme.sh à la place de certbot pour demander un certificat wildcard, des vérifications s’imposent.

Au passage, un petit tour du côté de la page SSL Server Test du SSL Labs, me gratifie d’un joli A+, qui témoigne du chemin parcouru depuis la première mise en place du HTTPS sur ces pages (B- ou C au début).

Au moment où j’écris ces lignes, c’est-à-dire quelques heures après l’opération de migration, je n’ai détecté aucun problème de configuration ou de fonctionnement. Toutefois, lecteurs attentifs, n’hésitez pas à me signaler tous dysfonctionnements que vous auriez remarqué.

[Note de service] Migration en cours (Nouvel environnement)

Unicoda est en train de migrer vers un environnement tout neuf. Si vous voyez cette note, c’est que vos DNS sont à jour et dirige vers la nouvelle version.

Les quelques tests effectués via la 4G sont plutôt positifs. Cela semble fonctionner correctement. Pas d’erreur dans les logs du nouvel environnement et déjà quelques logs d’accès.

Le reste des vérifications demain.

Pourquoi j’ai migré ma boîte mail

Pendant longtemps, mon adresse mail principale a été gérée par le FAI de la famille; une adresse en @neuf.fr en l’occurrence. J’ai jonglé et jongle encore entre plusieurs adresses mails, en fonction des cas et des besoins. Je crois que j’ai pris conscience de l’importance de l’adresse mail que l’on communique (la principale, pas celle pour le spam), le jour où, en pleine recherche de stage, le serveur mail de mon école d’ingénieur s’est écroulé et est resté inaccessible pendant une petite semaine. Pas terrible, lorsque l’adresse mail qui figure sur votre CV retourne un mail d’erreur technique. On reste heureusement joignable par l’intermédiaire plus traditionnel du téléphone. Bref, dans les deux jours qui suivaient, j’avais changé l’adresse mail de mon CV par mon adresse principale FAI.

Et voilà qu’il y a de cela deux années, la question est revenue sur le devant la table. Après avoir repris le contrôle sur un certain nombre de mes données en hébergeant mes propres services, je me suis tourné vers le problème de l’adresse mail. Il faut savoir qu’en France, une adresse FAI n’est pas immuable. Tant qu’on reste chez ce FAI, pas de problème, mais dès lors que l’on résilie son abonnement, les risques apparaissent. En effet, en cas de résiliation, le fournisseur a l’obligation légale de maintenir l’accès à l’adresse pour une durée de 6 mois. Après 6 mois, la décision de conserver l’adresse mail ou de la supprimer pour pouvoir la réattribuer est à la discrétion de l’opérateur. En règle générale, les pratiques diffèrent donc d’un fournisseur à l’autre, certains garantissent la pérennité de l’adresse sans limite de temps, d’autres avec condition « d’activité » par période de 6 mois. Il est donc préférable d’éviter d’utiliser une adresse mail FAI comme adresse principale de contact, sachant que l’on peut être amené à changer de fournisseur pour l’une ou l’autre raisons.

Se pose également la question de la confiance. Bien évidemment, les mails que nous envoyons transitent en clair sur le réseau, et si les communications peuvent être éventuellement chiffrés entre les serveurs par lesquels le mail passera, celui-ci reste en clair au niveau de chaque serveur le temps d’être transféré vers le serveur suivant. On s’intéresse davantage ici à la confidentialité des données. En clair, dans quelle mesure faisons-nous confiance à l’hébergeur de notre adresse pour que celui-ci ne consulte pas le contenu de nos mails entrants et sortants; comme le fait Google à l’aide d’algorithmes pour proposer de la publicité ciblée dans son interface web ?

Ayant réfléchi à de nombreuses reprises, à l’hébergement de mon propre serveur mail, mais l’ayant toujours repoussé pour divers raisons (relative complexité, gestion du spam, mise en liste blanche de l’IP du serveur, redondance en cas de panne ou d’indisponibilité…), je me suis tourné vers une solution intermédiaire : prendre un nouveau nom de domaine chez un hébergeur proposant une solution mail associée. Ainsi, j’obtiens le premier maillon, le nom de domaine et peux par la suite rediriger les mails vers mon propre serveur. J’ai donc enregistré un nom de domaine chez Gandi puisque leur offre inclut la possibilité de créer 5 boîtes mail pour 1Go d’espace total partagé, redirection, alias, antivirus et anti-spam, avec possibilité de passer sur une offre payante spécifique pour le mail. Cette solution permet également d’envisager si nécessaire, le passage vers une offre payante chez ProtonMail, avec gestion de nom de domaine personnalisé.

Voici quelques points que j’ai noté pour mon changement d’adresse mail :

  • Ne pas se précipiter, prendre son temps. Cela ne sert à rien d’espérer tout changer en quelques jours, il faudra du temps pour s’assurer que nos contacts utilisent notre nouvelle adresse.
  • Migrer progressivement tous les comptes vers la nouvelle adresse. En effectuant la migration sur plusieurs mois, on constate au fur et à mesure quels services ne disposent pas de la nouvelle adresse.
  • Éventuellement et si possible, mettre en place un message de réponse automatique sur l’ancienne adresse pour indiquer le changement d’adresse.

Par ailleurs, ce travail de migration se trouve grandement simplifié lorsqu’on possède déjà la liste de ses comptes dans un Keepass ou équivalent. On connaît alors tous les endroits où le changement d’adresse est à effectuer; mais en contrepartie, toutes les entrées utilisant l’ancienne adresse sont à mettre à jour.

La question essentielle à se poser me semble être : « A qui puis-je faire confiance pour gérer mes mails et dans quelle mesure ? ».

PS: Reste toujours le même problème que si l’un de nos contacts à son adresse chez un fournisseur auquel nous ne faisons pas confiance, celui-ci dispose tout de même d’une copie de nos échanges. (A moins de chiffrer évidemment).

Migrer son WordPress

C’est effectif depuis jeudi soir, Unicoda dispose maintenant d’un serveur tout neuf. Effectuer une migration de WordPress est en fait relativement simple pour peu qu’un terminal ne vous fasse pas peur et sinon, des interfaces graphiques et autres plugins peuvent parfois vous simplifier encore le travail. Le nom de domaine ne changeant pas, la procédure en est encore simplifiée.

On arrive donc sur un serveur vierge de tout paquets, les paquets de base et c’est tout. Quelques installations s’impose donc, à coup d’aptitude ou de apt-get si vous préférez. Avant toute chose, on met à jour les informations concernant les paquets avec aptitude update, puis mise à jour via aptitude safe-upgrade. Suite à ces manipulations, un petit dpkg-reconfigure tzdata s’impose, histoire d’avoir une heure correcte sur le serveur. L’heure de Moscou, c’est bien beau, mais pour avoir des logs lisibles, une heure française c’est mieux (Bonjour à nos amies russes et biélorusses au passage). Arrive donc la phase d’installation à proprement parler. Via aptitude install, on installe donc les paquets suivants: php5, mysql-server, php5-mysql, php5-gd, vsftp.

Vient ensuite la configuration de vsftp, serveur FTP comme vous avez pu le deviner. On édite le fichier /etc/vsftpd.conf et on relance avec /etc/init.d/vsftpd restart pour que les modifications soient prises en compte.

On s’attaque ensuite à la partie MySQL pour préparer la nouvelle base de données de notre site à accueillir celle provenant de l’autre serveur : mysql -p. Puis dans votre invite de commande MySQL:

>CREATE DATABASE nomBaseDeDonnees;

>GRANT ALL PRIVILEGES ON nomBaseDeDonnees.* TO "NomUtilisateur"@"hostname" IDENTIFIED BY "motDePasse";

>FLUSH PRIVILEGES;

>EXIT;

Concernant les différents paramètres, nomBaseDeDonnes correspond au nom que vous donnez à votre base de données, nomUtilisateur parle de lui-même, hostname est généralement à remplacer par localhost et motDePasse c’est limpide. Votre base de données est donc prête à accueillir vos anciennes informations relatives à vos articles, utilisateurs, commentaires, etc…

Il faut également récupérer le contenu de votre dossier wp-content qui contient toutes les images que vous avez pu héberger sur votre site, les thèmes et les plugins. Un téléchargement du dossier via un client FTP fonctionnera très bien. Compresser le dossier avant envoi vous permettra de patienter moins longtemps pendant le téléchargement de vos données et surtout, pendant leur upload à venir. Une fois le dossier téléchargé, on l’upload justement vers le nouveau serveur; cette étape prend du temps surtout si votre dossier n’est pas compressé et que votre upload se résume à du 36Ko/s. On peut ensuite remplacer le dossier wp-content de notre installation toute fraîche de WordPress par celui de notre ancien site.

Il faut également transférer les données de  l’ancien base de données et les injecter dans la nouvelle. La commande suivante vous permet de récupérer les anciennes données dans un fichier:

mysqldump --add-drop-table -h mysqlhostserver -u mysqlusername -p databasename | bzip2 -c > fichier.bak.sql.bz2.

Au niveau des paramètres, localhost pour mysqlhostserver, votre nom d’utilisateur pour mysqlusername, le nom de l’ancienne base de données à la place de databasename et remplacer fichier par le nom que vous voulez pour votre sauvegarde des données. On récupère ensuite le fichier via notre ftp, on l’upload à son tour vers le nouveau serveur, on décompresse au préalable le fichier: bzip2 -d fichier.bak.sql.bz2 et on injecte les données dans notre nouvelle base de données:

mysql -h mysqlhostserver -u mysqlusername -p databasename < fichier.bak.sql

Avec localhost pour mysqlhostserver, votre nom d’utilisateur mysql pour mysqlusername et le nom de votre nouvelle base de données en lieu et place de databasename. A ce stade, votre nouveau site est presque opérationnel, il ne reste plus qu’à faire pointer le nom de domaine vers le nouveau serveur, configurer apache (Doc Ubuntu) et éditer le fichier wp-config.php de votre nouveau WordPress avec les paramètres utilisés pour la création de la nouvelle base de données.

On trouve la plupart des informations dont on a besoin sur le web, et notamment sur le site de WordPress. Quelques heures suffisent donc à effectuer la migration d’un site WordPress vers un nouveau serveur si on conserve le même nom de domaine, le plus long étant à mon sens, l’upload du dossier wp-content.