APT lent sur Ubuntu 24.04 : astuces de cache/proxy pour accélérer les mises à jour en entreprise

Méthode de diagnostic rapide

Quand on dit « APT est lent », cela peut signifier n’importe lequel de ces cas :

• La récupération des métadonnées est lente (apt update bloque sur « Connecting »)
• Les téléchargements de paquets sont lents (apt upgrade rampe)
• La décompression/configuration est lente (CPU/disque contraints, rien à voir avec le réseau)
• Tout est lent parce qu’un proxy « aide » mal

Premier point : déterminer si c’est réseau, miroir ou E/S locale

1. Mesurez la vitesse de téléchargement vers le miroir depuis un client et depuis un hôte réseau « connu bon ». Si les deux sont mauvais, c’est WAN/miroir/proxy. Si seuls les clients sont lents, c’est client/proxy/DNS.
2. Vérifiez la latence DNS. Un DNS lent fait paraître APT bloqué, parce qu’il l’est — en attente.
3. Séparez la phase fetch et l’installation en ne téléchargeant que (apt-get -d) et en chronométrant la décompression séparément.

Deuxième point : vérifier le comportement du proxy

1. Si vous êtes derrière un proxy d’entreprise, vérifiez s’il fait de l’interception TLS, du scanning de contenu, ou un « cache » mal configuré.
2. Confirmez que APT utilise bien le proxy que vous pensez. La moitié du temps il n’est pas configuré sur les serveurs, et l’autre moitié il est configuré deux fois.

Troisième point : décider la classe de correction

• Bureau avec 10–300 machines Ubuntu : déployez apt-cacher-ng sur le LAN. C’est le point idéal.
• Conformité stricte + jeu de paquets stable : envisagez un miroir complet ou un gestionnaire de dépôts (plus d’exploitation, plus de contrôle).
• Machine isolée sur mauvais Wi‑Fi : choisissez un meilleur miroir et corrigez le DNS ; ne construisez pas un empire de cache.

Pourquoi APT « semble lent » en entreprise

Les performances d’APT sont façonnées par une pile de petites latences. En datacenter, ces latences sont faibles et prévisibles. En bureau, elles sont chaotiques : retransmissions Wi‑Fi, résolveurs DNS, proxys transparents, appliances « sécurité », et un lien WAN partagé avec des appels vidéo et quelqu’un qui synchronise une bibliothèque photo de la taille d’une petite lune.

APT a aussi un profil de trafic spécifique :

• Beaucoup de petits fichiers de métadonnées pendant apt update (fichiers Release, listes d’index).
• Puis moins, mais plus gros téléchargements de paquets pendant l’installation/mise à niveau.
• Puis E/S disque locale et CPU pendant la décompression et les scripts post-installation.

La première phase est celle où les bureaux souffrent. APT peut récupérer des dizaines de fichiers depuis plusieurs dépôts. Si chaque connexion HTTPS a une poignée de main lente ou chaque requête DNS prend 200 ms, ça s’accumule vite. Un cache/proxy sur le LAN condense cette latence en un saut local rapide.

Conseil assumé : Si vous avez plus que quelques systèmes Ubuntu sur un même site, arrêtez de laisser chaque machine télécharger les mêmes paquets depuis Internet. Ce n’est pas « décentralisé ». C’est juste du gaspillage.

Une petite blague en bonus : APT n’est pas lent ; il attend patiemment que votre proxy finisse ses pensées.

Faits intéressants et contexte

• APT a été lancé à la fin des années 1990 comme outil de haut niveau pour Debian, conçu pour gérer les dépendances de façon fiable entre dépôts.
• « Acquire » est tout un sous-système dans APT ; la plupart des plaintes « APT est lent » concernent en réalité la configuration d’Acquire, le DNS et le transport — pas dpkg.
• APT utilisait historiquement plusieurs connexions avec précaution parce que les miroirs et la bande passante étaient rares ; les réseaux modernes ont inversé les contraintes, mais APT optimise toujours la correction avant tout.
• L’écosystème de miroirs d’Ubuntu est distribué globalement ; le « meilleur » miroir pour un bureau peut changer selon le peering de l’ISP, pas la géographie.
• HTTPS est devenu l’attente par défaut avec le temps ; il améliore l’intégrité et la confidentialité mais augmente l’overhead de poignée de main et rend certains appareils de mise en cache transparents inutiles.
• Les index de paquets sont compressés (souvent .gz), ce qui est bon pour la bande passante mais signifie que le CPU peut compter sur de petites machines ou VM surchargées.
• apt-cacher-ng est devenu populaire parce qu’il est sans chichis : il peut mettre en cache sans que vous ayez à héberger un miroir complet ni réécrire les structures de dépôts.
• Dans de nombreux bureaux, le DNS est le goulet invisible parce que les résolveurs internes redirigent en amont avec filtrage, journalisation et limites de débit.

