All links of one day
in a single page.
<Previous day - Next day>

rss_feedDaily RSS Feed
floral_left The Daily Shaarli floral_right
——————————— Monday 23, February 2026 ———————————
permalink
Mon Feb 23 22:37:17 2026

De Debian GNU/Linux Bookworm à Trixie / Debian 12 à 13

Comme à chaque passage à une nouvelle version de Debian GNU/Linux, voici un résumé de tout ce qui a foiré ou changé pour moi quand je suis passé à Trixie (Debian 13).

Comme d'hab, les changements majeurs sont dans la doc, tout comme la procédure de mise à jour.

Cette dernière se résume à :

apt update && apt -y dist-upgrade && apt clean && apt -y autoremove --purge
apt list '?obsolete'
apt list '?config-files'
apt list '?narrow(?installed, ?not(?origin(Debian)))'
apt-mark showhold
find /etc -iname '*.dpkg-old'
find /etc -iname '*.dpkg-new'
find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
dpkg --audit
Modifier sources.list
apt update
apt upgrade --without-new-pkgs
apt full-upgrade
reboot
apt autoremove --purge <ancien_noyau>
apt clean
apt modernize-sources
apt list '?obsolete'
apt list '?config-files'
apt list '?narrow(?installed, ?not(?origin(Debian)))'
find /etc -iname '*.dpkg-old'
find /etc -iname '*.dpkg-new'
find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'


APT

Pour les fichiers de sources de paquets, passage au format deb822 et à sources.list.d (qui existe depuis belle lurette, on est d'accord).

La doc préconise de le faire avant la mise à jour. Je préconise de le faire après, car alors l'outil apt modernize-sources sera disponible et fera tout le boulot. D'ailleurs, la doc préconise aussi cela 😀️. Via.


BIND

J'utilise BIND en tant que serveur DNS faisant autorité. J'attends qu'il mette à disposition exclusivement mes zones DNS (comme j'attends de mon serveur web qu'il serve uniquement le contenu que je lui indique). J'avais donc supprimé toutes les zones par défaut (.local, 127.in-addr.arpa, 168.192.in-addr.arp, etc. Pour la culture, lire ceci.).

Sauf que :

The default empty zones, and localhost forward and reverse zones have been removed from the package in favor of BIND 9 native directive empty-zones yes (that is on by default).

This include following configuration files:

  • /etc/bind/db.0
  • /etc/bind/db.127
  • /etc/bind/db.255
  • /etc/bind/db.empty
  • /etc/bind/db.local
  • /etc/bind/named.conf.default-zones
  • /etc/bind/zones.rfc1918

Please make sure you are not including any of these files in your configuration.

Dit autrement, pour ces zones, BIND va désormais répondre tout seul, sur la base d'une config intégrée (built-in), que ces zones sont vides. Mais moi je veux qu'il ne réponde pas du tout.

D'après la doc, la directive « empty-zones » n'existe pas. Il s'agit de « empty-zones-enable ».

Malgré ce que dit la doc de BIND et celle de Debian (ci-dessus), je constate que BIND 9 ne sert pas ces zones par défaut, il faut « empty-zones-enable yes; ».

Dans le doute, j'ai quand même ajouté empty-zones-enable no; dans la config.


curl

Implémente http/3. --http3 / --http3-only. Oui, ces commandes figuraient dans le manuel de la version livrée avec Debian 12 mais ça ne fonctionnait pas.


CRON

Running 'cron -N' triggers a cron tick, causing all job definitions to be processed immediately, and then exits. This is useful for testing changes in crontabs.


devilspie

Je l'utilise pour centrer mon terminal, celui de Mate, et en changer la taille. (Les paramètres de Mate permettent uniquement de changer la taille, pas de centrer.)

Le terminal de Mate a changé de nom au niveau du système de fenêtrage : « terminal » => « Mate-terminal ». Donc Devilspie ne sait plus agir dessus.

Dans ~/.devilspie/terminal.ds, j'ai changé la valeur du « application_name » :

(if (is (application_name) "Mate-terminal")
    (geometry "1800x900+55+60"))

J'ai aussi renommé ce fichier en mate-terminal.ds, simplement pour la cohérence.

Pour trouver le nouveau nom :

$ echo '(debug)' > ~/.devilspie/debug.ds
$ devilspie


Dovecot

D'une part, la réplication a été abandonnée. (Via Johndescs.)



D'autre part, la syntaxe du fichier de configuration a changé. (Via Aeris.)

Il doit commencer par :

dovecot_config_version = 2.4.0
dovecot_storage_version = 2.4.0

Des paramètres ont été renommés ou supprimés.

Dovecot propose un outil de migration. Je l'ai essayé et il y a eu des ratés.

Si ça peut aider, voici ce qui a changé chez moi :

  • Les blocs « userdb » et « passdb » doivent être nommés (le nom est sans importance) ;

  • « disable_plaintext_auth = yes » => auth_allow_cleartext = no (la valeur par défaut est « no ») ;

  • « ssl_cert » => ssl_server_cert_file (du coup, plus de redirection de fichier, « = </chemin/vers/certificat », juste « = /chemin/vers/certificat) ;

  • « ssl_key » => ssl_server_key_file (même remarque) ;

  • « ssl_prefer_server_ciphers = yes » => ssl_server_prefer_ciphers = server ;

  • « ssl_dh » => ssl_server_dh_file ;

  • Directive « sieve » d'un bloc « plugin » (qui permet d'indiquer l'emplacement du script Sieve d'un utilisateur) => directive path d'un bloc sieve_script qui doit être nommé ;

  • Directive « sieve_extensions » d'un bloc « plugin » (qui permet d'activer des extensions Sieve supplémentaires) => <nom_dune_extension> = yes (ex. « editheader = yes ») dans un bloc sieve_extensions.



