Rétrograder un paquet sous CentOS

En temps normal, le simple bon sens veut que l’on garde l’ensemble des paquets d’un système Linux à jour. Or, il arrive dans de rares cas que la mise à jour d’un paquet introduise un bug inédit qui nuit au bon fonctionnement du système. Sur les systèmes de qualité entreprise – c’est-à-dire censés fournir des mises à jour à faible risque – ce genre de phénomène est plutôt rare, mais ça arrive.

Pas plus tard qu’hier, j’ai eu l’occasion de découvrir un bug prohibitif dans la console d’administration de 389 Directory Server. Les espaces dans les textes de l’interface avaient disparu. Non content de cela, impossible de saisir ce caractère dans l’interface de gestion du serveur d’annuaires.

J’ai lancé une enquête sur 389-users@lists.fedoraproject.org et une autre sur centos@centos.org, et je me suis rendu compte que le problème venait de Java.

Ce genre de problème a d’ailleurs motivé les développeurs du projet 389 Directory Server à abandonner Java pour les versions subséquentes, au profit d’une simple console web.

Le bug en question a été signalé un peu partout, comme ici par exemple. En attendant qu’il soit résolu, la solution pragmatique consiste à rétrograder les paquets fautifs vers la dernière version qui ne présentait pas ce problème.

Voici les deux paquets Java dont je dispose pour l’instant.

$ rpm -qa | grep ^java-
java-1.8.0-openjdk-1.8.0.242.b08-0.el7_7.x86_64
java-1.8.0-openjdk-headless-1.8.0.242.b08-0.el7_7.x86_64

Sous Red Hat Enterprise Linux et CentOS, il existe plusieurs manières de rétrograder un paquet. Je vais me contenter de présenter la méthode manuelle, qui me semble plus simple.

Pour commencer, je crée un répertoire de téléchargement local pour mes paquets.

$ mkdir -v ~/RPMS
mkdir: created directory ‘/home/microlinux/RPMS’
$ cd ~/RPMS/

J’utilise le navigateur Links pour télécharger mes paquets.

$ links mirror.centos.org

En partant de la racine du miroir de téléchargement, je parcours successivement les répertoires centos-7 > 7.7.1908 > updates > x86_64 > Packages, j’effectue une recherche sur java-1.8.0-openjdk et je télécharge les deux paquets suivants.

• java-1.8.0-openjdk-1.8.0.222.b10-1.el7_7.x86_64.rpm
• java-1.8.0-openjdk-headless-1.8.0.222.b10-1.el7_7.x86_64.rpm

En temps normal, rpm -Uvh permet de mettre à jour un paquet. L’option --oldpackage autorise le rétrogradage.

$ rpm -Uvh --test --oldpackage java-*.rpm
Preparing...       ################################# [100%]

Le test s’est bien passé, je peux effectuer l’opération pour de bon.

$ sudo rpm -Uvh --oldpackage java-*.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:java-1.8.0-openjdk-headless-1:1.8################################# [ 25%]
   2:java-1.8.0-openjdk-1:1.8.0.222.b1################################# [ 50%]
Cleaning up / removing...
   3:java-1.8.0-openjdk-1:1.8.0.242.b0################################# [ 75%]
   4:java-1.8.0-openjdk-headless-1:1.8################################# [100%]

Le gestionnaire de paquets yum n’apprécie pas trop qu’on lui tire dans les pattes avec une invocation manuelle de rpm et nous affiche l’avertissement suivant pour les opérations subséquentes.

Warning: RPMDB altered outside of yum.

Pour remettre les pendules à l’heure, il suffit de faire ceci.

$ sudo rpm --rebuilddb
$ sudo yum history sync

Maintenant que nos deux paquets Java sont installés dans la bonne version, il nous faut empêcher leur mise à jour en ajoutant la ligne suivante au fichier /etc/yum.conf.

exclude=java-1.8.0-openjdk*

Il ne nous reste plus qu’à guetter les rapports de bugs de Red Hat pour une éventuelle résolution du problème.

La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.