Coin web de Frédéric Péters

fpeters@0d.be

Montée vers Debian 12

15 juin 2023, 09:53

La nouvelle version de Debian est sortie samedi dernier, version 12, nom de code « bookworm », je ne comptais pas précipiter la mise à jour de mon serveur mais mardi j’avais déjà un message me demandant si c’était ok d’installer les outils panikdb/etc. sur cette version, je réponds tranquillement que non il vaut mieux attendre un peu mais ça me motive quand même à regarder à ça. Comme le serveur fait tourner le site de radio Esperanzah!, que le festival n’est que dans un mois et demi, je peux y aller là plus facilement que sur l’infrastructure de radio Panik, bien plus sollicitée.

Je prépare donc ça, je commence par la mise à jour de l’infrastructure de construction des paquets pour les divers modules, ça se fait sans accroche, arrive donc le moment de démarrer la mise à jour. Je suis très bon élève je commence par lire les notes de publication, section 4, mises à niveau depuis Debian 11, 4.4 - mettre à niveau les paquets, 4.4.5 - mise à niveau minimale du système, il est conseillé de démarrer avec une mise à jour sans suppression de paquets, je m’exécuté,

# apt upgrade --without-new-pkgs

et ça marche ah non ça échoue sur le paquet exim4-config (configuration pour exim4, le serveur de mails),

2023-06-14 12:29:28 Exim configuration error in line 899 of /var/lib/exim4/config.autogenerated.tmp:
  option "message_linelength_limit" unknown
Invalid new configfile /var/lib/exim4/config.autogenerated.tmp, not installing /var/lib/exim4/config.autogenerated.tmp to
/var/lib/exim4/config.autogenerated

Je vérifié chez moi, cette option existe bien, je vérifie dans la documentation, elle est bien là aussi.

Ce qui se passe ici c’est que le paquet exim4-config a été mis à jour mais pas les paquets exim4, la nouvelle configuration ne marche pas avec l’ancienne version, raté.

Je désactive l’option en question, ça passe, je décide alors de suivre par la mise à jour d’exim, histoire de pouvoir tout de suite remettre l’option et ne pas l’oublier, là ça met à jour correctement, je remets l’option, je vérifie que ça fonctionne, ça ne fonctionne pas.

2023-06-14 12:38:54 1q9Pm1-003mLf-13 ** fredp@0d.be <fpeters@0d.be>
  R=dovecot_router T=dovecot_virtual_delivery:
  Tainted arg 2 for dovecot_virtual_delivery transport command: 'fredp@0d.be'

Ce qui se passe ici c’est qu’exim a commencé à suivre de près les données transmises via le réseau et à ne plus autoriser leur utilisation directe dans la configuration, pour éviter toute une série de problèmes de sécurité. Ma configuration contient :

  command = /usr/lib/dovecot/deliver -d $local_part@$domain -f $sender_address

et $local_part (la partie fredp de fredp@0d.be) est une information qui vient directement du réseau (la requête de transmission d’un message vers telle adresse), plus question de l’utiliser directement comme ça, le problème doit être commun, il l’est tant que les premiers résultats de recherche donnent des gens saoulés en mode « on a déjà répondu 20 fois, cherchez dans les archives » ce qui n’est pas des masses pratique. Finalement je ne trouve pas de solution qui correspondrait pile à ma configuration mais j’arrive à bricoler quelque chose qui passe, la recommandation générale est de passer le terme recherché dans un fichier de correspondances, ça assurera que c’est une valeur sûre, je crée donc un fichier qui contient des lignes type :

fredp: fredp

et je modifie la ligne de configuration,

command = /usr/lib/dovecot/deliver -d ${expand:${lookup{$local_part}wildlsearch*@
{/etc/exim4/virtual.real/$domain_data}}}@${domain_data}

Et ça fonctionne. (l’autre partie modifiée c’est le paramètre -f retiré, après avoir lu qu’il n’était pas nécessaire, et l’utilisation de domain_data plutôt que domain, que j’avais ailleurs dans la configuration.)

Tant qu’à être dans les logs il restait un vieux message d’erreur sans conséquence mais c’est l’occasion de le corriger, surtout qu’une réponse directement applicable se trouve en ligne.  L’erreur :

Error: net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied

La réponse sur un vieux forum, en 2009, ajouter à dovecot (le serveur qui gère les boites mail),

service stats {
	unix_listener stats-reader {
		user = vmail
		group = vmail
		mode = 0660
	}

	unix_listener stats-writer {
		user = vmail
		group = vmail
		mode = 0660
	}
}

Avec tout ça le temps passe et le serveur n’est pas bien rapide, je n’ai pas tout l’après-midi et je ne voudrais pas partir avec le serveur en plan, je décide de continuer de manière ciblée seulement,

apt install apt
apt install nginx
apt install openssh-server
apt install bind9

tout ça fonctionne mais ça demande trop d’attention et de toute façon je dois partir.

Interlude train, réunion, terrasse, train.

Vue de la Meuse à Liège, sous un grand ciel bleu

Bord de Meuse et grand ciel bleu à Liège, 14 juin 2023

Interlude nuit.

Ça demandait donc trop d’attention et la suite j’ai un peu de temps devant moi pour réparer au cas où donc je lance en vrac,

apt full-upgrade

 

et bien sûr tout se passe bien pour cette partie.

Je termine par la montée de version postgresql, toujours aussi facile, puis un redémarrage du serveur, toujours aussi stressant,

64 bytes from skuf.0d.be (2001:41d0:8:9d87::1): icmp_seq=27 ttl=54 time=17.9 ms
64 bytes from skuf.0d.be (2001:41d0:8:9d87::1): icmp_seq=28 ttl=54 time=44.6 ms

(le stress monte)

64 bytes from skuf.0d.be (2001:41d0:8:9d87::1): icmp_seq=74 ttl=54 time=74.8 ms
64 bytes from skuf.0d.be (2001:41d0:8:9d87::1): icmp_seq=75 ttl=54 time=97.9 ms
64 bytes from skuf.0d.be (2001:41d0:8:9d87::1): icmp_seq=76 ttl=54 time=29.6 ms

En fait c’était bien rapide ce redémarrage.

Dernier tour pour vérifier que tout est ok, seul soucis rdio.space, j’avais oublié d’activer le démarrage automatique quand je l’ai basculé de site statique vers site django, je répare ça et c’est bon, le serveur est maintenant en Debian 12.