Sommaire

Distro Upgrade sur hôte Docker

Introduction

Mon serveur chez OVH (celui sur lequel ce site est hébergé) avait été installé en 16.04 LTS et upgradé en 18.04 avant que j’y mette mes services.
Ayant tous mes services en conteneurs Docker, je n’ai pas eu grand besoin de me tenir à jours sur mon hôte.

Sur les versions LTS d’Ubuntu, les MAJs de sécurités sont supportés pendant 5 ans (soit jusqu’à 04/2023 pour la 18.04 LTS).

J’ai donc décidé de mettre à jour mon serveur.
Je vais alors vous détailler ici les étapes que j’ai dû faire et les problèmes que j’ai eus.

Tant qu’à faire, je vais mettre à jour mon serveur en 22.04.
Du coup, je vais effectuer deux MAJ d’OS (une vers focal et une autre vers jammy).

Préparation

Avant tout, il faut s’assurer d’être déjà totalement à jour au niveau des packages. On s’assure aussi d’avoir le package qui permet la MAJ de l’OS.

1
2
3
apt update
apt upgrade
apt install update-manager-core

Ensuite, je désinstalle Docker et enlève les sources associées :

1
apt purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-ce-rootless-extras

Je supprime alors le fichier de source Docker :

1
rm /etc/apt/sources.list.d/docker.list

Je relance un update et upgrade pour être sûr et je redémarre mon serveur.

Upgrade

SSH

Je lance alors la procédure avec un do-release-upgrade. Comme je suis sur un serveur chez OVH, j’effectue cette action via SSH.

J’ai alors un message me disant :

Lecture du cache

Vérification du gestionnaire de paquets

Continuer dans une session SSH ?

Cette session semble tourner à travers SSH. Il n’est actuellement pas recommandé de faire une mise à niveau à travers SSH car en cas d’échec, il est plus difficile d’effectuer une réparation.

Si vous continuez, un nouveau service SSH va être lancé sur le port « 1022 ». Voulez-vous continuer ?

_Continuer [oN]

Je valide donc cela et ouvre une autre connexion en parallèle sur ce port au cas où.

Maudis Python

Ensuite, comme à mon habitude, j’ai des problèmes avec python :

Vérification du gestionnaire de paquets

Mise à niveau impossible

Votre installation de python3 est corrompue. Veuillez corriger le lien symbolique « /usr/bin/python3 ».

Le programme de MAJ nécessite python3.6 alors que j’ai la version 3.8.
Bien que /usr/bin/python3.6 --version fonctionne, update-alternatives --config python3 ne me propose pas cette version, mais uniquement la 3.8…

J’ai alors résolu le problème en forçant le lien symbolique :

1
ln -sf /usr/bin/python3.6 /usr/bin/python3

Le processus d’upgrade est maintenant fonctionnel.

Focal

Ci-dessous, les étapes que j’ai bêtement validées :

/bionic-distro-upgrade/img/Screenshot_1.webp
Configuration de paquet

Fichier de configuration « /etc/security/access.conf »
==> Modifié (par vous ou par un script) depuis l’installation.
==> Le distributeur du paquet a fourni une version mise à jour.
Que voulez-vous faire ? Vos options sont les suivantes :
Y ou I : installer la version du responsable du paquet
N ou O : garder votre version actuellement installée
D : afficher les différences entre les versions
Z : suspendre ce processus pour examiner la situation
L’action par défaut garde votre version actuelle.
*** access.conf (Y/I/N/O/D/Z) [défaut=N] ?y

Fichier de configuration « /etc/crontab »
==> Modifié (par vous ou par un script) depuis l’installation.
==> Le distributeur du paquet a fourni une version mise à jour.
Que voulez-vous faire ? Vos options sont les suivantes :
Y ou I : installer la version du responsable du paquet
N ou O : garder votre version actuellement installée
D : afficher les différences entre les versions
Z : suspendre ce processus pour examiner la situation
L’action par défaut garde votre version actuelle.
*** crontab (Y/I/N/O/D/Z) [défaut=N] ?y

Lecture des listes de paquets… Done
Construction de l’arbre des dépendances
Lecture des informations d’état… Done

Recherche de logiciels obsolètes
Lecture des informations d’état… Done

