Distribution EOLE

Le script a été ajouté pour valider l’installation du module, la synchronisation étant nécessaire à son bon fonctionnement. Il avait été décidé d’interrompre l’instance si la synchronisation n’était pas obtenue. Il ne semble pas y avoir de nouveaux éléments en termes de fonctionnalités qui pousseraient à réviser ce choix.

Dans un premier temps, ajout d’un appel à la commande logger pour avoir une trace du décalage lors de la procédure de synchronisation.

À l’issue de plusieurs tests manuels ou automatisés (via la commande /mnt/eole-ci-tests/scripts/configure-vm.sh -M instance -C default), le premier constat est que l’échec n’est pas systématique. Le deuxième constat, c’est que le décalage tend à décroître.

Extraits des décalages en fonction du temps dans un cas d’échec, d’abord durant l’exécution du script puis après :

2024-10-29T14:34:27.934405+01:00 dc2.domseth.ac-test.fr ntp_synchro_check: offset with clock served by 192.168.232.2: 70.265761
2024-10-29T14:34:38.583118+01:00 dc2.domseth.ac-test.fr ntp_synchro_check: offset with clock served by 192.168.232.2: 70.265761
2024-10-29T14:35:21.201058+01:00 dc2.domseth.ac-test.fr ntp_synchro_check: offset with clock served by 192.168.232.2: 42.372908
2024-10-29T14:35:31.853924+01:00 dc2.domseth.ac-test.fr ntp_synchro_check: offset with clock served by 192.168.232.2: 42.372908
2024-10-29T14:36:03.808286+01:00 dc2.domseth.ac-test.fr ntp_synchro_check: offset with clock served by 192.168.232.2: 42.372908

2024-10-29T14:36:03.612523+01:00 dc2.domseth.ac-test.fr synchro_ref: message repeated 4 times: [ offset=42.372908]
2024-10-29T14:36:07.977641+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=9.285902
2024-10-29T14:36:16.703692+01:00 dc2.domseth.ac-test.fr synchro_ref: message repeated 5 times: [ offset=9.285902]
2024-10-29T14:36:18.885677+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=9.285902
2024-10-29T14:36:22.161500+01:00 dc2.domseth.ac-test.fr synchro_ref: message repeated 2 times: [ offset=9.285902]
2024-10-29T14:36:26.540240+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=9.285902
2024-10-29T14:36:28.730059+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=9.285902
2024-10-29T14:36:46.210089+01:00 dc2.domseth.ac-test.fr synchro_ref: message repeated 9 times: [ offset=9.285902]
2024-10-29T14:36:50.584025+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=9.285902
2024-10-29T14:36:57.140757+01:00 dc2.domseth.ac-test.fr synchro_ref: message repeated 2 times: [ offset=9.285902]
2024-10-29T14:36:59.329186+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=9.285902
2024-10-29T14:37:03.726169+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=9.285902
2024-10-29T14:37:05.924967+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=9.285902
2024-10-29T14:37:07.015765+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=9.285902
2024-10-29T14:37:10.300240+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=9.285902
2024-10-29T14:37:12.482416+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=1.147234
2024-10-29T14:37:14.676997+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=1.147234
2024-10-29T14:37:17.973787+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=1.147234
2024-10-29T14:37:21.250382+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=1.147234
2024-10-29T14:37:22.338089+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=1.147234
2024-10-29T14:37:23.431303+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=1.147234
2024-10-29T14:37:25.620132+01:00 dc2.domseth.ac-test.fr synchro_ref: message repeated 2 times: [ offset=1.147234]
2024-10-29T14:37:28.907469+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=1.147234
2024-10-29T14:37:30.008442+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=1.147234
2024-10-29T14:37:31.101791+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=1.147234
2024-10-29T14:37:33.284588+01:00 dc2.domseth.ac-test.fr synchro_ref: offset=1.147234
2024-10-29T14:37:37.647839+01:00 dc2.domseth.ac-test.fr synchro_ref: message repeated 3 times: [ offset=1.147234]

Dans cet exemple, il faut un peu plus d’une minute supplémentaire pour atteindre un niveau de synchronisation sous le seuil de tolérance de 5s.

La condition de succès actuellement implémentée est décrite comme ceci dans le code :
"offset en deça de la limite admise pour les échanges kerberos (5 minutes exprimées en millisecondes)"

L’offset est récupéré via la commande ntpq -c "rv <id> offset" et est donc exprimé en millisecondes.

Pour la comparaison via l’opérateur -gt, la conversion en entier est nécessaire mais la méthode utilisée semble faire deux hypothèses : la valeur originale a toujours le même nombre de décimales et la décimale la plus à droite représente les millisecondes.

En conséquence, la contrainte sur l’offset est beaucoup plus drastique que nécessaire. Par exemple, avec le code suivant

#!/bin/bash

offset=$(ntpq -c "rv 17767 offset")
echo "offset en millisecondes (unité par défaut) : $offset" 
echo "offset avec unité explicite : $(ntpq -u -c "rv 17767 offset")" 

# calcul opéré dans le script
offset="${offset//offset=}" # enleve 'offset='
offset="${offset#-}"        # enleve '-'
offset="${offset#+}"        # enleve '+'
offset="${offset//./}"      # enleve '.' multiple
echo "valeur comparée à 300000 : $offset => $([ "$offset" -lt 300000 ] && echo Vrai || echo Faux)" 

exit 0

on obtient les résultats suivants :

offset en millisecondes (unité par défaut) : offset=-0.152738
offset avec unité explicite : offset=-152.738us
valeur comparée à 300000 : 0152738 => Vrai

mais

offset en millisecondes (unité par défaut) : offset=-60999.461913
offset avec unité explicite : offset=-60.999461913s
valeur comparée à 300000 : 60999461913 => Faux

Dans ce dernier cas, le décalage est pourtant acceptable au sens kerberos.

La précédente correction (manipulations successives des chaînes de caractères) visant sans doute à simplifier la lecture par rapport à l’usage de la command sed, il semble bien venu de trouver un autre moyen de comparer la valeur du décalage avec le seuil d’acceptabilité pour kerberos.

Si la représentation du décalage donnée par la commande ntpq est stable (même unité, méme nombre de décimal) on peut changer l’unité de seuil (de milliseconde à nanoseconde).
Si on veut éviter de s’appuyer sur cette propriété, on peut également utiliser un autre type de test évitant l’étape de conversion et les erreurs potentielles. Par exemple, un test d’encadrement entre -300000 et 300000 avec bc.

Note : L'adresse du serveur NTP de DC2 est hestia.eole.lan. Ca ne devrait pas être DC1 ?

En tout cas, les tests passent mieux (beaucoup plantes toujours, mais plus loin). Il y a encore de temps en temps des erreurs de synchronisation. A voir, est-ce qu'on accepte l'état actuel ? Est-ce qu'on ajoute du log pour connaître l'état de synchronisation ?