Projet

Général

Profil

Actions

Demande #3615

fermé

Détection automatique des services à redémarrer suite à un dist-upgrade

Ajouté par Christian P. Momon il y a presque 6 ans. Mis à jour il y a plus de 3 ans.

Statut:
Fermé
Priorité:
Normale
Assigné à:
Catégorie:
-
Version cible:
Début:
01/03/2019
Echéance:
% réalisé:

80%

Temps estimé:
Difficulté:
2 Facile

Description

Lorsqu'un paquet de lib est mis à jour, les services qui en dépendent ne sont pas nécessairement redémarrés par apt.

Demande :
1) installer needrestart sur toutes les machines (ajout dans les paquets April par défaut ?) ;
2) faire une sonde pour remonter si des services ont besoin d'être redémarrés ;
3) déployer la sonde sur toutes (?) les machines.

Sur #april-chapril le 01/01/2019 :

09:32 < cpm_screen> Les paquets suivants seront mis à jour : libssl1.0.2 php7.0 php7.0-cli php7.0-common php7.0-fpm php7.0-gd php7.0-intl php7.0-json php7.0-mbstring php7.0-mysql php7.0-opcache php7.0-readline php7.0-xml
09:32 < cpm_screen> ça semble n'être qu'un upgrade simple
09:42 < PoluX__> oui pas de soucis
09:42 < PoluX__> tu peux restarter apache2 pour vérifier que ça tourne après
09:44 < QGuLL> apache et nginx ?
09:52 < cpm_screen> hmmm, bah, c'est pas censé le faire tout seul ?
09:52 < QGuLL> si possible
09:52 < QGuLL> attend je regarde
09:54 < cpm_screen> j'ai fait l'upgrade sur la vm admin et le nginx a été démarré le 18 fév, donc a priori, là, pas redémarré
09:55 < cpm_screen> pareil pour apache sur la vm lamp
09:56 < cpm_screen> ok, je vais redémarré à la main les nginx et apache :D
09:58 < QGuLL> j'ai pas l'impression qu'il mette à jour la libssl utilisée
09:58 < QGuLL> nginx charge libssl1.1:amd64: /usr/lib/x86_64-linux-gnu/libssl.so.1.1
09:58 < QGuLL> après ptet qu'il la lit une fois et garde pas de filehandler ouvert dessus
10:00 < cpm_screen> vala, restarts fait
10:01 < cpm_screen> ou qu'il détecte un changement de fichier et recharge… 
10:01 < QGuLL> possible
10:08 < PoluX__> on devrait installer needrestart et monitorer ça d'ailleurs
10:09 < QGuLL> debian pense à tout /o\
10:10 < PoluX__> à défaut, un lsof | grep lib | grep '(deleted)$' en console donne des indices
10:10 < cpm_screen> hmmmm, mais c'est le boulot du gestionnaire de paquet ça, nan ? S'il met un paquet à jour et que celui-ci est utilisé par un service, il est censé redémarré le service tout seul, nan ? C'est fixé par les caractéristiques du paquets, nan ?
10:10 < PoluX__> cpm_screen: non
10:11 < PoluX__> cpm_screen: si tu upgrade libssl et que apache utilise libssl, le packageur de libssl est pas au courant
10:12 < PoluX__> et la dépendance peut dépendre de la config, donc pas évident de prévoir ça niveau packaging
10:13 < cpm_screen> apt-get (le gestionnaire de paquets) lui, il peut savoir, et du coup l'animateur du paquet libssl pourrait dire « rebooter tout ce qui m'utilise)
10:14 < PoluX__> cpm_screen: oui mais :)

Sur #april-admin le 01/01/2019 :

