Migrer MV complexe

Passage de Stretch à Buster d'une machine applicative. 
La machine visée (sous KVM) comporte :

• un serveur Web
• PHP
• Une base de données MariaDB
• Un seul processeur virtuel, 40 Go de disque et 1024 Mb de RAM.

Seul OSSEC présent sur la machine d'origine ne sera pas traité ici. 
Le serveur Web utilise une copie de ce site. 
On reprend les étapes utilisées pour la machine "simple". 
Remarque : 
Les listes de mises à jour peuvent être longues et "sortir" de l'écran il est donc conseillé de lancer les commandes avec "tee" vers un fichier de log : "apt-get upgrade 2>&1 | tee /tmp/MONUPGRADE.LOG" on aura ainsi accès au listing intégral en cas d'incident. On peut aussi aller boire un café pendant que ça "tourne" ! 
1) Mise à niveau de Stretch par la trilogie : 
-- apt-get clean 
-- apt-get update 
-- apt-get upgrade 
Ce dernier ne donne que quelques paquets à traiter en "autoremove", ce qui est fait dans la foulée. 
2) Modification du fichier "sources-list" :  
récupération de celui de la machine précedente avec ajout de "contrib non-free".

3) Effacer les fichiers de paquets "Stretch" :  
Dans /var/lib/apt/lists : supprimer tous les fichiers. 
4) récupérer les information paquets de "Buster" :

• Mettre à jour le fichier sources.list.
• apt-get clean ; apt-get update" 

5) première mise à jour "Buster" : 
apt-get upgrade 
601 paquets téléchargés (301MB) 184MB d'espace disque supplémentaire, 401 laissés en l'état. 
Redémarrage automatique des services. 
Debut : 19:10 
Fin     : 19:34 
6) Reboot pour démarrer sur le nouveau noyau 4.19. 
7) Effectuer l'upgrade de version.

• Commencer par nettoyer : "apt-get autoremove"
• Continuer par : "apt-get dist-upgrade"

446 paquets "upgradés", 352 nouveaux, 726MB à télécharger,1235MB d'espace supplémentaire. 
Début : 19:41 
Fin     : 19:54 
Mais l'installation de MariaDB 10.3 a échoué ! et a bloqué l'installation de 396 autres paquets. 
Après analyse il s'agit d'un conflit entre le MariaDB 10.3 déjà installé sur la machine d'origine (déjà un clone !) depuis une source non Debian pour tester la version 10.3. 
Essai de "forçage" des problèmes de version :

et cela à l'air de fonctionner, la connexion à la base est fonctionelle. 
Par contre ni "haproxy", ni "apache" ne sont lancés. 
8) Nettoyage final : "apt-get autoremove" + reboot. 
"autoremove" demande de faire un "apt-get --fix-broken install" pour un problème de dépendances lié à Python 3.5 et 3.7. 
Cela va installer 4 nouveaux packages et finir l'installation interrompue par MariaDB soit 396 paquets ! 
Après installation de tous ces paquets se déroule et "haproxy" ne peut être redémarré, mais cela n'interrompt pas la suite de l'installation. 
Il va falloir vérifier et adapter le paramétrage Haproxy qui semble refusé par la nouvelle version. 
9) Un petit reboot pour finir le nettoyage. 
Tiens, Apache a bien démarré et semble fournir des données consormes, MariaDB est donc en bonne forme. 
Par contre Haproxy refuse touhours de démarrer et "journalctl -xe", comme souvent, ne donne aucune information utile ! 
Je vais donc voir le log de Haproxy et : Ah! Mais c'est bien sûr ! J'ai simplement oublié de changer l'adresse IP de connexion dans "haproxy.cfg" c'est donc celle du premier clone ! Dès que c'est fait tout rentre dans l'ordre et mon haproxy se met en route sans problème. 
Quelques tests sur le site permettent de vérifier que tout fonctionne. 
Toutefois nous sommes encore liés à PHP7.0 il va falloir tenter le passage dans la version supérieure car Buster fournit PHP 7.3 et on va pouvoir tester OpCache qui est censé bien fonctionner en 7.3. 
Après quelques jours : 
Après 4 jours je fais la première mise à jour "Buster" et comme on est encore en période presque "unstable" énormément de paquets mis à jour et plus de 230MO téléchargés dont PHP7.3. Après cette mise à jour je constate encore 46 paquets à supprimer, et un petit coup de "apt-get autoremove" m'en débérasse et libère 609MO dont l'espace occupé par les "vieux" noyaux série 4.9 encore présents, la version utilisée : 4.19.0.0-bpo.2.