Migration Debian 10 vers 11


serveur web avec Django - Wagtail

rédigé le : Oct. 5, 2021

En route vers Debian Bullseye


Et oui, l'envie irrésistible de passer à Debian 11 (Bullseye) était là. Tout en sachant que cela ne se passerait pas du premier coup.

Après plusieurs années de migration Debian (depuis au moins "Sarge"), je m'attendais à de petits problèmes, qui pour la plupart me semblent plus que logiques. Migrer un serveur est toujours une opération sensible.

Mais pour tout dire, sur cette partie, serveur web avec des projet django-wagtail, la migration s'est relativement bien passée.

Voici un descriptif des actions menées.

Mise en situation


Le serveur à mettre à jour est utilisé pour héberger plusieurs sites web.

Celui-ci comporte:

La mise à jour


Pour faire cette mise à jour, j'ai bien évidemment commencer par sauvegarder toutes les données !! Point super important !!

Ensuite je conseille de mettre le système actuel à jour

$ sudo apt update
$ sudo apt upgrade

Si tout est bien sauvegardé et que le système est à jour, nous pouvons commencer les étapes de migration.

En premier, nous allons modifier le fichier sources.list de Debian.

Le mieux est d'aller sur le site de Debian (https://wiki.debian.org/SourcesList) et de récupérer les lignes à copier dans sources.list

puis de les insérer dans le fichier avec votre éditeur préféré (pour moi VI).

$ sudo vi /etc/sources.list

deb http://deb.debian.org/debian bullseye main
deb-src http://deb.debian.org/debian bullseye main

deb http://deb.debian.org/debian-security/ bullseye-security main
deb-src http://deb.debian.org/debian-security/ bullseye-security main

deb http://deb.debian.org/debian bullseye-updates main
deb-src http://deb.debian.org/debian bullseye-updates main

Avant de lancer la commande apt pour l’ultime mise à jour :) , travaillant toujours à distance sur des sessions ssh, je me place toujours dans un screen, ce qui m'évite en cas de perte de connexion de ne pas "planter" les commandes en cours, et de pouvoir reprendre la mise à jour après reconnexion.

Donc si vous ne l'utilisez pas, vous pouvez installer screen

$ sudo apt install screen

À partir de maintenant, je me connecte en root pour continuer les opérations suivantes

$ sudo su -

Maintenant que mon fichier est à jour, je vais pouvoir me placer dans un screen

# screen -S upgrade

Cette commande va ouvrir un terminal virtuel .

Petit plus, si vous ne connaissez pas screen voici un lien pour la prise en main de base (https://linux.developpez.com/formation_debian/screen.html)

C'est parti pour la mise à jour:

# apt update
# apt dist-upgrade

Lors de la mise à jour, Debian vous posera quelques questions sur certains paquets,

par exemple, si vous avez fait des modification dans le fichier sshd_config, il vous demandera si vous voulez garder l'ancienne version ou passer à la nouvelle.

Faites bien attention à ces questions !!

Je conseillerais de regarder les différences, et de garder l'ancien fichier, pour faire les modifications importantes après mise à jour (si besoin bien sûr).

Lorsque la migration est terminée, relancez le serveur, pour prendre en compte le nouveau noyau Linux.

# reboot

Après la mise à jour


Normalement, tout s'est bien passé !!!

le système se relance bien. Apache est bien relancé sur ce serveur, mais étrangement sur d'autre serveur, le service web ne s'est pas relancé seul. En regardant le statut du service apache2, l'erreur suivante s'affiche :

$ sudo systemctl status apache2
...
Syntax error on line 146 of /etc/apache2/apache2.conf: Syntax error on line 3 of /etc/apache2/mods-enabled/php7.3.load: Cannot load /usr/lib/apache2/modules/libphp7.3.so into server: /usr/lib/apache2/modules/libphp7.3.so: cannot open shared object file: No such file or directory
...

Le problème vient de la version de php qui est passé de 7.3 à 7.4, et si sur certain serveur, la mise jour fait automatiquement la bascule, ce n'est pas le cas ici. Ce n'est pas dramatique, la modification n'est pas compliqué :

$ sudo a2dismod php7.3
$ sudo a2enmod php7.4
$ sudo systemctl restart apache2

Parfait, notre service web apache2 est de retour !! Mais...

Mariadb n'est plus démarré !!!

Bon rien de grave non plus, il suffit juste de réinstaller mariad-server, et tout se relance parfaitement pour l'accès aux bases de données, ouf !

$ sudo apt install mariadb-server

On va pouvoir vérifier que les accès aux sites web sont toujours opérationnels.

Test des sites Django-Wagtail

Et là, c'est le drame, les sites ne se lancent pas.

Il semble que les librairies python ne soient plus là !! Et effectivement après vérification, les librairies sont obsolètes.

Mon espace d’environnement virtuel est toujours paramétré avec python 3.7, alors que la version Debian 11 Bulseye utilise python3.9.

Plus de peur que de mal,

mais il faut cependant que je refasse tous mes environnements virtuels python.

et c'est là, qu'un bon fichier requirement.txt tenu à jour va me faciliter la vie :)

Pour info, j'utilise virtualenvwrapper, et j'ai été confronté à deux problématiques différentes :

Reprenons la mise en place des environnements virtuels.

Donc, je supprime mes environnements virtuels python.

rmvirtualenv <monenv>
mkvirtualenv -p python3 <monenv>
pip install -r /<dir projet web de monenv>/requirement.txt

Je fais cette opération pour tous mes environnements virtuels, et c'est parfait, j'ai accès à tous mes sites !!!

Test des sites sur PHP

Si les sites Django fonctionnent maintenant, les sites PHP, pour quelques-un, ne fonctionnent plus.

Et pour des sites du type Joomla, je me retrouve avec la page blanche et le message d'erreur : error

par habitude, ce message signifie que Joomla n'arrive pas à joindre sa base de données. Mais pourquoi, mariadb est bien en fonction ?

Et bien, comme pour le passage de python3.7 à python3.9,

Debian est passé de php7.3 à php7.4,

et lors de la migration, toutes les librairies PHP n'ont pas été réinstallées. Heureusement la liste des librairies PHP installées en version 7.3 sont toujours présentes, mais désinstallées ; la commande suivante me permet de récupérer cette liste et de la réinstaller pour php7.4

$ sudo dpkg -l |grep " php7.3" | awk '{print "sudo apt install "$2 }' | sed s'_7.3_7.4_'

Cette commande me ressort une liste de lignes à copier, et re-coller dans le terminal pour exécuter les commandes (je préfère à une exécution automatique, car j'aime bien vérifier le retour de ma commande).

Dernier points php

Étant passé de ph7.3 à php7.4, il peux être intéressant de vérifier si des options configurées dans les php.ini ne sont pas perdu ( par exemple le timezone ?! ). Un "diff" des deux fichiers php.ini permet de voir rapidement les modification à faire.

diff /etc/php/7.3/apache2/php.ini /etc/php/7.4/apache2/php.ini

FINI

Voilà, j'ai retrouvé tous mes services et mon serveur est à jour !!!