Une idée paraphrasée, car elle vaut la peine d’être retenue en exploitation : Werner Vogels a souvent défendu l’idée que « tout échoue, donc concevez pour la défaillance » (idée paraphrasée). La lenteur d’APT est généralement une défaillance douce : pas assez cassée pour déclencher une alerte, mais suffisamment pour gaspiller le temps de tout le monde.

Tâches pratiques : commandes, sorties, ce que ça signifie, et la décision

Ce sont des tâches de terrain. Exécutez-les d’abord sur un client affecté, puis sur l’hôte de cache/proxy potentiel. Ne devinez pas. Mesurez.

Task 1: Confirmer quelle partie est lente (update vs download vs install)

cr0x@server:~$ sudo time apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://security.ubuntu.com/ubuntu noble-security InRelease [110 kB]
Fetched 110 kB in 8s (13.2 kB/s)
Reading package lists... Done

real    0m9.214s
user    0m0.391s
sys     0m0.103s

Ce que ça signifie : Vous passez des secondes à récupérer de petites métadonnées. Ça sent le DNS, la poignée de main du proxy, ou la latence par requête.

Décision : Concentrez-vous sur DNS/proxy/cache, pas disque ou CPU.

Task 2: Mesurer seulement le temps de téléchargement pour les mises à niveau (ignorer le temps d’installation)

cr0x@server:~$ sudo time apt-get -y -d dist-upgrade
Reading package lists... Done
Building dependency tree... Done
The following packages will be upgraded:
  openssl openssh-client
Need to get 4,812 kB of archives.
Get:1 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 openssl amd64 3.0.13-0ubuntu3.2 [1,402 kB]
Get:2 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 openssh-client amd64 1:9.6p1-3ubuntu13.4 [3,410 kB]
Fetched 4,812 kB in 2s (2,406 kB/s)

real    0m3.011s
user    0m0.233s
sys     0m0.116s

Ce que ça signifie : Si ceci est rapide mais que la mise à niveau complète est lente, votre goulet est l’installation/décompression locale et les scripts.

Décision : Si le téléchargement est rapide, cessez d’accuser les miroirs. Regardez le disque et les verrous dpkg.

Task 3: Vérifier les verrous dpkg/apt et les processus bloqués

cr0x@server:~$ ps aux | egrep 'apt|dpkg' | head
root        1421  0.0  0.1  18220  4800 ?        Ss   09:01   0:00 /usr/lib/apt/apt.systemd.daily
root        1507  0.2  0.3  56340 12420 ?        S    09:02   0:01 /usr/bin/dpkg --configure -a

Ce que ça signifie : La tâche quotidienne systemd peut déjà être en train de mettre à jour ou configurer des paquets.

Décision : Ne la contrariez pas. Laissez-la finir, ou planifiez les mises à jour hors des heures de bureau.

Task 4: Vérifier les dépôts et les transports configurés (HTTP vs HTTPS)

cr0x@server:~$ grep -R --no-filename -E '^(deb|deb-src)\s' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null | head -n 8
deb http://archive.ubuntu.com/ubuntu noble main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu noble-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu noble-security main restricted universe multiverse

Ce que ça signifie : Vous utilisez HTTP ici (courant pour les dépôts Ubuntu). HTTPS peut être plus lent via des appliances d’inspection ; HTTP peut être bloqué dans certains environnements.

Décision : Choisissez le transport qui s’intègre proprement à votre politique réseau ; le cache fonctionne mieux quand le chemin est stable.

Task 5: Vérifier quel miroir vous atteignez réellement (et s’il y a redirection)

cr0x@server:~$ apt-cache policy | sed -n '1,60p'
Package files:
 100 /var/lib/dpkg/status
     release a=now
 500 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages
     release v=24.04,o=Ubuntu,a=noble-updates,n=24.04,l=Ubuntu,c=main,b=amd64
     origin archive.ubuntu.com

Ce que ça signifie : Confirme l’origine et les priorités de dépôt.

Décision : Si vous déployez ensuite un cache, vous validerez que l’origine change vers votre hôte de cache.

Task 6: Diagnostiquer la latence DNS (souvent le vrai coupable)

cr0x@server:~$ resolvectl status | sed -n '1,40p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.0.10
       DNS Servers: 10.20.0.10 10.20.0.11

Ce que ça signifie : Vous utilisez un DNS interne. C’est bien — jusqu’à ce qu’il soit lent ou qu’il filtre agressivement.

Décision : Si le DNS interne est surchargé, corrigez-le ou ajoutez un résolveur cache local par site.

Task 7: Chronométrer les recherches DNS pour les miroirs

cr0x@server:~$ time getent ahosts archive.ubuntu.com | head -n 3
91.189.91.83    STREAM archive.ubuntu.com
91.189.91.83    DGRAM
91.189.91.83    RAW