Supprimer les paquets obsolètes ?

68 paquets vont être supprimés.

_Continuer [oN] Détails [d]

La mise à niveau du système est terminée.

Redémarrage nécessaire de l’ordinateur

Un redémarrage est nécessaire pour terminer la mise à niveau.
Si vous choisissez « o », le système sera redémarré.

_Continuer [oN]

Une fois le redémarrage effectué, un lsb_release -a me montre bien que je suis en 20.04 :

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal

J’ai lancé un update et upgrade mais tous les paquets étaient déjà à jour.

Jammy

Voulez-vous commencer la mise à niveau ?

1 paquet installé n’est plus maintenu par Canonical. Vous pouvez
toujours obtenir une assistance de la part de la communauté.

5 paquets vont être supprimés. 81 nouveaux paquets vont être
installés. 485 paquets vont être mis à jour.

Vous devez télécharger au total 549 M. Ce téléchargement prendra
environ 1 minute avec votre connexion.

L’installation de la mise à niveau peut prendre plusieurs heures. Une
fois le téléchargement terminé, ce processus ne peut être annulé.

_Continuer [oN] Détails [d]

Fichier de configuration « /etc/sudoers »
==> Modifié (par vous ou par un script) depuis l’installation.
==> Le distributeur du paquet a fourni une version mise à jour.
Que voulez-vous faire ? Vos options sont les suivantes :
Y ou I : installer la version du responsable du paquet
N ou O : garder votre version actuellement installée
D : afficher les différences entre les versions
Z : suspendre ce processus pour examiner la situation
L’action par défaut garde votre version actuelle.
*** sudoers (Y/I/N/O/D/Z) [défaut=N] ?

Recherche de logiciels obsolètes
Lecture des informations d’état… Done

Supprimer les paquets obsolètes ?

119 paquets vont être supprimés.

Supprimer les paquets peut prendre plusieurs heures.

_Continuer [oN] Détails [d]

La mise à niveau du système est terminée.

Redémarrage nécessaire de l’ordinateur

Un redémarrage est nécessaire pour terminer la mise à niveau.
Si vous choisissez « o », le système sera redémarré.

_Continuer [oN]

Drame

Après plus de 10 minutes, toujours pas de réponse au ping… Entre temps, je reçois un message automatique d’OVH me disant qu’ils vont investiguer un potentiel défaut matériel.
Le problème n’est surement pas matériel en vue du contexte.

Bref, je passe en mode rescue (qui me boot sur une Debian) pour tenter de faire des trucs…
Je ne m’y connais pas assez pour comprendre et résoudre le problème… Du coup, je tente un tuto pour réinstaller grub mais rien n’y fait.

Je me résous donc à réinstaller le serveur…
Je réalise alors une archive de toutes les datas de mes conteneurs (dans mon cas, archiver le dossier /var) et je scp cela sur mon PC (47 Go => 1h…).

Réinstallation

Configuration

Je fais donc une demande de réinstallation en Ubuntu 22.04 et patiente.
Après une quinzaine de minutes, je reçois les informations de connexion par e-mail.

Je me connecte donc, copie ma clé SSH et lance mon playbook Ansible qui réalise automatiquement les actions suivantes :

  • Installation de package que j’utilise (htop,…)
  • Configuration de ma politique de MAJs automatique
  • Ajouts de mes scripts spécifiques
  • Configuration des éléments de supervision (Nagios)
  • Installation de Docker et Compose
  • Création de l’arborescence de mes services Docker
  • Copie de mes fichiers de configurations de mes conteneurs

Application

Je copie alors mon archive de données (encore une heure de copie…) et l’extrait afin que mes services retrouvent leurs données.

Ainsi, je navigue dans chaque dossier de service pour faire un docker compose up -d en croisant les doigts.
Bonne nouvelle, tout fonctionne comme avant !

Conclusion

La mise à jour de l’OS est une opération délicate. Il faut toujours prévoir le pire.

Je considère que j’ai eu de la chance mais j’avais aussi prévu le coup.
Avec Ansible et mes sauvegardes automatiques (bien que je ne me suis pas servi de ces derniers), j’étais quasiment sûr de pouvoir sauver les meubles.

En tout cas, si vous faites la même opération que moi, bon courage !