Ces changements de syntaxe m'ont contraint à lire la documentation de Dovecot.

J'y ai découvert que le processus anvil peut être exécuté en non-root.

Il est également possible de faire tourner les processus d'authentification en non-root lorsqu'on utilise passwd+shadow, puisque tout membre du groupe d'utilisateurs shadow peut lire /etc/shadow.

Pour mettre tout cela en œuvre, j'ai ajouté ou modifié ceci dans ma config Dovecot :

service auth {
  user = dovecot
  group = shadow
}

service auth-worker {
  user = dovecot
  group = shadow
}

service anvil {
  user = dovecot
}

Ne pas oublier d'appliquer la conf : systemctl reload dovecot.


ejabberd et AppArmor

$ systemctl status --state failed
apparmor.service

journalctl -u apparmor crache le morceau :

apparmor.systemd[2371]: Restarting AppArmor
apparmor.systemd[2371]: Reloading AppArmor profiles
apparmor.systemd[2469]: profile has merged rule with conflicting x modifiers
apparmor.systemd[2469]: ERREUR lors du traitement Regex du profil su, le chargement a ?chou?
apparmor.systemd[2371]: Error: At least one profile failed to load
apparmor.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: apparmor.service: Failed with result 'exit-code'.
systemd[1]: Failed to start apparmor.service - Load AppArmor profiles.

Solution :

$ /sbin/apparmor_parser -N /etc/apparmor.d | grep su
surfshark
/usr/sbin/ejabberdctl//su

L'origine du problème serait donc le profil AppArmor pour ejabberd.

La date de dernière modification du fichier /etc/apparmor.d/usr.sbin.ejabberdctl est janvier 2021.

$ dpkg -S /etc/apparmor.d/usr.sbin.ejabberdctl
ejabberd: /etc/apparmor.d/usr.sbin.ejabberdctl

Ce fichier aurait été déposé par le paquet logiciel ejabberd.

C'était le cas dans Debian 12, mais plus dans Debian 13.

apt-file search /etc/apparmor.d/usr.sbin.ejabberdctl indique qu'il n'est pas déposé par un autre paquet.

Il reste la possibilité d'un fichier créé par un script de post-installation, mais apt install --reinstall ejabberd ne recrée par le fichier.

Un redémarrage d'ejabberd après un effacement du fichier fonctionne.

