Debian passage de "Stretch" à "Buster" sur une machine virtuelle "simple" (Xen).

J'ai réalisé les tests sur une machine virtuelle déjà installée en "Stretch". 
J'ai fait le premier test dans une VM de test pour bien vérifier la marche à suivre ... et tester le kernel 5.0.2 en version "Xenifiée". 
Ordre prévu des opérations : 
1) Mise à niveau "Stretch" de cette machine. 
"apt-get update + apt-get upgrade" : mettre à jour la machine au dernier niveau de Stretch. 
Toutes les commandes suivantes sont exécutées avec "... 2>&1 | tee FICHIER.LOG" afin de garder une trace complète des actions. 
2) Modifier le fichier sources.list :

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" : 
- lancer "apt-get clean" 
- lancer "apt-get update" :

Les nouveaux fichiers doivent apparaître dans /var/lib/apt/lists :

5) Effectuer une mise à jour simple. 
Lancer "apt-get upgrade" pour effectuer une mise à jour simple. Pour ce premier test cela télécharge 572 paquets. J'ai choisi de relancer les services sans confirmation. 
Après un certain temps (un temps certain ?) la machine est enfin à jour. 
Début : 11:27 
Fin      : 11:45 
Un "cat /etc/debian_version" donne un magnifique "buster/sid" 
et on peut remarquer l'installation d'un noyau "4.19" un peu plus récent que le "4.9" de Stretch. 
6) Reboot. 
Je reboote la machine pour valider le tout avant de passer à l'opération suivante. La machine a bien rebooté et démarré sur le noyau 4.19. 
7) Effectuer l'upgrade de version. 
- "apt-get dist-upgrade" me signale de nombreux paquets "obsolete" à supprimer par "apt-get autoremove" que je décide de faire immédiatement et stoppe le "dist-upgrade". 
-- "apt-get autoremove" supprime 28 paquets et récupère 275Mb de disque. 
-- "apt-get dist-upgrade" qui signale d'autres paquets à passer en "autoremove", 401 paquets upgradés et 326 nouveaux paquets installés. 
Il faudra donc relancer un "apt-get autoremove" après. 
Début : 11:56 
Fin   : 12:14 
8) Nettoyage final. 
-- "apt-get autoremove" et 464MB de disque libérés. 
Très rapide : #2 minutes. 
On a alors une machine "propre" en Buster, on la reboote pour vérifier et le redémarrage se passe fort bien : le passage est réussi sans aucune anomalie. 
Etape suivante migrer une machine plus complexe avec apache, PHP, une base de données Mysql/MariaDB ....

Au démarrage les seules remarques évidentes sont un changement de couleur :

• Lors du boot (interface grub plus sombre)
• Lors de la connexion à X où le fond d'écran semble, là aussi, plus sombre.

J'ai répété cette procédure sur une autre machine de test et tout a fonctionné comme prévu.

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. 
 

Je suis ensuite passé aux choses sérieuses : migrer une "vraie" machine de production, celle sur laquelle est implanté ce service Web dans une machine virtuelle. 
J'ai choisi de faire la migration "on line" sans aucune interruption "volontaire" du service. 
J'ai suivi la procédure indiquée, c'est un peu long, mais cela fonctionne sans problèmes majeurs. Tout juste quelques modifications de fichiers de config à accepter (après vérification ! ). 
Phases de 1 à 5 passées sans ennuis et le service Web est resté disponible pratiquement tout le temps (sauf lors des reboot bien sûr !). 
Phase 6 : Reboot sur kernel 4.19. 
Phase 7 : dist-upgrade : 
Un grand nombre de paquets modifiés ou créés (927 paquets), tout se passe bien ! Là aussi quelques modifications de fichiers de config à accepter ou refuser (toujours après vérification !! ). 
La migration PHP7 --> PHP7.3 est "incorporée" mais pas pour Apache ! Qui refuse de fonctionner car seuls sont présents les modules php7. 
Voir /etc/mods-availables : 
ls -1 *php* 
php7.0.conf 
php7.0.load 
Vite installer libapache2-mod-php7.3 php7.3-mysql et quelques modules PHP7.3 qui semblent manquer. 
a2dismod php7.0 
a2enmod php7.3 
systemctl restart apache2 
Et cela fonctionne nettement mieux ! 
Vite un "apt-get autoremove" pour terminer ... qui me propose la suppression de 200 paquets et 344MO disque d'économie. 
Un reboot rapide pour vérifier la stabilité du système mis à jour et le service WEB manque encore de quelques modules PHP7.3 ... après leur mise en place tout semble fonctionner parfaitement.

Tests du lendemain : tout semble OK la sauvegarde de nuit a fonctionné. 
Ci dessous les interruptions de service :