Une vérification de disque peut rallonger énormément la durée du redémarrage. Vérifier :

df | awk '/^\/dev/\/mapper/ {print $1}' | xargs -I {} sh -c 'echo {}; tune2fs -l {}' | awk '/^\/dev/ {print $1} /^Filesystem state/ {print $3, " ",$4}'

Ouvrir une action de maintenance sur https://status.chapril.org/ :

• utiliser le modèle reboot cluster ;
• renseigner When is this maintenance scheduled for? ;
• ne pas remplir When did this maintenance complete? ;
• cocher Notifier les abonnés ?.

Envoyer un courriel aux listes :

From: François Poulain <fpoulain@metrodore.fr>
To: chapril@april.org
Subject: [Chapril] Reboot du cluster
Date: Sun, 4 Mar 2018 15:25:18 +0100
Reply-To: chapril@april.org
Sender: chapril-request@april.org
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)

Coucou,

Je vais rebooter le cluster pour tenir compte du dernier upgrade
noyal de sécurité.

François

-- 
François Poulain <fpoulain@metrodore.fr>

À l'aide du compte https://pouet.chapril.org/@chapriladmin :

Nous allons redémarrer les serveurs de notre Chapril https://chapril.org pour tenir compte des mises à jour.

L'opération prendra environ 30 minutes, durée pendant laquelle les services seront indisponibles.

Vérifier qui est présent sur les vm :

cluster_guests='admin allo bastion biliz dns drop grof lamp libreoffice ludo mail pad pouet sympa valise xmpp wiki'
for guest in $cluster_guests ;
do
    echo "===== $guest ====="
    cmd='for i in $(ps auxwww|grep "\-bash" | awk '\''{ print $2 }'\'' ); do cat "/proc/$i/environ" ; done 2>/dev/null |strings |grep GIT_AUTHOR_NAME | sort | uniq'
    ssh root@$guest.cluster.chapril.org "$cmd"
done

Pour le cas où un animateur travaillerait sur sa vm sans avoir vu ni le courriel ni status.chapril.org, envoyer un avertissement sur chaque machine.

./do.sh "wall 'Bonjour. Reboot SI Chapril à 13h15. Cpm.'"

• Mettre les hosts concernés en downtime
• Propager les downtimes en questions sur les services des hosts.

Le script suivant peut être utilisé pour couper le monitoring sur les hôtes et propager les downtimes sur les services hébergés. Les identifiants sont définis dans le fichier /etc/icinga2/conf.d/api-users.conf sur la machine admin.cluster.chapril.org, l'utilitaire jo (paquet Debian) est requis.

curl -k -s -S -i -u ${ICINGA_USER}:${ICINGA_PASSWORD} -H 'Accept: application/json' \
 -X POST 'https://icinga.chapril.org:5665/v1/actions/schedule-downtime' \
 -d "$(jo -p \
        pretty=true \
        type=Host \
        filter="match(\"persan*\", host.vars.hote)" \
        all_services=true \
        author="${GIT_AUTHOR_NAME}" \
        comment="Persan upgrade maintenance" \
        fixed=true \
        start_time=$(date +%s -d "+0 hour") \
        end_time=$(date +%s -d "+1 hour"))"

Noter la liste des VM actives pour comparer avec après le redémarrage.

# virsh list

Arrêter les VMs avant de redémarrer Persan:

cd /etc/libvirt/qemu
virsh list --state-running --name | xargs -I{} virsh shutdown {}; watch virsh list

reboot

Attendre que le système ait fini de démarrer (état à running) :

watch "systemctl status | grep State | head -1"

Démarrer les VM (⚠️ne pas redémarrer la VM template⚠️):

virsh list --state-shutoff --name  | grep -v template | xargs -I{} virsh start {}; watch virsh list

virsh list

Et comparer à la liste avant reboot.

Parfois les vm démarre mais en statut « degraded ». Il convient de vérifier par un :

./do.sh "systemctl status | head -2"

Et pour les vm n'ayant pas un statut « running », faire la commande suivante pour identifier le service en souffrance :

systemctl list-units

Si un problème subsiste alors les sondes devraient le faire apparaître dans Icinga. Vérifier que les alertes actives sont acceptables.

Éditer l'action de maintenance :

• Status : sélectionner complete ;
• When did this maintenance complete? : mettre la date et horaire de fin.