10:09 < olasd> QGuLL: vu la quantité de trucs à redémarrer ça va plus vite de reboot :p
10:17 < cpm_screen> olasd: huhu, hmmm, dis-moi, 1) dans le paquet d'upgrade, le packageur de libssl peut très bien dire à apt-get de redémarrer le service apache ? 2) les packageurs Debian le font quand c'est nécessaire, n'est-ce pas ?  :D
10:18 < olasd> QGuLL: You think you're some kind of Jedi, waving your hand around like that? I'm a Toydarian. Mind tricks don't work on me. :P
10:18 < olasd> cpm_screen: uniquement quand le fait d'avoir fait la mise à jour va casser le paquet utilisateur (c'est le cas de la libc quand les modules nsswitch changent d'interface)
10:19 < olasd> pour une mise à jour de sécurité dans une bibliothèque, non, il faut redémarrer les utilisateurs de la lib à la main (ou utiliser needrestart ou équivalent)
10:19 < cpm_screen> olasd: haaaaaaa, oki, du coup vaut mieux se poser la question après un apt-get dist-upgrade.
10:20 < cpm_screen> Voilà, needrestart, merciiiiiiiiiiiii <3
10:20 < QGuLL> olasd: mais si lsof ne révèle pas d'utilisation des lib, elles peuvent être copiées par le démon et le filehandler fermé, donc on voit pas si elles sont utilisées ?
10:22 < olasd> hum, aucune idée; le plus simple serait de regarder comment needrestart est implémenté ;p
10:22 < QGuLL> ou d'installer needrestart tout simplement
10:23 < olasd> (needrestart a aussi un hook apt donc il peut demander quels services redémarrer une fois qu'il a fait son job

Mis à jour par Quentin Gibeaux il y a presque 6 ans

Testé et approuvé :

(April) root@lamp:~# needrestart -p
WARN - Kernel: 4.9.0-8-amd64, Services: 3 (!), Containers: none, Sessions: none|Kernel=0;0;;0;2 Services=3;;0;0 Containers=0;;0;0 Sessions=0;0;;0
Services:
- apache2.service
- nagios-nrpe-server.service
- ssh.service
(April) root@lamp:~# needrestart -r a
Scanning processes...
Scanning candidates...
Scanning linux images...
Running kernel seems to be up-to-date.
Restarting services...
 systemctl restart apache2.service nagios-nrpe-server.service ssh.service
No containers need to be restarted.
No user sessions are running outdated binaries.
(April) root@lamp:~# needrestart -p
OK - Kernel: 4.9.0-8-amd64, Services: none, Containers: none, Sessions: none|Kernel=0;0;;0;2 Services=0;;0;0 Containers=0;;0;0 Sessions=0;0;;0
(April) root@lamp:~# needrestart -h
Unknown option: h
Usage:

  needrestart [-vn] [-c <cfg>] [-r <mode>] [-f <fe>] [-u <ui>] [-bkl]

    -v          be more verbose
    -q          be quiet
    -m <mode>   set detail level
        e       (e)asy mode
        a       (a)dvanced mode
    -n          set default answer to 'no'
    -c <cfg>    config filename
    -r <mode>   set restart mode
        l       (l)ist only
        i       (i)nteractive restart
        a       (a)utomatically restart
    -b          enable batch mode
    -p          enable nagios plugin mode
    -f <fe>     overwrite debconf frontend (DEBIAN_FRONTEND, debconf(7))
    -u <ui>     use preferred UI package (-u ? shows available packages)

  By using the following options only the specified checks are performed:
    -k          check for obsolete kernel
    -l          check for obsolete libraries

    --help      show this help
    --version   show version information

À déployer sur l'infra, et déployer également une sonde icinga qui lance un needrestart -p (qui fournit une réponse en syntaxe nagios).

Mis à jour par Quentin Gibeaux il y a presque 6 ans

  • Statut changé de Nouveau à En cours de traitement
  • % réalisé changé de 0 à 80

Déployé sur l'infra avec un check icinga.

On a donc des remontés quand des démons doivent être redémarrés

Quelques remarques :
- non installé sur drupal6, car la version jessie est trop vieille et n'a pas l'option nagios
- en panne sur 2 vm : bots sympa + guarana
- bots :

(April) root@galanga:~# /usr/lib/nagios/plugins/check_nrpe -t 90 -p 5666 -H 172.16.0.13 -c check_needrestart
NRPE: Unable to read output

#alors que sur la VM :
(April) root@bots:~# su - nagios -s /bin/bash
(April) nagios@bots:~$ sudo /usr/sbin/needrestart -pq
OK - Kernel: 4.9.0-8-amd64, Services: none, Containers: none, Sessions: none|Kernel=0;0;;0;2 Services=0;;0;0 Containers=0;;0;0 Sessions=0;0;;0

Idem que bots : guarana

Et sur sympa :

(April) root@sympa:~# needrestart -pq
Can't cd to (unreachable)/var/lib/sympa/expl: No such file or directory

Mis à jour par Christian P. Momon il y a environ 4 ans

Plus de problème constaté sur la vm sympa :

(April) root@sympa:~# needrestart -pq
OK - Kernel: 4.19.0-11-amd64, Services: none, Containers: none, Sessions: none|Kernel=0;0;;0;2 Services=0;;0;0 Containers=0;;0;0 Sessions=0;0;;0

Mis à jour par Quentin Gibeaux il y a plus de 3 ans

  • Statut changé de En cours de traitement à Fermé

les problèmes sont plus d'actualité

Mis à jour par Christian P. Momon il y a plus de 3 ans

  • Assigné à mis à Quentin Gibeaux
Actions

Formats disponibles : Atom PDF