Un yum update qui tourne mal ?

Ma politique est de mettre à jour mes serveurs Centos dès que je vois au moins 10 paquets à mettre à jour. Ça fait des années que ça dure, et je n’ai jamais eu de soucis.



Le yum update

Mais aujourd’hui, un application php sur Symfony a subitement cessée de fonctionner après un yum update …

Voici une partie de la liste des paquets mis à jour :

---> Package php72-php-bcmath.x86_64 0:7.2.19-2.el7.remi will be updated
---> Package php72-php-bcmath.x86_64 0:7.2.20-1.el7.remi will be an update
---> Package php72-php-cli.x86_64 0:7.2.19-2.el7.remi will be updated
---> Package php72-php-cli.x86_64 0:7.2.20-1.el7.remi will be an update
---> Package php72-php-common.x86_64 0:7.2.19-2.el7.remi will be updated
---> Package php72-php-common.x86_64 0:7.2.20-1.el7.remi will be an update
---> Package php72-php-fpm.x86_64 0:7.2.19-2.el7.remi will be updated
---> Package php72-php-fpm.x86_64 0:7.2.20-1.el7.remi will be an update
---> Package php72-php-imap.x86_64 0:7.2.19-2.el7.remi will be updated
---> Package php72-php-imap.x86_64 0:7.2.20-1.el7.remi will be an update
---> Package php72-php-intl.x86_64 0:7.2.19-2.el7.remi will be updated
---> Package php72-php-intl.x86_64 0:7.2.20-1.el7.remi will be an update
---> Package php72-php-json.x86_64 0:7.2.19-2.el7.remi will be updated
---> Package php72-php-json.x86_64 0:7.2.20-1.el7.remi will be an update
---> Package php72-php-mbstring.x86_64 0:7.2.19-2.el7.remi will be updated
---> Package php72-php-mbstring.x86_64 0:7.2.20-1.el7.remi will be an update
---> Package php72-php-mysqlnd.x86_64 0:7.2.19-2.el7.remi will be updated
---> Package php72-php-mysqlnd.x86_64 0:7.2.20-1.el7.remi will be an update
---> Package php72-php-pdo.x86_64 0:7.2.19-2.el7.remi will be updated
---> Package php72-php-pdo.x86_64 0:7.2.20-1.el7.remi will be an update
---> Package php72-php-xml.x86_64 0:7.2.19-2.el7.remi will be updated
---> Package php72-php-xml.x86_64 0:7.2.20-1.el7.remi will be an update

L’erreur dans l’application

Après cet update , Symfony me lâche une erreur à son habitude pas très parlante dans des cas complexes.

Error: During class fetch: Uncaught ReflectionException: Class Symfony\Component\Templating\Helper\Helper not found in vendor/symfony/security-bundle/Templating/Helper/LogoutUrlHelper.php:23

Rien dans le github de l’application question, que du workaround non fonctionnel sur Symfony dans ce cas là. Bref c’est la cata :/

Je descends les sauvegardes de la nuit, et exactement le même probleme. Donc le coupable est validé, c’est un des paquets ci-dessus.

Donc pas le choix il faut rollbacker le yum update.

La commande Yum history

Même dans le LPIC, je n’ai pas vu cette commande et j’avoue ne jamais avoir eu à le faire. Voici donc quelques explications :

[root@CentOs]# yum history
Loaded plugins: fastestmirror
ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
    68 | update                   | 2019-07-03 07:37 | E, I, U        |   21
    67 | update                   | 2019-06-18 07:44 | E, I, U        |   16

...

Dès qu’on utilise yum , l’historique s’incrémente avec l’action faite, son horodatage , et ce qu’elle a entrainé.

La liste des actions

Voici liste des abréviations de la colonne action.

Action Abréviation Description
Downgrade D Un paquet au moins a été mis à niveau à une version antérieure.
Erase E Un paquet au moins a été supprimé.
Install I Un nouveau paquet au moins a été installé.
Obsoleting O Un paquet au mons a été marqué comme obsolète.
Reinstall R Un paquet au moins a été réinstallé.
Update U Un paquet au moins a été mis à jour à une version plus récente.

La signification des Altered

Voici liste des abréviations de la colonne altered qui donnent le resultat de la transaction.

Symbole Description
< Avant que la transaction se termine, la base de données rpmdb a été modifiée hors de yum.
> Une fois la transaction terminée, la base de données rpmdb a été modifiée hors de yum.
* La transaction ne s’est pas terminée correctement.
# La transaction s’est terminée correctement, mais yum a retourné un code de sortie différent de zéro.
E La transaction s’est terminée correctement, mais une erreur ou un avertissement s’est affiché.
P La transaction s’est terminée correctement, mais des problèmes existaient déjà dans la base de données rpmdb.
s La transaction s’est terminée correctement, mais l’option de ligne de commande --skip-broken a été utilisée et certains paquets ont été ignorés.

