Ayant quelques serveurs en production (en Jessie ou Stretch), j’hésite toujours franchement à lancer des upgrades réguliers dans la mesure où ça peut très très mal se passer et causer des heures de sueurs froides à restaurer au plus vite un site offline et ses divers services … mais à un moment il faut bien en passer par là, et les failles APT récentes sont une raison solide de se lancer !
J’ai donc commencé à mettre à jour applicatif par applicatif sur une Stretch après backup complet (site, base, config) : en réglant la source.list uniquement sur du “main contrib non-free”, en vérifiant après update la policy de chaque élément de la liste --upgradable (elle est longue …) et en procédant une à une chaque install successive afin éviter le possible déraillement d’un upgrade total - qui me donne toujours l’impression d’un gros bouton rouge à code nucléaire …
Idéalement je procéderais si je le pouvais par des VMs avec un miroir de test pour mise à jour complète, vérification que tout marche dessus puis bascule DNS interne, mais je ne peux pas forcément faire cela sur certains serveurs … alors peut être qu’il y a d’autres astuces possibles que je ne connais pas permettant de faciliter ce type de problématique ?
Changement de version de Debian: sed -i 's#jessie#stretch#g' /etc/apt/sources.list
Ajouter le dépôt de sécurité de jessie: echo "deb http://security.debian.org/debian-security jessie/updates main" >> /etc/apt/sources.list
Reprendre du point 1 à 12
Après quelques jours, supprimer les instantanés
Jusqu’à maintenant je n’ai pas eu de réel surprise. Le travail en heure non-ouvrés permet d’avoir un peu de temps pour corriger les quelques merdouilles éventuelles.
Sinon quand je travaillais on avait des équipements en structure actif/stand-by.
Les changements de logiciels se faisaient sur le stand-by et quand on avait fini et on basculait le stand-by en actif puis on mettait à jour l’ancien actif.
Plus tu fais des « rolling updates », moins ça se passe mal.
Il vaut mieux avoir un process d’update régulier genre mensuel, AMA.
Aprés, tu peux cloner tes machines en virtualbox et tester tes updates, si tu veux t’assurer de ne pas interrompre ta production.
Erf, effectivement, je parle d’instantané dans un contexte de virtualisation. Lorsqu’il s’agit de serveurs physique, je fais une image CloneZilla. Cela sous-entends un arrêt le temps de la sauvegarde…
Snapper n’est pas directement compatible avec les partitions ext4
LVM2 n’accepte pas de reprendre ma partition ext4 pré-existante
Malgré de nombreuses tentatives, je n’ai pas trouver le moyen de contourner ces problèmes … je commence à me demander si je ne vais pas creuser côté virtualisation finalement, car je ne trouve aucune autre alternative locale à la Snapper qui soit du même niveau - la plupart des solutions trouvées sont plus ou moins des gros backups via rsync.