Un peu d’amour pour le blog (et la VM en général)

Cet article a été publié il y a 3 ans 10 mois 16 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Vous connaissez l’adage qui dit que les cordonniers sont les plus mal chaussés ? Dans mon cas c’était incroyablement vrai, ma procrastination sur la maintenance de tout ça étant incroyablement puissante. J’ai quand même fini par me mettre à la tâche, et j’ai décidé de détailler pour que l’on comprenne bien le problème afin d’éviter de le reproduire.

Le champ de bataille

Nous sommes donc sur une VM bloquée en Debian 8, avec les installations notables suivantes :

• PHP 5.6 des dépots Jessie pour les scripts legacy
• PHP 7.0 des dépots Dotdeb (la référence de l’époque quand je l’ai installé)
• PHP 7.3 des dépots Sury, d’abord pour Matomo dont les dernières versions commandaient un PHP supporté.
• Redis de dépot Dotdeb
• nginx-http2 du dépot dédié Dotdeb

Et surtout, d’anciennes traces d’installation d’ISPConfig, qu’on se traîne encore comme un boulet parfois sans savoir pourquoi on a des soucis. On le voit, je ne suis pas vraiment mon propre conseil d’essayer de limiter les sources externes de paquets, mais avec le temps et l’âge d’une Debian, proposer des technos récentes (PHP7+ et HTTP2 entre autres), c’est compliqué. Pareil pour les montées de versions qui sont compliquées par les opérations passées et l’activité des scripts.

Installation de la VM, allégorie

De cette installation, j’en ai tiré notamment un conflit à l’installation du module Redis sur PHP 7.3 à cause du nom du package qui bute avec les fichiers de celui de php 7.0 de Dotdeb. J’avais pas fait attention quand j’avais installé PHP 7.3 en ce mois de Janvier, et j’avais du coup perdu deux mois de visites sur Matomo (c’est lui qui demandait PHP 7.3 pour ses mises à jour), parce que le plugin Queued Tracking qui stocke les visites dans Redis avant enregistrement définitif renvoyait une erreur 500 parce que les commandes Redis n’existent pas. Et comme l’interface fonctionnait au moment où j’ai basculé, j’ai pas percuté. Oui, je suis un boulet.

Travail préparatoire

L’intervention a donc d’abord été l’occasion d’un gros gros inventaire et surtout d’un nettoyage de scripts inutiles, de vhosts inexistants et non fonctionnels, de pools php qui vont avec ou orphelins (vhosts nettoyés mais php toujours là), bref, les confs PHP et Nginx sont beaucoup plus claires sur ce qui est réellement en activité sur le serveur.

J’en ai également profité pour procéder à un déménagement de certains vhosts annexes sur PHP 7.3, comme mon FreshRSS qui me remercie grandement. Au passage, au fur et à mesure je rend agnostique le chemin du socket, ça permet de changer facilement de version sans avoir à bidouiller plusieurs fichiers. Là, je déplace le fichier de conf du pool d’une version de PHP à l’autre, je redémarre celui qui ne sert plus, je redémarre celui qui servira, je teste. Le retour arrière est à peu près aussi rapide.

Ça a aussi permis de virer quelques packages, et j’ai été surpris, parce qu’en fait, PHP 5.6 n’était plus utilisé ni démarré, il a donc fini à la poubelle. Autre découverte, apache2 est également toujours installé !? Il a rejoint PHP 5.6. J’ai potentiellement viré un ou deux autres trucs découverts par hasard, mais pas forcément en lien direct avec le bordel du jour.

On attaque la butte

Ce coup-ci, on rendre dans le dur. Je commence par réactiver les dépôts Sury pour tenter de mettre à jour les paquets PHP 7.0 de Dotdeb vers PHP 7.0 Sury. L’opération a pris du temps, mais s’est bien terminée, modulo quelques paquets restants. En effet, ils n’ont pas le même nom chez Sury. Je les supprime donc (paquets liés au module redis) et je réinstalle la version Sury. Et ça s’est super bien passé !

Il restait quelques éléments à supprimer pour être définitivement tranquille. Le méta-paquet « php » va installer la dernière révision de PHP en date, soit PHP 7.4. Et désormais, je n’ai plus de conflit à l’installation de paquets PHP 7.x. Au passage, il y a des différences entre PHP 7.0 et php 7.3, mais dans certains cas ils sont juste inutiles donc pas la peine de les installer. D’autres n’existent plus comme mcrypt, on va voir juste après la conséquence.