La commande Yum undo (rollback)

Pour revenir en arrière, il suffit de taper la commande suivante qui compris l’id de transaction yum

 yum history undo 68

Le rollback gère la désinstallation des paquets à jour, puis installe les version précédentes . Ce n’est donc pas une restauration à base de cache mais une récupération des paquets via le dépôt.

Ca y est ! L’application php est de nouveau fonctionnelle !!! la prod est repartie et il va maintenant falloir trouver un correctif, mais cette fois ci au calme.

On peut d’ailleurs voir que notre rollback est lui même une transaction que l’on peut rollbacker ^^


[root@CentOs]# yum history
Loaded plugins: fastestmirror
ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
    69 | history undo 68          | 2019-07-03 10:27 | D, E, I        |   22
    68 | update                   | 2019-07-03 07:37 | E, I, U        |   21
    67 | update                   | 2019-06-18 07:44 | E, I, U        |   16

Yum history : allons plus loin

Les fonctionnalités de history sont vraiment puissantes et permettent de voir finement ce qu’il y a pour chaque transaction.

SQLite sous le capot

Yum history est magique mais pas tant que ca. Explorons les statisques

[root@CentOs]# yum history stats
Loaded plugins: fastestmirror
File        : //var/lib/yum/history/history-2018-05-16.sqlite
Size        : 2,478,080
Transactions: 69
Begin time  : Wed May 16 16:11:05 2018
End time    : Wed Jul  3 10:30:24 2019
Counts      :
  NEVRAC :  1,321
  NEVRA  :  1,321
  NA     :    543
  NEVR   :  1,321
  rpm DB :  1,321
  yum DB :  1,321
history stats

On vient de trouver la base sur laquelle il s’appuie, une base sqlite :

[root@CentOs]# ll /var/lib/yum/history/history-2018-05-16.sqlite
-rw-------. 1 root root 2478080 Jul  3 10:30 /var/lib/yum/history/history-2018-05-16.sqlite
[root@CentOs]# sqlite3 /var/lib/yum/history/history-2018-05-16.sqlite
SQLite version 3.7.17 2013-05-20 00:56:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .tables
pkg_rpmdb             trans_end             trans_with_pkgs
pkg_yumdb             trans_error           vtrans_data_pkgs
pkgtups               trans_prob_pkgs       vtrans_prob_pkgs2
trans_beg             trans_rpmdb_problems  vtrans_skip_pkgs
trans_cmdline         trans_script_stdout   vtrans_with_pkgs
trans_data_pkgs       trans_skip_pkgs

Quel utilisateur a fait la transaction ?

Pour savoir qui a fait la transaction ,il suffit de demander le summary, avec un id de commit ou même une plage

[root@CentOs]# yum history summary 66..69
Loaded plugins: fastestmirror
Login user                 | Time                | Action(s)        | Altered
-------------------------------------------------------------------------------
root <root>                | Last day            | D, E, I, U       |       43
root <root>                | Last 3 months       | E, I, U          |       17
history summary

L’historique pour un paquet

On peut encore aller plus loin en regardant le cycle de vie d’un paquet specifique. On retrouvera l’id du commit et ainsi la date et le compte qui l’a effectué.

[root@CentOs]# yum history package-list php72-php-intl*
Loaded plugins: fastestmirror
ID     | Action(s)      | Package
-------------------------------------------------------------------------------
    69 | Downgrade      | php72-php-intl-7.2.19-2.el7.remi.x86_64
    69 | Downgraded     |                7.2.20-1.el7.remi.x86_64
    68 | Updated        | php72-php-intl-7.2.19-2.el7.remi.x86_64
    68 | Update         |                7.2.20-1.el7.remi.x86_64
    63 | Updated        | php72-php-intl-7.2.18-1.el7.remi.x86_64
    63 | Update         |                7.2.19-2.el7.remi.x86_64
    61 | Updated        | php72-php-intl-7.2.17-1.el7.remi.x86_64
    61 | Update         |                7.2.18-1.el7.remi.x86_64
    59 | Updated        | php72-php-intl-7.2.16-1.el7.remi.x86_64            EE
    59 | Update         |                7.2.17-1.el7.remi.x86_64            EE
    57 | Updated        | php72-php-intl-7.2.15-1.el7.remi.x86_64            EE
    57 | Update         |                7.2.16-1.el7.remi.x86_64            EE
    53 | Updated        | php72-php-intl-7.2.14-1.el7.remi.x86_64
    53 | Update         |                7.2.15-1.el7.remi.x86_64

Épilogue

Armé de yum history, il est vraiment facile de recuperer un état du système stable. J’ai mené quelque recherches et il semblerait que la situation est beaucoup plus compliquée sur les Debian-like avec apt / apt-get.

Un article intéressant de Vivek sur nixCraft permet de reproduire la même fonctionnalité.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *