Configuration des clients

Nous avons un (ou deux) serveurs NTP de strate 3, qui vont nous servir pour la synchronisation du reste de notre parc. Suivant les conditions, nous aurons une stratégie différente.

Les serveurs

Ces machines étant destinées en principe à tourner 24/7, il nous suffira d'installer le paquet ntp et configurer le daemon pour qu'il se synchronise sur notre (nos) serveur(s) de référence. Ces serveurs deviendront à leur tour des serveurs NTP de strate 4, qu'il sera d'ailleurs inutile d'utiliser comme tels.

Les stations de travail

L'outil ntpdate sera sans doute le mieux approprié. Cet outil se contentera d'aller chercher l'heure « juste » sur nos serveurs chaque fois que l'interface réseau sera activée. Il y aura naturellement une dérive, mais un système comme GNU/Linux arrive à rendre cette dérive négligeable sur la durée de service. Nous partons du principe que les stations de travail sont re-démarrées au moins une fois par semaine et que nous disposons d'une distribution Debian ou dérivée (les autres distributions doivent toutefois fournir des outils similaires).

Le paquet ntpdate contient l'utilitaire du même nom, ainsi qu'un « wrapper » maison : ntpdate-debian, qui ne fait qu'appeler ntpdate en tenant compte des informations définies dans le fichier /etc/default/ntpdate.

Ce « wrapper » sera appelé à chaque initialisation d'une interface réseau (script dans /etc/network/if-up.d).

Au final, avec un /etc/default/ntpdate de cette forme :

# The settings in this file are used by the program ntpdate-debian, but not
# by the upstream program ntpdate.

# Set to "yes" to take the server list from /etc/ntp.conf, from package ntp,
# so you only have to keep it in one place.
NTPDATE_USE_NTP_CONF=no

# List of NTP servers to use  (Separate multiple servers with spaces.)
# Not used if NTPDATE_USE_NTP_CONF is yes.
NTPSERVERS="<serveur1> [<serveur2>]"

# Additional options to pass to ntpdate
NTPOPTIONS=""

Où ça se complique

Debian installe par défaut le client DHCP isc-dhcp-client. Ce client utilise un script pour effectuer les opérations de mises à jour de la configuration IP. Suivant le contexte, ce script ne sera pas le même et les répercutions seront « slightly » différentes.

Sans network-manager

La configuration du réseau se construit à partir des informations fournies dans /etc/network/interfaces. Si une interface doit être configurée par DHCP, alors dhclient est lancé, qui lui-même fait appel à dhclient-script. Ce dernier exécute entre autres choses, des scripts présents dans les répertoires /etc/dhcp/dhclient-enter-hooks.d/ et /etc/dhcp/dhclient-exit-hooks.d/.

Il se trouve que ntpdate a installé dans /etc/dhcp/dhclient-exit-hooks.d/ un script ntpdate. Ce dernier va contrôler si le serveur DHCP a envoyé l'option ntp-servers (option 042). Si c'est le cas, il récupère l'information et la place dans /var/lib/ntpdate/default.dhcp.

Le wrapper ntpdate-debian, s'il trouve cette information, l'utilisera de préférence à ce qui peut être indiqué dans /etc/default/ntpdate.

Au final, ntpdate adoptera le comportement suivant, par ordre de priorité :

  1. serveurs NTP fournis dans la configuration ntp si elle existe et que le choix n'a pas été désactivé dans /etc/default/ntpdate ;
  2. serveurs NTP fournis par DHCP si l'option existe ;
  3. serveurs NTP indiqués dans /etc/default/ntpdate.

Avec network-manager

Networkmanager va invoquer dhclient, mais en lui imposant un script qui est en réalité un binaire : /usr/lib/NetworkManager/nm-dhcp-client.action, dhclient-script étant ainsi mis hors-jeu.

Les scripts présents dans dhclient-enter-hooks.d et dhclient-exit-hooks.d sont ignorés, l'information éventuellement issue de DHCP n'est pas reportée dans /var/lib/ntpdate/default.dhcp et au final ntpdate adoptera le comportement suivant, par ordre de priorité :

  1. serveurs NTP fournis dans la configuration ntp si elle existe et que le choix n'a pas été désactivé dans /etc/default/ntpdate ;
  2. serveurs NTP indiqués dans /etc/default/ntpdate.

Le DHCP se fatigue pour rien et c'est sans doute dommage.

ntp et ntpdate

Les deux ne font pas bon ménage et il est bon de préciser quelques points qui peuvent poser des problèmes sur les serveurs :

  • ntpdate ne fonctionnera pas si le service ntpd est actif ;
  • ntpd refusera de synchroniser une horloge dont la dérive est supérieure à 1000 secondes, estimant que dans ce cas, l'intervention d'un administrateur est indispensable.

Autrement dit, dans le cas d'un serveur qui a été arrêté et qui, lors de son re-démarrage présenterait une dérive importante de son horloge, ne se mettra pas à l'heure avec le seul service ntpd. Il est donc bienvenu d'exécuter ntpdate avant d'avoir démarré le service ntpd ou à défaut, après avoir momentanément arrêté ce service.

Le service ntpd dispose tout de même d'une option qui permet d'outrepasser la règle des 1000 secondes (ntpd -g) Voici ce que dit le man à ce propos :

-g Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options.

Pour ceux qui n'aiment pas ntpdate, l'option -q permet à ntpd fonctionner d'une manière similaire. Le man dit :

-q Exit the ntpd just after the first time the clock is set. This behavior mimics that of the ntpdate program, which is to be retired. The -g and -x options can be used with this option. Note: The kernel time discipline is disabled with this option.

Ainsi, ntpd invoqué avec les options -g et -q devrait permettre de se passer de ntpdate sur les stations de travail. Je n'ai pas testé ce mode de fonctionnement.

Sur une distribution de type Debian, les options d'appel de ntpd sont configurées dans le fichier /etc/default/ntp.