[gull] Mise à jour Debian par étapes

[Marc SCHAEFER]

Bonsoir,

J'ajoute mon petit (?) grain de sel sur un seul point:

On Mon, Dec 22, 2025 at 05:07:28PM +0100, Claude Paroz via gull wrote:
> Pour le cas de figure que j'ai présenté, l'objectif est toujours de finir
> sur une LTS complète, c'est juste une manière plus progressive d'y arriver.
> Et pour le cas plus général du testing dans une stable, il peut arriver des
> situations où on n'a pas le choix. Mais on est d'accord, ça doit rester
> exceptionnel.

Je dirais que pour des services "complexes", j'ai tendance aujourd'hui
(depuis environ 4-5 ans systématiquement, depuis une vingtaine d'années
dans certains cas) à mettre chaque service complexe dans sa propre
machine virtuelle (plutôt du lxc à l'origine, aujourd'hui aussi
du Docker).

Je sais que tu as explicitement exclu ces solutions: toutefois, je
trouve que lxc est super-simple à mettre en place et ne crée pas
énormément de dépendances à des façons de faire trop complexes.  Docker
également, on peut en faire quelque chose d'assez simple aussi.

En résumé, pour certains services complexes, j'ai tendance à les isoler,
et à les mettre à jour de manière étalée. Evidemment cela signifie
maintenant que tu as plusieurs "systèmes Debian" à gérer, mais
cela contrebalance la complexité d'une mise à jour de tout.  Ca prend
toutefois du temps d'isoler (mais la plupart du temps j'y ai pensé
au début: et quand ce n'est pas le cas, je profite du prochain
cycle LTS Debian de 5 ans pour le faire en planifiant).

Exemples tirés de mon expérience:

   - en général les hosts sont super-simplifiés ce qui veut dire
     que leur mise à jour est sans problèmes particuliers
     et très rapide, ils ne sont pas directement accessibles
     d'Internet (uniquement via un jump host), de même d'ailleurs
     pour la plupart des services SSH des conteneurs

   - j'ai un serveur web centralisé en conteneur qui termine le HTTPS
     et gère des certificats usuels et du Let's Encrypt,
     mais après il proxifie à certains services

        le réseau interne inter-conteneurs et inter-hosts est
        firewallé de manière adéquate, limitant l'impact
        du piratage d'un seul conteneur, mais évidemment pas
        celui d'un host: tout mettre en HTTPS serait possible
        mais jusqu'ici j'ai considéré que cela ne valait pas
        la peine

   - les services complexes chez moi sont, chacun dans leur
     conteneur (lxc ou Docker, c'est égal, je gère cela assez
     similairement sans dépendances trop fortes à Docker),
     notamment:

        - serveur mail, anti-spam
        - serveur de mailing-list Mailman
        - serveur de base de données PostgreSQL
        - serveur de téléphonie Asterisk
        - serveur d'applications Mojolicious
        - serveur de ticket RT
        - serveur de statistiques (munin principalement)
        - serveur Home Assistant
        - serveur Foswiki
        - SSH jump host
        - serveur fail2ban
        - serveur IDS
        (et 2-3 autres trucs)

   - tous ces conteneurs écrivent leur logs dans un endroit
     centralisé (voir fichiers à partager ci-après), donc un seul
     fail2ban, une seule communication à abuseipdb.com, etc

   - la localisation exacte des conteneurs (sur quel host)
     est arbitraire (utilisation d'un DNS interne pour
     remapper)

   - les fichiers à partager sont partagés en quelque chose
     qui ressemble à NFS (glusterfs pour les intimes), et
     donc chaque serveur peut être sur une machine matérielle
     différente (et peut être migré)

   - il y a deux firewalls: un extérieur, et un pour mon mini-cloud,
     qui sont gérés au sein d'un outil centralisé avec le reste
     du firewalling inter-host et inter-conteneur, y compris un
     système de détection d'intrusion centralisé

Typiquement il y a 2 ans j'ai profité d'une mise à jour de bullseye à
bookworm pour sortir RT, PostgreSQL, Asterisk et fail2ban d'un gros
conteneur fourre-tout LTS datant d'environ *20 ans*!!!: désormais j'ai
des scripts d'auto-déploiement et je peux les mettre à jour
individuellement.  Ce boulot relativement important me permet
d'envisager, d'ici 2028, un passage à trixie progressif sans souci, même
s'il y a quand même pas mal de choses qui changent.  Les scripts de
déploiement sont complètement agnostiques de lxc/Docker/whatever et
pourraient même marcher en machine réelle à quelques détails près
(environnement spécifique).

Il y a d'ailleurs un cas particulier: Asterisk n'étant plus vraiment
dans Debian récente, j'ai un script de déploiement automatique de la
dernière version stable que je tourne de temps en temps (*).  De même
pour Home Assistant.  Il faut accepter que certains logiciels très
spécifiques ne puissent pas raisonnablement être packagés par Debian.
J'ai hésité pour Mailman par exemple, mais finalement la version de
Debian me suffit (après 2 ans de recul).

Pour le reste, l'ensemble des conteneurs sont surveillés automatiquement
en sécurité et je peux choisir quelles mises à jour de packages Debian
appliquer en tout temps.

D'un autre côté, il me reste des machines Debian complexes (p.ex.
mon laptop personnel et quelques systèmes pas encore migrés), et
j'apprécie effectivement la qualité de la gestion de packages Debian,
ainsi que la possibilité de garder "un certain temps" des packages
de compatibilité avec certaines versions (en particulier pour
PostgreSQL ça marche dans mon expérience très facilement, en plus
de la possibilité d'installer avec support officiel souvent au
moins deux versions majeures).

En ce qui concerne la prochaine échéance LTS (été 2026, fin de
bullseye), il me reste actuellement 4 conteneurs à migrer, dont un que
je souhaite "découper", et un qui va mourir lorsque toutes ses
applications Mojolicious seront migrées au conteneur applicatif dédié.
Sinon, je prévoir de faire la migration à trixie ou son successeur,
d'une partie des conteneurs dès 2026 ou 2027, et finir en 2028.

Tout ce travail depuis 2020 m'a aussi permis de passer d'environ 300 W
de consommation électrique à moins de 120W, à la fois en utilisant des
systèmes embarqués recyclés (apu2) et des ordinateurs recyclés à basse
consommation, tout cela y compris deux routeurs pour deux liaisons
Internet, 3 switches, et 4 hosts.  Normalement d'ici cet été, je devrais
pouvoir passer à 2 hosts et 2 switches, et donc probablement autour de
60-80W (le routeur UPC consomme 14 W, il va devenir un élément
significatif de la consommation).

PS: ce qui est aussi chouette c'est la possibilité de mettre à jour
    un host en ayant migré tous ses conteneurs ailleurs avant,
    puis remigrer ensuite, ou de tester rapidement des mises à jour
    sur un conteneur construit à partir d'un snapshot LVM ou
    Docker d'un autre!  Ou d'activer la nouvelle version déployée
    d'une application en 1 seconde en changeant les règles de
    firewall et/ou le DNS.

(*) non, je ne ferai pas confiance aux images Docker, et j'ai des
    patches source locaux qui ne me permettent de toute façon
    pas de les utiliser, et je ne souhaite pas injecter de
    dépendances à Docker de toute façon!  je génére sur la même
    base des images de base Debian pour lxc ou Docker.