Mettre à jour, c’est rarement (Linux) ou toujours (Windows) la roulette russe. Résumé d’une mise à jour vers Debian 10.

Introduction

Debian 10 “Buster” étant disponible depuis quelques temps, j’ai décidé de faire la mise à jour de mes postes. J’ai trouvé deux blagues mignonnes, sans impact réel pour mon usage.

Mise à jour “Express”

Comme la machine à mettre à jour propose uniquement un serveur FTP (via vsftpd), j’ai préféré passer par une installation “directe” plutôt que refaire de zéro.

Adaptation des sources

Il faut commencer par modifier le fichier /etc/apt/sources.d/sources.list et remplacer toutes les occurrences de “stretch” par “buster

Installation de la nouvelle version

Ensuite, il faut lancer un sudo apt-get update puis un sudo apt-get upgrade. Finalement, la mise à jour proprement dite se fait via sudo apt-get dist-upgrade.

Les blagues

Le serveur FTP ne répond plus!

C’est tout de même dommage d’avoir un seul service exposé et qu’il soit inutilisable après mise à jour (on dirait du Windows). Le problème vient du certificat SSL qui a changé de format, le serveur reporte l’erreur “500 OOPS: SSL: cannot load RSA private key”. Dans mon cas, le certificat étant “self-signed”, il faut en générer un nouveau.

La commande suivante permet de générer un nouveau certificat: sudo openssl req -x509 -nodes -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem -days 365 permet de générer le nouveau certificat dans le fichier vsftpd.pem. Bien sûr, si votre fichier /etc/vsftp.conf fait référence à un autre fichier, il faut adapter la commande.

“Il a fait bib bip, on a fait meuh, il a coulé à pic”

Pour une raison difficile à comprendre pour les gens normaux (mais somme toute logique, du fait de l’organisation du système), Debian “Buster” ne fait plus bip. Ni meuh. Alors on est d’accord que c’est bien plus con de ne plus avoir de service FTP sur un serveur FTP que de bip mais tout de même. J’utilise la commande “beep” à la fin de scripts un peu long (genre celui de backup), ce qui me permet de vaquer à d’autres occupations.

1er point à vérifier: est-ce que la rule sur “pcspkr-beep” est configurée?

Editer le fichier /lib/udev/rules.d/70-pcspkr-beep.rules, il doit contenir les lignes suivantes

1
2
# Give write access to the PC speaker to the user logged in on the current virtual console
ACTION=="add", SUBSYSTEM=="input", ATTRS{name}=="PC Speaker", ENV{DEVNAME}!="", TAG+="uaccess"

Dans mon cas, la rule est configurée. Mais toujours pas de bip. Saperlotte! Mais pourquoi? La réponse est plutôt simple et tient en trois lettres: ssh. Je suis connecté en ssh sur la machine et la rule précédente est valable uniquement pour les utilisateurs connectés “physiquement”.

Il faut ajouter un groupe système nommé “beep”: sudo addgroup --system beep

Ensuite, il faut ajouter une rule via le fichier /lib/udev/rules.d/90-pcspkr-beep.rules

1
2
# Add write access to the PC speaker for the "beep" group
ACTION=="add", SUBSYSTEM=="input", ATTRS{name}=="PC Speaker", ENV{DEVNAME}!="", RUN+="/usr/bin/setfacl -m g:beep:w '$env{DEVNAME}'"

Pour vérifier que la rule est correcte (en root): modprobe -r pcspkr; sleep 2; modprobe pcspkr

Finalement, rendre le ou les utilisateurs membres du groupe “beep”: sudo usermod gobo -a -G beep

Et voila!