real    0m0.215s
user    0m0.004s
sys     0m0.004s

Ce que ça signifie : 215 ms pour une requête n’est pas catastrophique, mais multiplié par des dizaines de requêtes, plus des retransmissions, plus des proxys, ça devient moche.

Décision : Si vous voyez >100 ms de manière répétée en LAN, traitez le DNS comme une dépendance de production et mettez un cache local.

Task 8: Mesurer le temps de mise en place TCP/TLS brut

cr0x@server:~$ curl -I -s -o /dev/null -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' http://archive.ubuntu.com/ubuntu/
dns:0.021 connect:0.034 tls:0.000 ttfb:0.102 total:0.103

Ce que ça signifie : Pour HTTP, pas de TLS. Si vous exécutez la même chose contre un dépôt HTTPS et voyez un grand tls, un proxy ou une appliance d’inspection peut être impliqué.

Décision : La latence se corrige avec un cache LAN car les poignées de main lentes n’ont lieu qu’une fois par objet autrement.

Task 9: Vérifier les problèmes de MTU (classique « ça marche mais c’est lent »)

cr0x@server:~$ ip link show dev eth0 | sed -n '1,3p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

Ce que ça signifie : MTU 1500 est normal. Si vous êtes sur VPN/VXLAN/PPPoE et avez un MTU non assorti, vous pouvez avoir des retransmissions et des blocages.

Décision : Si les téléchargements se bloquent aléatoirement, testez le Path MTU et corrigez l’edge réseau, pas APT.

Task 10: Voir si APT utilise un proxy (et lequel)

cr0x@server:~$ apt-config dump | egrep -i 'Acquire::(http|https)::Proxy' | head
Acquire::http::Proxy "http://proxy.office.local:3128/";
Acquire::https::Proxy "http://proxy.office.local:3128/";

Ce que ça signifie : APT est explicitement configuré pour utiliser un proxy.

Décision : Si ce proxy est distant (SIège) et que votre bureau ne l’est pas, vous venez d’ajouter un RTT inutile. Placez le cache plus près ou contournez-le pour les dépôts Ubuntu.

Task 11: Confirmer la reachable du proxy et s’il est le point d’étranglement

cr0x@server:~$ curl -s -o /dev/null -w 'proxy_connect:%{time_connect} total:%{time_total}\n' http://proxy.office.local:3128/
proxy_connect:0.003 total:0.004

Ce que ça signifie : Le proxy LAN est joignable rapidement. Si cela prend des secondes, votre « proxy de bureau » n’est pas local ou est surchargé.

Décision : Corrigez la localisation/capacité du proxy avant de réécrire les configs APT.

Task 12: Inspecter le comportement de retry/timeout d’APT (symptômes de perte)

cr0x@server:~$ sudo apt -o Debug::Acquire::http=true update 2>&1 | egrep -i 'Connecting|Waiting|Retrying' | head -n 20
Connecting to archive.ubuntu.com (91.189.91.83)
Waiting for headers
Connecting to security.ubuntu.com (185.125.190.39)
Waiting for headers

Ce que ça signifie : Les « Waiting for headers » indiquent une latence serveur/proxy, de la congestion, ou de la perte de paquets plus que des limites de bande passante brute.

Décision : Déployez un cache sur le LAN pour réduire les allers-retours externes ; si ça persiste, investigatez la perte WAN et l’overhead d’inspection proxy.

Task 13: Valider que vous avez assez d’espace disque pour le cache sur l’hôte de cache

cr0x@server:~$ df -h /var/cache | tail -n 1
/dev/sda2        200G   38G  153G  20% /var

Ce que ça signifie : Beaucoup d’espace pour un cache de paquets. apt-cacher-ng est efficace même avec un stockage modeste, mais il ne doit pas manquer d’espace.

Décision : Si l’espace est limité, allouez un volume dédié pour le cache et définissez une politique d’éviction.

Task 14: Confirmer que votre cache sert réellement des hits une fois déployé

cr0x@server:~$ sudo tail -n 8 /var/log/apt-cacher-ng/apt-cacher.log
2025-12-29 10:12:41|O|171|archive.ubuntu.com|ubuntu|pool/main/o/openssl/libssl3_3.0.13-0ubuntu3.2_amd64.deb
2025-12-29 10:13:02|H|612|archive.ubuntu.com|ubuntu|pool/main/o/openssl/libssl3_3.0.13-0ubuntu3.2_amd64.deb

Ce que ça signifie : O est une récupération origine (miss). H est un hit cache. Les hits sont là où l’accélération et les économies de bande passante se produisent.

Décision : Si vous ne voyez que des origines, vos clients ne pointent pas vers le cache, ou la mise en cache est désactivée pour ce chemin de dépôt.

Options de cache et proxy (que déployer)

Il existe trois stratégies principales pour les bureaux. Chacune a sa place. Deux d’entre elles se compliquent trop facilement.