Conclusion : rm /etc/apparmor.d/usr.sbin.ejabberdctl.


Commande free

free: Used memory is Total - Available This means versions of free after 4.0.0 will show different Used values for older frees and some other system utilities.


Gajim

Problème majeur : plus d'icône dans la zone de notification, que ce soit avec mate ou avec gnome-shell.

Si on lance Gajim depuis le terminal, on obtient l'erreur :

(E) gajim.c.tray.linux     g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.kde.StatusNotifierWatcher was not provided by any .service files (2)

L'affichage de l'icône et du menu se fait désormais via DBus, via l'interface « org.kde.StatusNotifierItem » (= SNI). Source. Il faut donc que l'environnement de bureau implémente cette interface, écoute ces messages.

Solution :

If you remove mate-indicator-applet from the panel then you need to set enable-sni-support to True in org/mate/panel/general using dconf-editor.

mate-indicator-applet est bien installé. J'ai bien ajouté, à mon tableau de bord mate, tous les types d'applet de notification qui me sont proposés, sans succès. En revanche, l'activation de SNI dans dconf-editor, suivie d'un redémarrage, a fonctionné \o/.

Il faut s'assurer de ne pas avoir d'autres logiciels qui écoutent le bus SNI, comme ayatana-indicator-application ou ayatana-indicator-notifications ou taffybar ou…

Pour gnome-shell, il faut installer cette extension.



Quelques améliorations notables de Gajim (comparément à ma dernière critique) :

  • On peut désormais préciser une plage de dates pour la recherche par mot-clés dans l'historique de conversation ;

  • On peut remonter aussi loin que possible dans l'historique d'une conversation et autour des résultats de recherche : il n'y a plus de "saut" aléatoire vers le présent ou le lendemain du résultat ou… En revanche, la lenteur du défilement pour arriver jusqu'à l'extrait de conversation après un clic sur un résultat de recherche, pouah. Parfois, le défilement revient même en arrière, en direction du présent et il faut bourriner du clic sur le résultat de recherche pour arriver jusqu'à l'extrait de convers 🙁️.

  • On peut exporter ou supprimer l'historique pour un seul contact ;

  • Dans un historique exporté, il y a bien la date pour chaque message, même quand ils sont proches et qu'ils ont été groupés dans Gajim.

En revanche, dans l'interface Gajim, le copier-coller se fait toujours à la granularité d'un message 😑️.



Avant de rétablir l'icône de notification (supra), j'ai envisagé, à nouveau, de migrer vers un autre logiciel. Mais le seul autre logiciel livré dans Debian qui ne fasse que du Jabber, dino, refuse d'accepter les certificats x509 autosignés…


GnuPG

The upstream GnuPG project now explicitly and deliberately diverges from the OpenPGP standard. Debian's own workflows rely heavily on OpenPGP, and we ship several different OpenPGP implementations, so interoperability via standardization is a priority for the project.

While Debian still has significant dependencies on GnuPG, the version of GnuPG shipped in Debian will default to emitting only OpenPGP-compatible artifacts if at all possible. As of 2.4.7-4, the default is --compliance=openpgp, and we apply several patches to ensure that this mode is respected.

Rien de neuf, le chasme se confirme.


GnuPG et Yubikey

GnuPG 2.4 will not automatically fallback to the PC/SC driver for smartcard access if direct access fails. Users using pcscd for hardware access will need to explicitly disable the gnupg CCID driver. See --disable-ccid in scdaemon.1 and #1102717

Cela se confirme en pratique. GPG ne voyait plus ma Yubikey (présentation de mon installation et tutoriel ici).

$ gpg --card-status
gpg: selecting card failed: Aucun périphérique de ce type
gpg: la carte OpenPGP n'est pas disponible : Aucun périphérique de ce type

En VO :

$ gpg --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

Solution :

$ echo disable-ccid > ~/.gnupg/scdaemon.conf
$ pkill gpg-agent

(Pour le pkill : source.)


GnuTLS

Cette bibliothèque de fonctions n'est plus utilisée par apt, ni par openldap. Dommage, ça faisait de la diversité à openssl 🙁️.


