Astuce Unix : Commandes NTP
ITworld.com – Envoyez vos questions sur Unix dès aujourd’hui !
Voir d’autres conseils et astuces Unix
La chronique de la semaine dernière présentait NTP, le Network Time Protocol et le concept de maintien d’une heure très précise. Si de nombreuses commandes existent pour aider les administrateurs système à maintenir une heure assez précise sur les systèmes qu’ils gèrent, les plus évidentes sont très limitées. Par conséquent, la plupart des réseaux souffrent d’importants écarts de temps système. Des différences de temps telles que celles présentées ci-dessous (prises sur un réseau réel) ne sont pas rares:
host01 : Thu Oct 14 10:50:23 EDT 2004
host02 : Thu Oct 14 10:43 :53 EDT 2004
host03 : Thu Oct 14 10:41:52 EDT 2004
host04 : Thu Oct 14 10:50:13 EDT 2004
host05 : Thu Oct 14 10:33:59 EDT 2004
host06 : Thu Oct 14 14:48 :17 GMT 2004
host07 : Thu Oct 14 10:52:04 EDT 2004 *
host08 : Thu Oct 14 10:52:33 EDT 2004
host09 : Thu Oct 14 10:49:55 EDT 2004
host10 : Thu Oct 14 10:33 :20 EDT 2004 *
host11 : Thu Oct 14 10:51:22 EDT 2004
Dans ces onze systèmes sondés séquentiellement, nous pouvons constater une variabilité considérable dans le temps rapporté. Bien que les sondages aient eu lieu sur une période de quelques secondes, les différences de temps sont considérablement plus grandes que quelques secondes. Il y a, en fait, une différence de 18 minutes et 44 secondes entre les heures les plus anciennes et les plus récentes. Si nous avions interrogé l’ensemble du réseau, l’écart entre les heures les plus anciennes et les plus récentes signalées aurait été encore plus important.
Pour forcer des systèmes tels que ceux-ci à être plus proches dans le temps, l’administrateur système peut utiliser l’une ou l’autre d’un certain nombre de commandes avec plus ou moins de succès.
La commande date
La commande date qui permet à l’administrateur système de définir la date et l’heure est la commande la plus évidente pour corriger l’heure d’un système, mais elle dépend du fait que l’administrateur système ait une référence temporelle assez précise. Cette commande est également exécutée sur un seul système à la fois. En utilisant la commande date pour synchroniser deux systèmes, il est peu probable que l’administrateur système parvienne à rapprocher les heures des systèmes à quelques secondes près. La commande date n’est clairement pas la commande de choix lorsque la synchronisation est importante. Et, sur un réseau comportant plusieurs centaines de systèmes, cette approche peut être à la fois fastidieuse et inexacte.
Si un administrateur système émettait une commande date dans une boucle telle que celle présentée ci-dessous, les heures du système seraient plus proches que celles présentées ci-dessus, mais continueraient à varier d’autant de secondes que la boucle a mis de temps à se terminer. Et, bien sûr, cette variation de temps sera de plus en plus significative si un mot de passe doit être saisi pour chaque commande ssh.
for host in `cat host_list`do ssh $host "date 10141045"done
La commande date n’est clairement que très peu utile pour synchroniser les systèmes. Les horloges des systèmes qui ont tendance à gagner ou à perdre du temps, même si ce n’est que de l’ordre de quelques secondes chaque jour, vont rapidement élargir à nouveau les écarts de temps. En outre, les systèmes configurés pour d’autres fuseaux horaires — comme le seul système indiquant l’heure en tant que GMT dans la liste présentée ci-dessus, verraient leurs horloges décalées de plusieurs heures si nous utilisions la commande date comme indiqué.
La commande rdate
La commande rdate, un bien meilleur choix pour synchroniser les horloges sur un réseau, nécessite qu’un administrateur système sélectionne un système accessible à son réseau, vraisemblablement un système qui conserve une heure assez précise à utiliser comme référence horaire pour le reste.
La boucle suivante donnerait de bien meilleurs résultats que celle présentée ci-dessus. Après tout, le temps nécessaire à la réalisation de cette boucle n’aura aucun effet néfaste puisque chaque commande rdate se synchronisera sur l’heure du serveur de référence au moment de l’exécution de cette commande.
for host in `cat host_list`do ssh $host "rdate timekeeper"done
En outre, la commande rdate ne remplace pas le fuseau horaire du système cible. Au lieu de définir littéralement l’heure à une valeur fournie sur la ligne de commande, rdate demande des données temporelles qui sont indépendantes du fuseau horaire. En d’autres termes, si vous exécutez « rdate » sur un système utilisant GMT, l’heure sur le système GMT sera réglée correctement.
La commande rdate est généralement exécutée au démarrage du système ou par cron une fois par jour ou une fois par heure pour aligner les horloges des systèmes sur un réseau local. Par rapport aux horloges système indisciplinées présentées précédemment, il s’agit d’une grande amélioration. Cependant, du point de vue de chaque système dont l’horloge est remise à zéro avec rdate, certaines choses très inhabituelles peuvent se produire. Les horloges peuvent sauter en avant ou en arrière dans le temps à chaque fois que la commande rdate est exécutée. Ce comportement peut conduire à des interprétations très étranges d’événements sensibles au temps.
Commandes NTP
NTP présente clairement des avantages considérables par rapport aux commandes date et rdate. Pour commencer, NTP fournit un moyen de synchroniser les horloges du système avec une précision inhabituelle et d’effectuer les ajustements nécessaires en douceur, en évitant les sauts dans le temps que des commandes telles que rdate provoquent souvent. Regardons de plus près.
NTP fournit deux commandes pour le réglage de l’heure : la commande ntpdate — qui définit l’heure du système à peu près comme le fait la commande rdate (c’est-à-dire, en référençant un système distant pour obtenir l’heure actuelle) et le démon NTP — ntpd ou xntpd — qui fournit un mécanisme beaucoup plus élaboré pour arriver et se synchroniser à l’heure adéquate.
La commande ntpdate — généralement utilisée, comme la commande rdate, au démarrage du système, à la demande ou périodiquement par cron — synchronise l’heure sur une base « ad hoc » de manière similaire à rdate. Cependant, la commande ntpdate présente deux avantages très importants par rapport à rdate.
Pour commencer, ntpdate fait référence à un serveur NTP, et pas seulement à un garde-temps fiable accessible sur votre réseau. Comme les serveurs NTP sont généralement liés à la hiérarchie NTP (et, en fin de compte, à une horloge atomique très précise), ils sont presque garantis d’être plus précis que n’importe quel serveur qui a simplement une bonne puce d’horloge.
Pour une autre, ntpdate peut collecter un certain nombre d’échantillons de temps à partir d’un certain nombre de sources de temps (c’est-à-dire plusieurs serveurs NTP) et ensuite sélectionner le temps qui semble le plus précis. Ainsi, non seulement la commande ntpdate référence une source de temps qui est plus susceptible d’être précise que celles sélectionnées pour être utilisées avec rdate, mais elle référence un certain nombre de ces systèmes et applique un processus de sélection sophistiqué.
Une commande ntpdate pourrait ressembler à ceci:
# ntpdate 129.6.15.28
14 Oct 10:52:41 ntpdate : adjust time server 129.6.15.28 offset -0.003350 sec
En fait, si la commande ntpdate est installée sur votre système (/usr/sbin/ntpdate sur la plupart des systèmes Solaris), vous pourriez essayer cette commande ntpdate exacte dès maintenant. Le serveur de référence dans cet exemple est un serveur NTP au NIST à Gaithersburg, Maryland.
Alternativement, vous pourriez essayer une commande ntpdate comme ceci :
# ntpdate 129.6.15.28 216.200.93.8 208.184.49.9
14 Oct 14:57:41 ntpdate : ajuster le serveur de temps 216.200.93.8 offset 0.015733 sec
Dans ce cas, plusieurs serveurs NTP sont interrogés.
Le démon NTP
Bien que la commande ntpdate fournisse un niveau de contrôle de l’heure qui est un ordre de grandeur meilleur que rdate, le démon NTP va un pas de géant au-delà de ntpdate avec ses algorithmes sophistiqués pour maximiser la précision et la fiabilité. Utilisé correctement, le démon NTP utilise également une quantité minimale de ressources réseau — nous examinerons cette question la semaine prochaine.
Le démon NTP fournit des algorithmes sophistiqués qui synchronisent en douceur les horloges du système par un processus d’approximation successive. Plus le démon fonctionne longtemps, plus l’heure du système correspond à celle de sa source. Il effectue des ajustements importants rapidement, puis des ajustements plus petits au fil du temps pour éviter de dépasser l’heure adéquate.
Il peut falloir des minutes ou des heures à NTP pour s’approcher d’un niveau de précision fin mais, une fois que c’est le cas, la fiabilité de l’heure sur le système peut être étonnamment précise. Cela étant dit, la précision temporelle de NTP est toutefois liée en fin de compte à la précision des sources de temps qu’il référence. Chaque serveur NTP tente de se synchroniser sur l’UTC (c’est-à-dire le temps universel coordonné) en utilisant la meilleure source de temps et le meilleur chemin de transmission disponibles. Si l’ensemble des serveurs référencés transmettent des heures qui ne sont pas très proches les unes des autres, NTP considérera qu’un ou plusieurs de ces serveurs de temps sont en panne et les écartera. Ainsi, pour obtenir une heure précise en utilisant NTP, votre choix de serveurs de temps doit être précis.
Les nouveaux venus à NTP doivent noter que l’exécution du processus du démon NTP ne fait PAS nécessairement d’un système un serveur NTP. Le fait qu’un système compatible NTP joue le rôle de client ou de serveur est déterminé par les fichiers de configuration du démon sur ce système — ce que nous examinerons dans la chronique de la semaine prochaine.
Cette histoire, « Unix Tip : Commandes NTP » a été initialement publiée par ITworld .
.