Ce que le nettoyage a permis

J’ai pu réinstaller le QueuedTracking de Matomo, qui permet un gain de temps substantiel dans le chargement de la page puisque la visite est enregistrée dans Redis avant d’être traitée et enregistrée dans la base de données en arrière-plan par Matomo. Moins d’attente dans le chargement d’une page de votre côté, et comme de toute façon je suis pas à la seconde pour la traçabilité, ça peut prendre le temps que ça veut pour enregistrer (ou pas, en fonction des détails envoyés comme le DNT).

J’ai aussi profité pour virer le dépot Dotdeb pour m’assurer que je ne risquais pas d’installer quelque chose qui provient de chez eux. Il ne reste que celui dédié à Nginx qui n’a de toute façon pas été mis à jour depuis un moment (oui je sais…), mais comme il ne contient pas de paquets PHP c’est pas grave. J’ai d’ailleurs fait le ménage sur deux/trois autres dépôts qui ne servent plus et qui pour certains étaient déjà désactivés. Moins de dépôts activés, veut dire mises à jour et installations qui prennent moins de temps.

Une seule source de PHP, plus de conflit (je crois que je l’ai déjà dit), veut dire aussi passage à de futures versions facilité, ou presque. En effet, en fonction de l’âge des scripts/applications installées, ça peut se vautrer dans les grandes largeurs avec une version qui supprime une ou plusieurs fonctions qui servent à ceux-ci. et dans mon cas, mon WordPress va encore avoir besoin d’un peu d’amour pour tenter une grosse montée de version avant de pouvoir bénéficier d’une montée de version de PHP (et quand je vois le gain sur FreshRSS, ça fait plus qu’envie). J’ai quand même tenté l’upgrade vers PHP 7.2, pour l’instant je ne constate pas d’erreur, malgré l’âge de certains éléments (plugins pas maintenus entre autres). Il faudra quand même que je termine cette satanée migration vers WordPress 5 pour m’assurer de ne plus avoir de problème et pouvoir continuer les migrations.

moi à la fin de l’après-midi

J’étais chaud du coup j’ai procédé un peu pareil sur le VPS qui porte l’installation de LibreNMS. ce VPS avait déjà subi une sale montée de version de Debian à l’arrache, OVH avait eu la très mauvaise idée de juste laisser « stable » dans la configuration des dépots, mais comme je ne fais pas de dist-upgrade en auto, ça s’était fini en simili Debian 9 avec des dépendances et le noyau de Debian 8. Là encore, j’avais le PHP 5.6 de Debian 8 encore installé sur Debian 9, alors qu’il ne servait plus à rien.

Le nécessaire déménagement

Je me suis concentré aujourd’hui sur les problèmes liés à PHP et au blog (tiens au passage, le récent problème lié à Broken Link Checker a été compliqué à régler, mais c’est fait). Mais on l’a vu, il reste des horreurs comme le nginx custom, et la VM, avec son âge, a plusieurs autres tares, dont ces fameux relents d’ISPConfig. Faire la montée de version en place ne m’intéresse pas et causerait certainement plus de problème qu’elle n’en résoudrait, il est temps de mettre l’installation à la retraite pour repartir sur du neuf, un peu comme un gros ménage de printemps ne remplace pas un déménagement dans l’efficacité à virer les choses accumulées depuis des années.

Et ça fait partie des choses que je préparais pour le futur proche, mais c’était dans l’optique d’un certain budget allouable qui ne sera pas possible cette année (merci SARS-Cov-2). J’ai donc des plans à revoir pour quand même avancer sur le sujet sans me faire trop mal au porte-monnaie, en attendant, je suis content du résultat des travaux.

PS : j’avais prévenu sur Twitter que « ça va couper chérie » le temps que je bosse dessus. On m’a demandé pourquoi j’ai pas bossé sur une seconde VM à côté et basculé une fois terminé. Déjà parce qu’il y a pas mal de choses sur cette VM, et pas seulement le blog : autres sites, serveurs de discussion vocales, etc. Ensuite, la configuration réseau n’a jamais été pensée pour permettre ce genre de bascule simple, la machine est directement exposée avec son IP publique, sans pare-feu ni reverse-proxy devant, pas de Docker, pas de pare-feu autre que celui du noyal. Donc j’ai bossé « en live », ce qui n’était pas plus mal pour permettre de découvrir l’étendue des dégâts potentiels. Mais certains aspects pourraient changer dans la future infra.