Migration chez Proxgroup !

Bonjour,

La semaine dernière, nous publions un article annonçant que notre offre chez OVH se terminait le 25 juillet 2019 et que nous songions à changer d’hébergeur en conséquence.

Le jour même, nous avons reçu des dizaines de commentaires de votre part sur Mastodon nous suggérant de nombreux hébergeurs.

Nous en avons donc contacté quelques-uns parmi vos suggestions et nous nous sommes arrêtés sur l’association Proxgroup, hébergeur associatif suggéré par @ThomasGandalf.

Merci pour vos nombreuses suggestions qui nous ont grandement aidé dans notre recherche :)

Ce 25 juillet 2019, nous avons ainsi migré l’intégralité de notre infrastructure chez Proxgroup.

🔗Résumé de ce long parcours

« Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell. » − Luc

🔗24 juillet

Le 24 juillet à 13h15, nous annoncions ce que nous pensions être le début de la maintenance.

Proxgroup venait à peine de remettre le serveur entre nos mains que nous avions déjà commencé nos premières opérations : on nous avait remis un Debian 8 (Jessie), la première étape était de le mettre à jour vers Debian 10 - Stable (Buster) avant de commencer les choses sérieuses.

Première tâche, première mauvaise surprise : après une mise à jour d’une rapidité séduisante sans aucune erreur, nous redémarrons le VPS… Et il ne démarre plus.

On a réessayé plusieurs fois, on tentait de contourner le problème, mais il n’y avait rien à faire : ça marche sur Jessie, sur Stretch, mais sur Buster ça ne fonctionne plus.

On arrête tout et on vient déranger à nouveau le support de Proxgroup pour leur demander pourquoi ça ne marche pas.

On apprend dans leur réponse que Buster n’est pas compatible avec LXC. Pour être exact, la version de systemd utilisée par Buster causerait des problèmes.

Donc on nous propose de changer de VPS (pour passer sur un KVM) et on repart quelques heures plus tard sur un nouveau… Mais cette fois, on n’arrive pas à s’y connecter via SSH, même après plusieurs redémarrages, on galère.

En s’y connectant via VNC, on se rend compte que le VPS semble déconnecté d’Internet (un simple ping ou apt update ne fonctionnait pas) ; il a donc fallu recontacter le support qui a réglé le souci dans la nuit… (mais comme on était fatigués, on est partis dormir).

🔗25 juillet

Comme c’était le jour où notre offre expirait chez OVH, il a fallu la renouveler pour un mois afin d’éviter un downtime de plusieurs heures.

En début d’après-midi, nous annonçons sur Mastodon le début de la vraie maintenance.

Nous avons donc exécuté successivement les opérations suivantes sur le nouveau VPS :

• Mise à jour vers Buster
• Désactivation du compte root, création d’un compte utilisateur
• Rotation des clés SSH (ajout de nos nouvelles clés)
• Configuration des paramètres de sécurité de SSH (restrictions des algorithmes de chiffrement, désactivation de certaines fonctionnalités, SSHFP dans le DNS)
• Installation des paquets listés dans le rapport technique
• Remplacement du DNS par défaut du serveur et de Docker par celui de FDN
• Création des volumes Docker
• Téléchargement des images de base
• Migration des Dockerfiles, recompilation des images
• Génération de nouveaux certificats TLS…

🔗Migration des services

Le plus délicat était de migrer les services, car certains hébergent des données utilisateur ; il était donc nécessaire de les arrêter sur l’ancien serveur, de transférer les données puis de les démarrer sur le nouveau et enfin, de changer le DNS pour que le sous-domaine du service pointe vers le nouveau serveur.

On a donc commencé par les services qui ne nécessitent aucune coupure car ils n’ont pas de données : le proxy DoH et le service Schémas, (draw.io) ; il n’y a donc pas eu de downtime pour ces services et tout s’est très bien passé.

Juste après, nous avons migré le service Liens (Lstu), ce qui nous a nécessité 5 minutes de downtime (très peu de données).