hash-slinger

Ce paquet fournit les scripts tlsa, sshfp et openpgpkey.

Comme les scripts que j'avais mis dans /usr/local/bin, la version empaquetée est toujours la "vieille" 3.1. Elle affiche des avertissements python, ce qui est pénible quand on bosse sur ces sujets.

À partir de la version 3.5, ces logiciels utilisent les bibiothèques Python cryptography + ssl au lieu de M2Crypto (source). Or, elles rejettent les certificats x509 autosignés (alors que DANE TLSA permet de s'émanciper des autorités de certification…).

J'ai donc mis la version 3.4 de mi-2025 dans /usr/local/bin/.


hermetic-usr pattern

Je constate que de plus en plus de programmes suivent la bonne pratique « hermetic-user », c'est-à-dire qu'ils rangent leurs fichiers de conf par défaut dans /usr et permettent leur surcharge dans /etc, sous le même nom. Si ça peut éviter des comparaisons fastidieuses de fichiers de config lors des mises à jour majeures et/ou le recours à dpkg-divert, pourquoi pas 🙂️.

En l'espèce : NetworkManager (pour ses scripts dispatcher) ou iproute2 ou sysctl (même si cela est plutôt dû au passage à systemd-sysctl).


iproute2

La coloration des noms d'interfaces, des adresses (IPv4, IPv6, MAC), et de l'état physique (up/down) améliore grandement la lisibilité de la sortie des commandes ip […] \o/.

Cela m'a permit de réaliser que, dans ip l, « state UP » est l'état physique de l'interface réseau (câble branché, Wi-Fi actif, etc.), qu'il n'y a plus besoin de logiciel additionnel comme ethtool pour le constater, et que l'état logique figure entre « < » et « > » 😄️.


last, lastlog, wtmp

La doc expose qu'en prévision du bug de l'an 2038, les commandes last et lastlog ne sont plus fournies.

Conséquence : les commandes w et who n'affichent plus les utilisateurs connectés, excepté root. Je m'en sers sans cesse pour vérifier si je suis connecté en IPv4 ou IPv6, si je n'ai pas laissé traîner des sessions, et pour vérifier viteuf s'il n'y a pas d'intrus.



lslogins -uo USER,LAST-HOSTNAME affiche uniquement la dernière connexion d'un utilisateur, pas l'ensemble de ses connexions actives.



lastlog2 -a : idem. Et si l'on a une connexion SSH en IPv6 et l'autre en IPv4, que l'on clôture proprement celle en IPv6, alors c'est l'IPv6 qui lui est associée (ce qui est faux, on est désormais en IPv4). De plus, ça affiche « Last login: » après chaque « su - », ce qui est pénible.



wtmpdb last -p now fait le job. \o/ Dans mon ~/.bashrc, j'ai ajouté alias w="w ; wtmpdb last -p now guigui root".

J'ai eu quelques connexions rémanentes (« still logged in ») après des redémarrages du système ou des connexions SSH interrompues. J'ai attendu plusieurs jours : il ne semble pas y avoir de purge automatique. On peut nettoyer ça à la main : echo 'delete from wtmp where User = "guigui" and Logout is null and Login < <timestamp_sur_16_chiffres> ;' | sqlite3 /var/log/wtmp.db. (Pour rappel, pour obtenir un timestamp sur 10 chiffres à partir d'une date : date -d 'YYYY-MM-JJ HH:MM' +%s. Ajouter six « 0 » pour obtenir un timestamp 16.)



J'apprécie de lire « Last login: » lors d'une connexion SSH. PrintLastLog yes dans /etc/ssh/sshd_config.

Pour que ça continue, il ne faut pas supprimer /var/log/lastlog, contrairement à ce qu'expose la doc' sus-pointée.



On peut effacer /var/log/btmp* et /etc/logrotate.d/btmp.

Par défaut /etc/logrotate.d/wtmpdb conserve /var/log/wtmp.db pendant 4 ans ! Je trouve ça excessif, j'ai passé ça à 4 semaines, conformément à ma politique de journalisation :

# sed -i 's/yearly/weekly/' /etc/logrotate.d/wtmpdb
# dpkg-divert --add --no-rename --divert /etc/logrotate.d/wtmpdb.dpkg-dist /etc/logrotate.d/wtmpdb


mesg et write

The mesg(1) and write(1) programs are no longer provided. It is believed chatting between users is nowadays done using more secure facilities.

Même si je les ai très peu utilisés il y a un bail, ça fait quand même quelque chose, le temps que les moins de vingt ans, tout ça 💔️.


nftables

La syntaxe « meter » est dépréciée, mais nft continue de la traduire en limitation de débit utilisant des ensembles d'adresses IP (= des sets).

Ainsi, la règle « tcp dport 443 ct state new meter RL-HTTP-v6 { ip6 saddr and ffff:ffff:ffff:ffff:0000:0000:0000:0000 limit rate over 15/second } counter drop »
est traduite tcp dport 443 ct state new add @RL-HTTP-v6 { ip6 saddr and ffff:ffff:ffff:ffff:0000:0000:0000:0000 limit rate over 15/second burst 5 packets } counter drop.

Je précise que « burst » a toujours été implicitement défini à 5 par défaut. Le set « RL-HTTP-v6 » est créé automatiquement.

La présence d'une IP ou d'un réseau dans un tel set ne signifie pas qu'elle fait l'objet de la restriction de débit, simplement qu'elle a initié au moins une communication.

Ce qui m'ennuie, puisque toute IP qui a envoyé au moins un paquet restera dans le set possiblement indéfiniment (sauf redémarrage du système ou du pare-feu ou atteinte du nombre maximal d'éléments dans un set, ou…).

Pour y remédier, on peut :

  • Recourir à une limitation de débit qui n'utilise pas les sets : tcp dport 443 ct state new limit rate over 15/second counter drop. Cela n'est pas possible si l'on veut limiter des réseaux au lieu d'adresses éparses.

  • Créer soi-même l'ensemble en précisant la durée de vie des éléments avec la directive timeout. Le décompte commence dès l'ajout. La réception de futurs paquets tant que la durée de vie n'est pas écoulée ne la prolonge pas.


nginx

D'une part :

the "listen ... http2" directive is deprecated, use the "http2" directive instead



D'autre part, nginx met en œuvre http/3 \o/.

Tout est dans la doc : générale, module.

En gros, dans le bloc server de mon site web, j'ai ajouté :

  • listen [::]:443 default_server ipv6only=off quic reuseport; ;

  • quic_retry on;. Pour éviter les attaques par réflexion+amplification ;

  • ssl_early_data off;. Pour désactiver le mode O-RTT qui ne m'inspire pas confiance. Cloudflare le désactive aussi (source : expérimentation).

J'ai testé avec curl --http3-only. On peut aussi tester avec openssl s_client -quic -alpn h3 -connect <hostname>:443.



Pour que ça fonctionne avec un navigateur web, il faut ajouter un enregistrement DNS de type « HTTPS ». Contenu minimal : 1 . alpn="h2,h3" (« h2 » car mon nginx met également en œuvre HTTP/2). (Un CNAME est autorisé.) Ça devrait aussi fonctionner avec un entête HTTP « Alt-Svc », mais je n'ai pas essayé.

Si tu utilises un certificat x509 autosigné, il faut configurer Firefox : network.http.http3.disable_when_third_party_roots_found => false. Il faut redémarrer Firefox.

Firefox ne cherchera pas toujours l'enregistrement DNS HTTPS. Je pense qu'il garde cela dans les « données de site ». À chaque fois que j'ai effacé ces données, Firefox a demandé l'enregistrement DNS HTTPS et a fait des requêtes HTTP/3.


nicinfo

Client RDAP. Toujours pas disponible dans les dépôts officiels de Debian.

Erreur : « bash: /usr/local/bin/nicinfo : ne peut exécuter : le fichier requis n'a pas été trouvé ».

Même solution que la dernière fois.


OpenDNSSEC

Mon serveur met plus de 1 m 30 pour s'éteindre. Ça sent la tâche coincée et le délai d'attente par défaut de systemd-system.

journalctl -xn 5000 crache le morceau :

systemd[1]: opendnssec-enforcer.service: State 'stop-sigterm' timed out. Killing.
systemd[1]: opendnssec-enforcer.service: Killing process 567 (ods-enforcerd) with signal SIGKILL.
systemd[1]: opendnssec-enforcer.service: Main process exited, code=killed, status=9/KILL
systemd[1]: opendnssec-enforcer.service: Failed with result 'timeout'.

journalctl -u opendnssec-enforcer :

systemd[1]: Stopping opendnssec-enforcer.service - OpenDNSSEC Enforcer daemon...
░░ Subject: L'unité (unit) opendnssec-enforcer.service a commencé à s'arrêter
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ L'unité (unit) opendnssec-enforcer.service a commencé à s'arrêter.
ods-enforcerd[567]: free(): invalid pointer
ods-enforcerd[567]: Aborted:
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: gsignal
ods-enforcerd[567]: abort
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: __libc_free
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: Aborted
ods-enforcerd[567]: :
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: gsignal
ods-enforcerd[567]: abort
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: __libc_free
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown
ods-enforcerd[567]: unknown

Outcha, un logiciel qui termine en segfault ou en sigabrt (arrêt anormal), c'est mauvais signe.

Mais OpenDNSSEC n'est plus fourni par Debian, il n'est plus maintenu, et son remplaçant n'est pas encore prêt.

Donc il faut faire avec :

# mkdir /etc/systemd/system/opendnssec-{enforcer,signer}.service.d/

# tee /etc/systemd/system/opendnssec-{enforcer,signer}.service.d/override.conf << EOF
[Service]
TimeoutStopSec=5s
EOF

# systemctl daemon-reload


OpenRDAP

Le client RDAP OpenRDAP est enfin empaqueté dans Debian.

Il était temps puisque certains opérateurs de registre de noms de domaine ne mettent plus en œuvre l'ancien protocol whois, comme celui de .info.


OpenVPN

Le client OpenVPN 3 est désormais livré par Debian.

Il utilise la même architecture et la même bibliothèque de fonctions que les clients OpenVPN Connect ou OpenVPN for Android, ce qui peut être pratique pour homogénéiser un parc.

N'étant toujours pas une interface graphique, il ne permet pas d'émanciper les utilisateurs non-informaticiens d'un gestionnaire de réseau comme NetworkManager, ce qui est dommage vu les dysfonctionnements qu'ils peuvent induire (route par défaut IPv6 alors que la conf OpenVPN ne la prévoit pas, réseau qui bagotte = déco/reco intégrale, etc.).

Je ne l'ai pas essayé.


OpenSSH

sshd(8): this release disables finite field (a.k.a modp) Diffie-Hellman key exchange in sshd by default. Specifically, this removes the "diffie-hellman-group" and "diffie-hellman-group-exchange-" methods from the default KEXAlgorithms list. The client is unchanged and continues to support these methods by default.

Uhu l'échange de clés DHE qui se fait sortir. Donc, par défaut, il ne reste plus que les algos post-quantiques ML-KEM (ex. Kyber) et sntrup761, ainsi que les algos basés sur les courbes elliptiques curve25519 et ECDH 😮️.


sshd(8): the server will now block client addresses that repeatedly fail authentication, repeatedly connect without ever completing authentication or that crash the server. Operators of servers that accept connections from many users, or servers that accept connections from addresses behind NAT or proxies may need to consider these settings.

Plus besoin de fail2ban devant sshd ? Lire aussi. Via Johndescs.


sshd(8): several log messages have changed. In particular, some log messages will be tagged with as originating from a process named "sshd-session" rather than "sshd".

Ce changement a été pris en compte dans le filtre dédié du paquet fail2ban.


Paquets

Paquets qui n'existent plus, qui ont changé de nom, etc., en sus de ceux présentés séparément dans le reste de cet article.

  • dnsutils (clients DNS, dig, etc.) => bind9-dnsutils ; bind9utils (outils pour administrer un serveur DNS BIND, rncd, etc.) => bind9-utils ;

  • dstat => pcp, mais on passe d'un simple binaire à des démons qui tournent en permanence ;

  • mitmproxy n'est plus présent dans les dépôts officiels Debian stable (mais il est dans testing, donc il devrait revenir) ;

  • p7zip / p7zip-full => 7zip ;

  • vino / vinagre ne sont plus fournis (mais ils le sont dans unstable, donc ils devraient revenir).


pipx

Il a désormais l'option --global qui permet de rendre disponible sans effort un logiciel Python à tous les utilisateurs. \o/

Exemple : python upgrade --global yt-dlp.


Postfix

postfix[1501]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: support for parameter "smtpd_tls_dh1024_param_file" will be removed; instead, do not specify (leave at default)
postfix[1515]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: support for parameter "smtpd_tls_eecdh_grade" will be removed; instead, do not specify (leave at default)



Concernant « smtpd_tls_dh1024_param_file », la doc expose :

With Postfix ≥ 3.7, built with OpenSSL version is 3.0.0 or later, if the parameter value is either empty or "auto", then the DH parameter selection is delegated to the OpenSSL library, which selects appropriate parameters based on the TLS handshake. This choice is likely to be the most interoperable with SMTP clients using various TLS libraries, and custom local parameters are no longer recommended when using Postfix ≥ 3.7 built against OpenSSL 3.0.0.



Concernant « smtpd_tls_eecdh_grade », la doc consigne :

As of Postfix 3.6, the value of this parameter is always ignored, and Postfix behaves as though the auto value (described below) was chosen.
This feature is not used as of Postfix 3.6. Do not specify.



Donc j'ai supprimé ces deux directives.

La valeur de compatibility_level passe à 3.9.


saslauthd

Je l'utilise pour l'authentification submission de Postfix.

Lors de l'envoi d'un courriel :

postfix/smtpd[1496]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory
postfix/smtpd[1496]: warning: SASL authentication failure: Password verification failed

journalctl -u saslauthd -xn 20 crache le morceau :

systemd[1]: /usr/lib/systemd/system/saslauthd.service:8: PIDFile= references a path below legacy directory /var/run/, updating /var/run/saslauthd/saslauthd.pid → /run/saslauthd/saslauthd.pid; please update the unit file accordingly.
systemd[1]: saslauthd.service: Can't open PID file '/run/saslauthd/saslauthd.pid' (yet?) after start: No such file or directory
systemd[1]: saslauthd.service: start operation timed out. Terminating.
systemd[1]: saslauthd.service: Failed with result 'timeout'.
systemd[1]: Failed to start saslauthd.service - SASL Authentication Daemon.

À partir de Debian 13, saslauthd est lancé par une unit systemd (/usr/lib/systemd/system/saslauthd.service). Elle reprend les paramètres de /etc/default/saslauthd, dont un chemin différent où créer sa socket, écrire son numéro de processus, etc., si, comme moi, tu chroot ton postfix (ce qui est la config par défaut de Debian). Source d'inspiration.

Or, l'unit systemd cherche le numéro de processus hors du chroot postfix. Ne le trouvant pas, systemd-system considère que salsauthd n'a pas démarré correctement et le tue.

Solution :

# mkdir /etc/systemd/system/saslauthd.service.d/

# cat > /etc/systemd/system/saslauthd.service.d/override.conf << EOF
[Service]
PIDFile=/var/spool/postfix/var/run/saslauthd/saslauthd.pid
EOF

# systemctl daemon-reload
# systemctl restart saslauthd.service
# systemctl enable saslauthd.service



Ce problème m'a contraint à lire le manuel. J'y ai découvert :

saslauthd should be started from the system boot scripts when going to multi-user mode. When running against a protected authentication database (e.g. the shadow mechanism), it must be run as the superuser. Otherwise it is recommended to run daemon unprivileged as saslauth:saslauth […]

Or, nous avons vu avec Dovecot qu'il suffit de faire partie du groupe « shadow » pour être en capacité de lire /etc/shadow. On peut donc exécuter saslauthd avec un utilisateur dédié au lieu de root \o/ :

# adduser --system saslauth
# usermod -aG sasl saslauth

# chown saslauth /var/spool/postfix/var/run/saslauthd

# cat >> /etc/systemd/system/saslauthd.service.d/override.conf << EOF
User=saslauth
Group=shadow
EOF

# systemctl daemon-reload
# systemctl restart saslauthd.service


systemd-sysctl

Il ne lit plus /etc/sysctl.conf, qui a été déplacé en /usr/lib/sysctl.d/50-default.conf.

Les fichiers dans /etc/sysctl.d sont toujours pris en compte.


systemd-tmpfiles

/tmp est désormais stocké en RAM (= tmpfs) par défaut. (Je pensais que ça avait déjà été fait depuis longtemps 😮️.) C'est systemd-mount qui s'en occupe.

Le contenu de /tmp et de /var/tmp est régulièrement nettoyé automatiquement par systemd-tmpfiles. Pour /tmp, les fichiers plus vieux que 10 jours sont supprimés, 30 jours pour /var/tmp.

La doc de systemd-tmpfiles consigne que toutes les dates d'un fichier sont prises en compte dans la comparaison : mtime (dernière modification), atime (dernier accès), et ctime (modification des métadonnées). (La date de création aussi, mais elle n'est pas usuelle sur un système Gnu/Linux.)

