Re: Mise à jour Debian par étapes
Daniel Cordey via gull <gull-04vmY7CpswVinyhjFObuvR+/[email protected]> Mon, 22 Dec 2025 11:58:08 +0100
| Newsgroups | gmane.org.user-groups.gull.general |
|---|---|
| Message-ID | <[email protected]> |
--===============1721154698==
Content-Type: multipart/alternative;
boundary="------------9NBddwC5Pgz81oH0F4DOYzrO"
Content-Language: es-ES, fr, en-US
--------------9NBddwC5Pgz81oH0F4DOYzrO
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Hola,
On 12/22/25 11:16, Claude Paroz via gull wrote:
>
> J'ai une question concernant la mise à jour de Debian (entre 2 LTS).
> La doc indique déjà 2 étapes (que je suis généralement):
> apt upgrade --without-new-pkgs
Ça risque de faire beaucoup de packages ! En effet, entre deux LTS,
presque tous les packages ont une nouvelle version...
La commande 'apt upgrade' est justement là afin de garantir une
continuité. Entre autres, ça évite de supprimer des packages qui
seraient utilisés par d'anciennes versions. Toutefois, cela ne permet
pas de passer à la LTS suivante.
Par contre, à partir du moment on l'on fait 'full-upgrade', on bascule
complètement. C'est ce qui va permettre d'installer une nouvelle version
du kernel. Ce qui fait que '--without-new-package' n'a pas vraiment de
sens si l'on veut faire 'full-upgrade'.
>
> Sur un de mes serveurs, la dernière Trixie apporte des modifications
> assez importantes dans plusieurs services (notamment la config Dovecot
> qu'il faut réécrire), donc je préférerais effectuer des mises à jour
> progressives par service (mail, web, etc.), notamment pour éviter le
> stress de devoir contrôler/corriger tout en même temps.
C'est, à mon humble avis, le gros problème des LTS. J'ai fait ça pendant
des années, et, comme toi, j'avais des tas de problèmes à chaque
nouvelle version (qui me prenaient en moyenne une semaine de travail à
chaque fois). Pour d'autres raisons, j'ai abandonné le rythme des LTS,
pour adopter les versions biannuelles d'Ubuntu. Cela limite grandement
ce problème...
>
> Ma question de base est de savoir si un système Debian est en principe
> stable et fonctionnel *tant que les dépendances sont respectées*.
C'est justement le but de 'apt update' qui permet cette garantie. C'est
un énorme travail de la part des équipes chargées d'assurer la cohérence
des dépendances. À partir du moment où l'on fait 'full-upgrade', on
bénéficie aussi du respect des dépendances, mais pour l'ensemble de la
nouvelle version. On ne peut donc pas mélanger ancien et nouveau, car ça
serait infernal
> Je m'explique: admettons que je fasse la première étape (upgrade
> --without-new-pkgs). Puis par exemple je fais un upgrade spécifique du
> noyau (avec des apt install <nom_paquet>), puis d'autres services.
> L'objectif étant bien sûr d'arriver finalement à l'upgrade complet,
> mais en avançant par étapes, ce qui pourrait théoriquement durer
> plusieurs jours.
Ça casse toute la notion du respect des dépendances. N'oublions pas
qu'il y a du systemd là-dedans... Or, plein de choses changent dans les
packages, et surtout les fichiers de config et leurs séquencements.
>
> Est-ce une tactique (trop) risquée ? Quelqu'un a-t-il déjà vécu ce cas
> de figure ?
Je conseillerais d'utiliser un système de test complet, sur lequel tu
fais la migration avec 'full-upgrade'. Tu passes le temps qu'il faut
pour migrer/corriger tous les problèmes, et ensuite, tu passes ton
système en production.
La stratégie CI/CD essaie justement d'éviter ce genre de situation et
repose sur des architectures comme Kubernetes qui permettent de
répliquer des systèmes et de les faire évoluer progressivement.
Personnellement, j'estime que les LTS peuvent répondre à des besoins
très ponctuels, mais c'est un ancien concept qui est complètement
abandonné avec Docker/Kubernetes. Docker permet précisément d'assurer
une transition en douceur vers les nouvelles versions, en facilitant les
tests d'intégration et les transitions d'une version à une autre. Je ne
peux qu'encourager quiconque ayant des systèmes de production critiques,
de migrer ses applications/services vers Docker/Podman, dans le but de
faciliter les migrations. On peut parfaitement répliquer la sécurité des
LTS en utilisant Docker/Podman, tout en enlevant tout stress lors de
l'installation d'une nouvelle version.
J'ai bien conscience que ma réponse ne va pas dans le sens de ce que tu
voudrais, mais j'ai passé des années de galère à chaque migration vers
une nouvelle version (LTS), et c'est justement pour cette raison que je
me suis éloigné de cette pratique des LTS dès que possible. Ça fait
vingt ans que j'ai changé mon fusil d'épaule et je ne reviendrais en
arrière pour rien au monde. Toutes les entreprises offrant des services
massifs sur internet, sont toutes passées à Docker/Kubernetes... ce
n'est sans doute pas un hasard !
dc
--------------9NBddwC5Pgz81oH0F4DOYzrO
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html data-lt-installed="true">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body style="padding-bottom: 1px;">
<p>Hola,</p>
<div class="moz-cite-prefix">On 12/22/25 11:16, Claude Paroz via
gull wrote:<br>
</div>
<blockquote type="cite"
cite="mid:44740101-6d07-4974-a0ad-0f05746ee200-7lkl8Tipo3fR7s880joybQ@public.gmane.org"><br>
J'ai une question concernant la mise à jour de Debian (entre 2
LTS). La doc indique déjà 2 étapes (que je suis généralement):
<br>
apt upgrade --without-new-pkgs <br>
</blockquote>
<p>Ça risque de faire beaucoup de packages ! En effet, entre deux
LTS, presque tous les packages ont une nouvelle version... </p>
<p>La commande 'apt upgrade' est justement là afin de garantir une
continuité. Entre autres, ça évite de supprimer des packages qui
seraient utilisés par d'anciennes versions. Toutefois, cela ne
permet pas de passer à la LTS suivante. </p>
<p>Par contre, à partir du moment on l'on fait 'full-upgrade', on
bascule complètement. C'est ce qui va permettre d'installer une
nouvelle version du kernel. Ce qui fait que
'--without-new-package' n'a pas vraiment de sens si l'on veut
faire 'full-upgrade'.</p>
<blockquote type="cite"
cite="mid:44740101-6d07-4974-a0ad-0f05746ee200-7lkl8Tipo3fR7s880joybQ@public.gmane.org"><br>
Sur un de mes serveurs, la dernière Trixie apporte des
modifications assez importantes dans plusieurs services (notamment
la config Dovecot qu'il faut réécrire), donc je préférerais
effectuer des mises à jour progressives par service (mail, web,
etc.), notamment pour éviter le stress de devoir
contrôler/corriger tout en même temps. <br>
</blockquote>
<br>
<p>C'est, à mon humble avis, le gros problème des LTS. J'ai fait ça
pendant des années, et, comme toi, j'avais des tas de problèmes à
chaque nouvelle version (qui me prenaient en moyenne une semaine
de travail à chaque fois). Pour d'autres raisons, j'ai abandonné
le rythme des LTS, pour adopter les versions biannuelles d'Ubuntu.
Cela limite grandement ce problème...</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:44740101-6d07-4974-a0ad-0f05746ee200-7lkl8Tipo3fR7s880joybQ@public.gmane.org"><br>
Ma question de base est de savoir si un système Debian est en
principe stable et fonctionnel *tant que les dépendances sont
respectées*. <br>
</blockquote>
<p>C'est justement le but de 'apt update' qui permet cette garantie.
C'est un énorme travail de la part des équipes chargées d'assurer
la cohérence des dépendances. À partir du moment où l'on fait
'full-upgrade', on bénéficie aussi du respect des dépendances,
mais pour l'ensemble de la nouvelle version. On ne peut donc pas
mélanger ancien et nouveau, car ça serait infernal</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:44740101-6d07-4974-a0ad-0f05746ee200-7lkl8Tipo3fR7s880joybQ@public.gmane.org">Je
m'explique: admettons que je fasse la première étape (upgrade
--without-new-pkgs). Puis par exemple je fais un upgrade
spécifique du noyau (avec des apt install <nom_paquet>),
puis d'autres services. L'objectif étant bien sûr d'arriver
finalement à l'upgrade complet, mais en avançant par étapes, ce
qui pourrait théoriquement durer plusieurs jours. <br>
</blockquote>
<p>Ça casse toute la notion du respect des dépendances. N'oublions
pas qu'il y a du systemd là-dedans... Or, plein de choses changent
dans les packages, et surtout les fichiers de config et leurs
séquencements.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:44740101-6d07-4974-a0ad-0f05746ee200-7lkl8Tipo3fR7s880joybQ@public.gmane.org"><br>
Est-ce une tactique (trop) risquée ? Quelqu'un a-t-il déjà vécu ce
cas de figure ?
<br>
</blockquote>
<p>Je conseillerais d'utiliser un système de test complet, sur
lequel tu fais la migration avec 'full-upgrade'. Tu passes le
temps qu'il faut pour migrer/corriger tous les problèmes, et
ensuite, tu passes ton système en production.</p>
<p>La stratégie CI/CD essaie justement d'éviter ce genre de
situation et repose sur des architectures comme Kubernetes qui
permettent de répliquer des systèmes et de les faire évoluer
progressivement. Personnellement, j'estime que les LTS peuvent
répondre à des besoins très ponctuels, mais c'est un ancien
concept qui est complètement abandonné avec Docker/Kubernetes.
Docker permet précisément d'assurer une transition en douceur vers
les nouvelles versions, en facilitant les tests d'intégration et
les transitions d'une version à une autre. Je ne peux
qu'encourager quiconque ayant des systèmes de production
critiques, de migrer ses applications/services vers Docker/Podman,
dans le but de faciliter les migrations. On peut parfaitement
répliquer la sécurité des LTS en utilisant Docker/Podman, tout en
enlevant tout stress lors de l'installation d'une nouvelle
version.</p>
<p>J'ai bien conscience que ma réponse ne va pas dans le sens de ce
que tu voudrais, mais j'ai passé des années de galère à chaque
migration vers une nouvelle version (LTS), et c'est justement pour
cette raison que je me suis éloigné de cette pratique des LTS dès
que possible. Ça fait vingt ans que j'ai changé mon fusil d'épaule
et je ne reviendrais en arrière pour rien au monde. Toutes les
entreprises offrant des services massifs sur internet, sont toutes
passées à Docker/Kubernetes... ce n'est sans doute pas un hasard !</p>
<p>dc</p>
</body>
<lt-container></lt-container>
</html>
--------------9NBddwC5Pgz81oH0F4DOYzrO--
--===============1721154698==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZ3VsbCBtYWls
aW5nIGxpc3QKZ3VsbEBmb3J1bS5saW51eC1ndWxsLmNoCmh0dHBzOi8vZm9ydW0ubGludXgtZ3Vs
bC5jaC9tYWlsbWFuL2xpc3RpbmZvL2d1bGw=
--===============1721154698==--