Enfin, il nous restait à migrer le site, la base de données et le service mail ; ces trois services étant interconnectés, il est difficile de les migrer un par un.

On a migré tant bien que mal la BDD et le site avec un petit downtime de 5 minutes, mais nous avons rencontré un problème en migrant le service mail, à deux doigts de la fin de la migration. Au moment du démarrage du conteneur, Docker nous indiquait que le port 25 était déjà utilisé… On a cherché pourquoi pendant un petit moment pour finalement se rendre compte que Exim était installé de base sur l’hôte, et c’est lui qui squattait le port 25. On a fait le ménage et le service a enfin démarré :)

Notre dernière demande auprès du support fut celle de modifier le reverse DNS de notre nouvelle IP afin que nos mails ne se fassent pas blacklist (il n’y avait pas d’option pour cela dans leur interface).

🔗Leçons à retenir

Nous nous sommes retrouvés plusieurs fois dans une situation incertaine dans laquelle nous avons dû faire appel au support.

Quelques détails sur lesquels vous devez être attentifs lorsque vous migrez votre serveur :

• Annoncer la maintenance sur le plus de canaux possibles (nous avons failli sur ce point-là, puisqu’on ne s’est contentés que de Mastodon)
• Essayer d’être un peu plus précis en annonçant la durée de la maintenance (là aussi on a failli, on parlait d’un downtime de plusieurs heures, finalement c’était 10 minutes tout au plus grâce à la magie des conteneurs)
• Bien comprendre les enjeux autour de l’utilisation de la technologie de virtualisation du VPS (KVM, LXC, …).
• S’assurer qu’il soit possible de modifier le reverse DNS de votre IP si besoin
• Si vous hébergez des mails, assurez-vous que votre hébergeur / offre vous le permet. Si vous pouvez, testez l’IP de votre VPS sur les blacklists connues afin de vous assurer que cette IP n’a pas déjà servie à de mauvaises intentions.

🔗Des informations sur le nouveau serveur ?

Notre VPS chez Proxgroup dispose de 4 coeurs virtuels et 4 Go de RAM (+ 1 Go de swap).

En terme d’espace disque, nous sommes à 40 Go HDD avec possibilité d’agrandir si nécessaire. Le HDD n’est pas trop handicapant par rapport au SSD grâce au RAID 50 dont nous bénéficions, avec 1.7 To de cache SSD :)

Tout cela nous est gratuitement fourni par Proxgroup en échange d’une mention de leur association sur notre page d’accueil et dans la page “Nos amis”, ce qui est à nos yeux tout à fait respectable vis-à-vis des moyens mis en place en amont et qui correspond au même esprit d’entraide entre associations que nous entretenons de la même manière avec les CHATONS.

🔗Serveurs, réseau et et transparence

Enfin, nous préciserons que selon Proxgroup, ces serveurs sont hébergés à Nanterre.

L’association Proxgroup est en contrat avec avec Netrix SAS pour disposer d’une partie du datacenter, que Netrix exploite auprès du groupe Zayo. (ERRATUM: Il s’agit en réalité de Hexatom, pas Zayo.)

Proxgroup est aussi devenu membre du LIR auprès du RIPE en 2017.

Nous avons pu disposer de ces informations grâce à la transparence exemplaire dont fait preuve Proxgroup sur leur blog.

🔗Qu’en est-il du serveur précédent ?

Puisque nous avons dû renouveler notre offre chez OVH pour un mois et qu’il n’y a plus rien dessus, nous avons mis en place un relai Tor qui fonctionnera jusqu’à la fin de l’offre, le 25 août 2019.

Ce relai fonctionne dans un conteneur basé sur l’image de jess/tor-relay, légèrement altérée par nos soins.

🔗Remerciements

Nous tenons tout particulièrement à remercier l’association Proxgroup pour son formidable travail, leur réactivité et leur bienveillance :)

À très bientôt,

N&B