Le processus de mise à jour depuis Debian 12 crée un fichier /etc/tmpfiles.d/tmp.conf qui empêche le nettoyage de /tmp.

Sur mes serveurs, seul nsd conserve des éléments relatifs aux transferts de zone dans /tmp. Un des fichiers est créé au démarrage et n'est plus actualisé ensuite. Donc systemd-tmpfiles pourrait l'écraser à tort. Donc je conserve /etc/tmpfiles.d/tmp.conf. Par cohérence, j'en fais de même sur mes autres serveurs.

Sur mon poste de travail, je suis dubitatif qu'une purge de /tmp n'engendre aucun problème, donc je conserve également /etc/tmpfiles.d/tmp.conf.


tldr

tldr est un client codé en Haskell pour récupérer des pages « too long; didn’t read » qui résument, par des exemples concrets, le manuel de tout un tas de programmes.

Il n'est plus livré par Debian, même dans testing et unstable, donc il ne reviendra probablement pas.



tldr-hs (hs = Haskell = probable continuité) est fourni uniquement dans unstable.



tealdeer (en rust, a priori) est empaqueté mais il reste bloqué sur :

Error: Could not update cache

Caused by:
0: Could not decompress downloaded ZIP archive
1: invalid Zip archive: Could not find EOCD



tldr-py est disponible dans les dépôts officiels Debian, mais il est tout autant cassé :

$ git clone https://github.com/tldr-pages/tldr.git ~/.tldr

$ tldr init
Input the tldr repo path(absolute path): /home/guigui/.tldr
Input your platform(linux, osx or sunos): linux
Initializing the config file at /home/guigui/.tldrrc

$ tldr update
Check for updates...
fatal : argument 'master' ambigu : révision inconnue ou chemin inexistant. [en VO : « fatal: ambiguous argument 'master': unknown revision or path not in the working tree. »]
Utilisez '--' pour séparer les chemins des révisions, comme ceci :
'git <commande> [<révision>...] -- [<chemin>...]'
Traceback (most recent call last):
[…]

De plus, la syntaxe change : tldr ls => tldr find ls. Flemme…

Et, de toute façon, le logiciel plante lorsqu'on consulte une fiche : FileNotFoundError: [Errno 2] No such file or directory: '/home/guigui/.tldr/pages/index.json. Le dossier « pages » est désormais sous-divisé par système…



Au final, j'ai suivi les instructions du site web officiel qui figure dans la description du paquet Debian tldr que j'utilisais jusque-là :

# pipx install --global tldr
$ tldr -u

Il fonctionne au poil et sans changement de syntaxe.

#Debian 12 à Debian 13

-