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.
[cyklodev_summary]
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 updateL’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:23Rien 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 68Le 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 statsOn 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_pkgsQuel 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é.