1) apt-cacher-ng sur le LAN (meilleur défaut)

Ce que c’est : Un proxy HTTP qui comprend les schémas des dépôts Debian/Ubuntu et met en cache les paquets et fichiers d’index quand les clients les demandent.

Pourquoi ça marche : Le deuxième client obtient les paquets à la vitesse du LAN. Le 50e client ne titille presque pas le WAN.

Compromis : C’est une dépendance partagée. Si vous le rendez fragile, vous en entendrez parler. Si vous l’exploitez sans histoire, personne ne le remarquera — ce qui est le plus grand compliment en exploitation.

2) Proxy HTTP générique (Squid ou proxy d’entreprise)

Ce que c’est : Un proxy général qui peut ou non mettre en cache efficacement, selon le comportement HTTPS et les règles de cache.

Quand ça marche : Si la plupart du trafic de vos dépôts est en HTTP et que la politique de cache du proxy est sensée.

Quand c’est pénible : Dépôts HTTPS plus interception et scanning peuvent transformer APT en un documentaire au ralenti sur les poignées de main TLS.

3) Miroir local complet / gestionnaire de dépôts

Ce que c’est : Vous répliquez les dépôts Ubuntu localement (ou utilisez un gestionnaire de dépôts qui synchronise le contenu sélectionné).

Quand ça en vaut la peine : Flottes importantes, contrôle strict des changements, réseaux quasi air-gapped, ou besoin de disponibilité déterministe pendant des pannes amont.

Inconvénient : Plus de stockage, plus d’exploitation, plus de tickets « pourquoi ce dépôt ne se synchronise pas ».

Déployer apt-cacher-ng (recommandé pour la plupart des bureaux)

C’est la victoire de bureau : une petite VM ou mini-PC par site, quelques lignes de config, et soudain les mises à jour cessent d’être un incident réseau hebdomadaire.

Installation serveur sur Ubuntu 24.04

cr0x@server:~$ sudo apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Reading package lists... Done

Signification : Le système de base est assez sain pour installer des paquets.

cr0x@server:~$ sudo apt install -y apt-cacher-ng
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  apt-cacher-ng
Setting up apt-cacher-ng (3.7.4-1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/apt-cacher-ng.service → /usr/lib/systemd/system/apt-cacher-ng.service.

Signification : Le service est installé et activé.

Décision : Décidez où les clients y accéderont (nom DNS), et s’il doit écouter sur toutes les interfaces.

Confirmer qu’il écoute

cr0x@server:~$ sudo ss -lntp | egrep ':3142'
LISTEN 0      4096         0.0.0.0:3142      0.0.0.0:*    users:(("apt-cacher-ng",pid=1824,fd=7))

Signification : Le port par défaut 3142 est ouvert sur toutes les interfaces. Si c’est trop permissif, restreignez avec des règles de pare-feu.

Pare-feu de base (restreindre aux sous-réseaux du bureau)

cr0x@server:~$ sudo ufw allow from 10.20.0.0/16 to any port 3142 proto tcp
Rule added

Signification : Seul ce sous-réseau peut utiliser le cache.

Décision : Si vous avez plusieurs VLANs, ajoutez des règles explicites par sous-réseau ; n’ouvrez pas simplement au monde.

Configuration client : pointer APT vers le cache

Sur chaque client Ubuntu, créez un petit extrait de config. Utilisez le DNS pour l’hôte de cache afin de pouvoir le déplacer plus tard sans visiter chaque machine.

cr0x@server:~$ echo 'Acquire::http::Proxy "http://aptcache.office.local:3142";' | sudo tee /etc/apt/apt.conf.d/02proxy
Acquire::http::Proxy "http://aptcache.office.local:3142";

Signification : Les acquisitions HTTP utiliseront votre cache.

Décision : Si vos sources sont HTTPS, vous pouvez toujours proxyiser HTTPS via un proxy HTTP, mais testez avec votre stack de sécurité réseau ; certains environnements bloquent CONNECT.

Valider que les clients frappent le cache

Exécutez update sur le client, puis vérifiez les logs sur le serveur de cache.

cr0x@server:~$ sudo apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Fetched 126 kB in 1s (148 kB/s)
Reading package lists... Done

Signification : La sortie client n’affichera pas toujours explicitement le proxy. La vérité est dans les logs du cache.

cr0x@server:~$ sudo tail -n 5 /var/log/apt-cacher-ng/apt-cacher.log
2025-12-29 11:03:11|O|250|archive.ubuntu.com|ubuntu|dists/noble-updates/InRelease
2025-12-29 11:03:12|O|411|archive.ubuntu.com|ubuntu|dists/noble-updates/main/binary-amd64/Packages.gz
2025-12-29 11:04:02|H|7|archive.ubuntu.com|ubuntu|dists/noble-updates/InRelease

Signification : Première requête récupérée depuis l’origine, la seconde exécution a touché le cache.

Décision : Si vous ne voyez jamais de hits, vos clients contournent peut-être le proxy à cause d’une config existante, de variables d’environnement ou de politiques réseau.

Hygiène opérationnelle qui le maintient rapide

• Mettez les données du cache sur un disque qui ne concurrence pas des logs lourds ou des bases de données.
• Surveillez l’utilisation disque et le nombre d’inodes (beaucoup de petits fichiers apparaissent).
• Prévoyez les redémarrages : assurez-vous que le service démarre rapidement et que les règles de pare-feu persistent.
• Restez simple. Le cache n’est pas un lieu pour exprimer votre créativité.

Utiliser correctement un proxy HTTP(S) d’entreprise

Certaines entreprises disposent déjà d’un proxy d’entreprise. S’il est local, sain et configuré pour ne pas saboter les téléchargements de paquets, vous pouvez le réutiliser. S’il est distant (boucle vers le siège), il est souvent la raison pour laquelle APT est lent dans les succursales.

Décider si vous devez contourner le proxy pour les dépôts Ubuntu

Si la politique le permet, contourner le proxy pour des miroirs de mise à jour connus peut être une grosse amélioration. L’approche correcte dépend de la manière dont votre organisation gère le contrôle d’egress. Si la sécurité exige une visibilité via proxy, déployez un cache/proxy sur site et laissez-le sortir de façon contrôlée.

Configurer le proxy explicitement (ne comptez pas sur les variables d’environnement)

cr0x@server:~$ sudo tee /etc/apt/apt.conf.d/02proxy >/dev/null <<'EOF'
Acquire::http::Proxy "http://proxy.office.local:3128/";
Acquire::https::Proxy "http://proxy.office.local:3128/";
EOF

Signification : APT utilisera le proxy indépendamment de l’environnement shell de l’utilisateur.

Décision : Centralisez cela via la gestion de configuration. Des réglages de proxy édités à la main sont la cause du « ça marche sur mon laptop » en version sysadmin.

Surveiller les effets secondaires de l’interception TLS

Si votre proxy fait de l’interception TLS, vous pouvez observer :

• Des temps de poignée de main TLS longs (le client attend que le proxy inspecte)
• Des blocages aléatoires sur de gros téléchargements (buffering/scanning)
• Des erreurs de type mismatch de hash si le chemin est modifié (rare, mais ça arrive)

APT est centré sur l’intégrité. C’est une bonne chose. Ça signifie aussi que des boîtes « utiles » qui réécrivent le contenu ne sont pas vos amies.

Deuxième petite blague (et la dernière) : La seule chose pire qu’un proxy lent est un proxy lent qui prétend accélérer votre trafic.

Miroir local complet : quand ça en vaut la peine (et quand ce n’est qu’un hobby)

Un miroir complet est l’option sérieuse pour les grands environnements. Il vous donne :

• Indépendance face aux pannes amont ou à l’instabilité des miroirs
• Contenu reproductible (ce que vous avez testé est ce que vous déployez)
• Meilleures histoires de conformité (ce qui était disponible à un moment donné)

Il vous donne aussi des corvées :

• Horaires de synchronisation, planification du stockage, détection de corruption
• Gestion des clés et flux de signature si vous réhébergez ou curez
• Plus de pièces à maintenir qui peuvent vous réveiller à 2h du matin

Règle pratique : si le problème du bureau est « trop de machines téléchargent la même chose », apt-cacher-ng le résout avec un minimum de cérémonie. Si le problème est « nous avons besoin de dépôts contrôlés et curatés », alors construisez un miroir/gestionnaire de dépôts et acceptez la charge opérationnelle.

Ajustements côté client qui aident vraiment

L’optimisation côté client est la partie où les gens perdent du temps. Un cache/proxy donne le gros gain. Cela dit, quelques ajustements clients peuvent réduire la douleur.

Choisir un meilleur miroir (mais n’en faites pas un sport)

Les paramètres par défaut d’Ubuntu sont généralement corrects, mais « généralement » n’est pas une garantie de performance. Le miroir adapté à votre FAI et site peut différer.

Méthode pratique : testez deux ou trois miroirs depuis le bureau pendant les heures de travail et en dehors. Si un miroir est rapide à 1h du matin et lent à 10h, c’est probablement congestion/peering, pas votre configuration. En bureau, vous voulez de la constance, pas le « meilleur cas ».

Limiter les surprises dues à unattended-upgrades

Les unattended upgrades sont utiles. Des mises à jour non coordonnées sur un site font découvrir que votre lien WAN n’est pas infini.

Échelonnez-les. Ou faites-les passer par un cache de site pour que le trafic WAN ne se produise qu’une fois.

Ne pas « optimiser » en désactivant les vérifications de signature

Si quelqu’un propose de contourner la vérification pour que les mises à jour soient « plus rapides », refusez comme vous refuseriez un parachute d’occasion. Les vérifications d’intégrité ne sont pas optionnelles ; elles sont l’essence même d’un gestionnaire de paquets.

Mini-récits d’incidents en production

Incident : la mauvaise hypothèse (« c’est le miroir ») qui a coûté une semaine

Une entreprise de taille moyenne avait une succursale où les mises à jour Ubuntu prenaient 20–40 minutes. L’équipe a supposé que le miroir Ubuntu était en cause, parce qu’un traceroute semblait « long » et un test de vitesse sur un site aléatoire était correct. Ils ont changé de miroirs trois fois et essayé de pinner vers un endpoint régional spécifique.

Rien n’a changé. Certains matins c’était acceptable ; les après-midis c’était horrible. Misère intermittente classique.

Le vrai coupable était le DNS. Le résolveur de la succursale renvoyait toutes les requêtes au siège, à travers une stack de sécurité qui journalisait et filtrait. Aux heures de pointe, ce chemin subissait des pics de latence et des timeouts occasionnels. Le modèle « beaucoup de petites requêtes » d’APT faisait paraître le miroir coupable parce que la résolution de nom du miroir stagnait avant que des octets ne circulent.

Ils ont corrigé le problème en ajoutant un résolveur DNS cache local dans la succursale puis en déployant apt-cacher-ng. Les changements de miroir ont cessé d’être un sujet. La catégorie de tickets a disparu. La leçon était douloureusement simple : ne blâmez pas le service visible tant que vous n’avez pas mesuré la dépendance invisible.

Optimisation qui a mal tourné : « un proxy pour tous les sites »

Une autre organisation a centralisé tout derrière un seul proxy central pour « meilleur contrôle ». Les succursales étaient configurées pour l’utiliser pour APT, les navigateurs, tout. Le proxy avait suffisamment de CPU et de mémoire, et son tableau de bord était vert. Très corporate.

Mais les succursales étaient séparées par des liens à haute latence. Le trafic APT est devenu une parade de tunnels CONNECT et de petites requêtes, chacune payant la taxe RTT. Pire, le proxy faisait du scanning de contenu qui bufferisait les téléchargements avant de les libérer, ce qui est parfait pour détecter des malwares, moins parfait pour un gestionnaire de paquets tirant des centaines de mégaoctets.

Ils ont essayé d’ajuster la concurrence et les timeouts d’APT. Ça l’a rendu plus bruyant, pas plus rapide. Certains clients commençaient à échouer plus souvent, parce qu’ils étaient devenus plus agressifs sur des connexions vouées à être lentes.

La solution a été d’arrêter de traiter les succursales comme des clients légers du siège. Ils ont déployé un petit cache/proxy par site (toujours contrôlé, toujours journalisé à l’egress), et ont laissé le cache local sortir. L’utilisation WAN a chuté, les plaintes d’utilisateurs ont baissé, et le proxy central a pu faire ce pour quoi il était bon : appliquer la politique sans être une ancre de performance à longue distance.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « hôte de cache comme du bétail »

Une équipe a déployé apt-cacher-ng sur des dizaines de sites. Ils ont fait quelque chose de profondément pas sexy : standardisé l’image VM de cache, utilisé le même port, les mêmes règles de pare-feu, la même disposition disque, et géré l’extrait proxy client via la gestion de configuration.

Ils ont aussi traité le cache comme jetable. Pas d’optimisation artisanale sur la machine. S’il devenait bizarre, ils le redéployaient. Les logs étaient centralisés ; les métriques basiques (utilisation disque, service up, taux de requêtes). Le contenu du cache n’était pas précieux. Il pouvait être reconstruit par l’usage.

Puis un site a eu un incident électrique qui a corrompu le disque du cache. Les utilisateurs ont recommencé à signaler des mises à jour lentes, mais rien d’autre n’était cassé. La VM de cache a été reconstruite depuis le template standard en moins d’une heure, le DNS a pointé la nouvelle instance, et les clients ont continué. Pas d’héroïsme, pas d’appel incident nocturne. Juste la récompense d’être ennuyeux.

Erreurs courantes : symptôme → cause → correction

1) apt update « bloque » sur Connecting/Waiting for headers

Symptôme : Il semble bloqué, puis continue finalement.

Cause : Lenteur DNS, overhead de poignée de main proxy, perte de paquets, ou boîte de sécurité qui bufferise les réponses.

Correction : Chronométrez les recherches DNS ; mesurez connect/TTFB avec curl ; déployez un cache LAN ; corrigez la perte WAN ; évitez les proxys en hairpin distants.

2) Les téléchargements commencent vite, puis ralentissent jusqu’à l’arrêt

Symptôme : Les premiers Mo vont bien, puis ça se bloque ou devient erratique.

Cause : Problèmes MTU/PMTUD, scanning/buffering du proxy, ou retransmissions Wi‑Fi.

Correction : Vérifiez le MTU et l’overhead VPN ; testez en filaire ; contournez ou localisez le proxy ; gardez le cache sur le LAN pour réduire la sensibilité au WAN.

3) « Hash Sum mismatch » ou erreurs de signature apparaissent de façon intermittente

Symptôme : APT refuse d’utiliser des métadonnées téléchargées.

Cause : Proxy transparent altérant le contenu, couche de cache cassée servant des fichiers partiels, ou fenêtres de synchronisation de miroir incohérentes.

Correction : Désactivez la mise en cache transparente pour le trafic de dépôt ; videz les caches proxy pour les objets affectés ; changez pour un miroir stable ; assurez-vous que le disque du cache est sain.

4) Cache déployé, mais aucun gain de vitesse

Symptôme : Les clients téléchargent toujours depuis Internet ; les logs du cache montrent surtout des misses.

Cause : Clients non configurés, dépôts HTTPS contournant le cache, ou un autre proxy qui écrase les paramètres.

Correction : Vérifiez apt-config dump ; standardisez le snippet dans /etc/apt/apt.conf.d/ ; validez avec les logs du cache et un client de test contrôlé.

5) apt-cacher-ng remplit le disque

Symptôme : L’hôte cache manque d’espace, puis les mises à jour échouent.

Cause : Pas de politique d’éviction/nettoyage, trop de dépôts (y compris PPAs), ou partition trop petite.

Correction : Donnez-lui un vrai disque ; réduisez l’expansion des dépôts ; définissez la rétention/nettoyage ; surveillez l’usage de /var/cache/apt-cacher-ng.

6) « 403 Forbidden » ou « Proxy Authentication Required » depuis APT

Symptôme : APT échoue immédiatement via le proxy.

Cause : Le proxy exige une authentification, bloque CONNECT, ou bloque certains domaines/chemins.

Correction : Utilisez un cache de site non authentifié ; configurez l’auth proxy dans APT seulement si la politique le permet et si vous pouvez gérer les identifiants en toute sécurité ; whitelistez les domaines de dépôt.

7) Les mises à jour sont rapides, mais les installations sont lentes

Symptôme : Les téléchargements se terminent rapidement ; puis « Unpacking… » prend une éternité.

Cause : Disque lent, IOPS épuisés sur stockage partagé, VMs CPU-throttled, ou triggers/postinst dpkg qui font du travail.

Correction : Séparez le chronométrage téléchargement vs installation ; déplacez les VMs vers un meilleur stockage ; investiguez les scripts postinst lourds ; évitez d’exécuter des mises à jour pendant les pics de charge.

Checklists / plan pas à pas

Pas à pas : passer de « APT est lent » à des mises à jour rapides dans un bureau

1. Choisissez un client représentatif (filiaire si possible) et exécutez Task 1 et Task 2 pour séparer lenteur métadonnées/téléchargement/installation.
2. Mesurez la latence DNS (Task 6 et Task 7). Si le DNS est lent, corrigez-le d’abord ; un cache ne réglera pas un délai de résolution de nom.
3. Vérifiez s’il existe un proxy (Task 10). S’il est distant, prévoyez de remplacer le comportement hairpin par un cache local.
4. Déployez apt-cacher-ng sur une petite VM au site (Task : installer, vérifier écoute, pare-feu).
5. Pointer 3–5 clients de test vers le cache via /etc/apt/apt.conf.d/02proxy.
6. Validez les hits du cache depuis les logs (Task 14). Ne déclarez pas victoire tant que vous n’avez pas de hits.
7. Déployez la config client via vos outils de gestion (Ansible, Puppet, Chef, scripts Intune, ce que vous utilisez). Les edits manuels ne montent pas en charge et ne se révoquent pas proprement.
8. Échelonnez les horaires de mise à jour ou conservez unattended-upgrades mais assurez-vous qu’ils passent par le cache.
9. Ajoutez une surveillance basique : service up, usage disque, et un trend simple hits/misses basés sur les logs.
10. Rédigez le plan de rollback : suppression en une ligne du snippet proxy, remise du DNS, et comment redéployer la VM de cache.

Checklist : à quoi ressemble un état « bon » après la correction

• apt update se termine en secondes sur des exécutions répétées.
• Les logs du cache montrent un bon mélange de fetch origine et de hits ; les hits dominent après le premier jour.
• L’utilisation WAN pendant les fenêtres de patch est plus plate (pas une scie de téléchargements répétés).
• Aucun client n’est codé en dur vers des miroirs externes sans raison.
• La configuration du proxy est cohérente et gérée au centre.
• L’hôte de cache a de la marge disque et ne swappe pas.

Checklist : à éviter (parce que ça crée de nouveaux problèmes)

• Gérer un proxy centralisé unique pour tous les sites sauf si chaque site a des liens à faible latence vers lui.
• Appareils de mise en cache transparents pour le trafic de dépôt, surtout avec HTTPS.
• Dizaines de PPAs sur la flotte. Chacun ajoute des requêtes de métadonnées et du churn de cache.
• « Optimisations » qui désactivent les vérifications ou assouplissent la sécurité d’APT.

FAQ

1) Ai-je vraiment besoin d’un serveur de cache pour seulement 20 machines ?

Si ces 20 machines se mettent à jour régulièrement et partagent le même lien WAN, oui — surtout si le bureau a de la latence, une bande passante limitée ou des coûts d’egress élevés. apt-cacher-ng est léger et s’amortit rapidement en réduisant l’attente et les pics sur le lien.

2) apt-cacher-ng fonctionnera-t-il avec des dépôts HTTPS ?

Souvent oui, via proxying (CONNECT). Son bon fonctionnement dépend des politiques du proxy et de l’interception TLS de votre environnement. Testez avec quelques clients et vérifiez les hits dans les logs. Si votre stack de sécurité casse CONNECT ou force l’interception, envisagez un miroir complet à l’intérieur du périmètre réseau.

3) Un miroir complet est-il toujours plus rapide qu’apt-cacher-ng ?

Pas toujours. Un miroir peut être très rapide, mais il est plus lourd à opérer. apt-cacher-ng est piloté par les requêtes : il met en cache ce que votre flotte utilise réellement. Pour la plupart des bureaux, c’est le bon compromis.

4) Pourquoi apt update est lent mais la vitesse de téléchargement de apt upgrade semble correcte ?

Parce que apt update concerne « beaucoup de petits fichiers » et est sensible au DNS et à la latence d’établissement de connexion. Un cache sur le LAN aide beaucoup car il transforme ces récupérations distantes en opérations locales.

5) Dois-je augmenter les téléchargements parallèles d’APT ?

Seulement après avoir corrigé le cache et le choix de miroirs. Augmenter la parallélisation peut aggraver un proxy congestionné ou un WAN instable. Mesurez d’abord ; ne noyez pas le problème sous des connexions.

6) Puis-je partager un cache entre plusieurs bureaux ?

Vous pouvez, mais ce n’est rarement optimal sauf si la latence inter-bureaux est faible et le réseau fiable. Le but est d’éliminer le RTT du chemin critique. Placez les caches près des clients.

7) Qu’en est-il des snaps — bénéficient-ils du cache APT ?

Non. Les téléchargements snap sont séparés d’APT et utilisent une infrastructure différente. Résolvez APT d’abord, puis évaluez la mise en cache/proxy des snaps séparément si elles posent aussi problème.

8) Comment savoir si le proxy est le goulot d’étranglement ?

Comparez les temps avec et sans proxy sur un hôte de test (ou en déplaçant temporairement la config proxy). Chronométrez aussi la connexion au proxy vs la connexion au miroir, et recherchez « Waiting for headers » dans la sortie debug d’APT.

9) Est-il sûr de mettre en cache des paquets Ubuntu ?

Oui, si vous mettez en cache correctement et sans altérer le contenu. Les paquets sont signés et validés via les métadonnées du dépôt. N’utilisez pas d’appareils « transparents » qui réécrivent les réponses. Gardez l’hôte de cache patché et restreint au réseau.

10) Quelle surveillance minimale dois-je ajouter pour l’hôte de cache ?

La disponibilité du service (systemd), l’utilisation disque, et le volume des logs. Si vous voulez une métrique supplémentaire, suivez le taux de hits du cache dans le temps ; il indique si les clients l’utilisent vraiment.

Conclusion : prochaines étapes pour cette semaine

Si les mises à jour d’Ubuntu 24.04 sont lentes dans votre bureau, traitez cela comme tout autre problème de performance en production : isolez la phase, mesurez les dépendances, puis corrigez le goulet le plus efficace. Pour les bureaux, ce goulet est souvent la latence par requête et les téléchargements dupliqués, pas la bande passante brute.

Faites ceci, dans l’ordre :

1. Exécutez la méthode de diagnostic rapide sur un client : séparez métadonnées vs téléchargement vs installation.
2. Mesurez le DNS et le comportement du proxy. Si le DNS est lent, corrigez-le d’abord.
3. Déployez apt-cacher-ng sur le LAN et pointez les clients via un snippet APT géré.
4. Vérifiez les hits du cache dans les logs et observez l’aplatissement de l’utilisation WAN pendant les fenêtres de patch.
5. Restez ennuyeux : build standard, surveillance basique, et procédure simple de redéploiement.

L’état final que vous visez n’est pas « APT est rapide sur ma machine ». C’est « les mises à jour sont un non-événement pour tout le bureau ». Voilà le type de gain de performance avec lequel on peut vivre.