Suggerimento Unix: Comandi NTP
ITworld.com – Invia le tue domande su Unix oggi stesso!
Vedi altri consigli e suggerimenti su Unix
La scorsa settimana la rubrica ha introdotto NTP, il Network Time Protocol e il concetto di mantenimento dell’ora molto accurato. Mentre esistono numerosi comandi per aiutare gli amministratori di sistema a mantenere un tempo abbastanza accurato sui sistemi che gestiscono, i più ovvi sono molto limitati. Di conseguenza, la maggior parte delle reti soffre di grandi discrepanze nel tempo del sistema. Differenze di tempo come quelle mostrate qui sotto (prese da una rete reale) non sono rare:
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
Solo all’interno di questi undici sistemi sondati in sequenza, possiamo vedere una notevole variabilità nel tempo riportato. Mentre i sondaggi hanno avuto luogo nell’arco di pochi secondi, le differenze di tempo sono considerevolmente più grandi di pochi secondi. C’è, infatti, una differenza di 18 minuti e 44 secondi tra il primo e l’ultimo tempo riportato. Se avessimo sondato l’intera rete, il divario tra il primo e l’ultimo tempo riportato sarebbe stato ancora più ampio.
Per forzare sistemi come questi a una maggiore vicinanza temporale, l’amministratore di sistema può usare uno qualsiasi dei numerosi comandi con vari gradi di successo.
Il comando date
Il comando date che permette all’amministratore di sistema di impostare data e ora è il comando più ovvio per correggere il tempo su un sistema, ma dipende dal fatto che l’amministratore di sistema abbia un riferimento temporale abbastanza preciso. Anche questo comando viene eseguito un sistema alla volta. Usando il comando date per sincronizzare due sistemi, è improbabile che un sysadmin riesca ad avvicinare i tempi dei sistemi più di qualche secondo l’uno dall’altro. Il comando data non è chiaramente il comando da scegliere quando la sincronizzazione è importante. E, su una rete con diverse centinaia di sistemi, questo approccio può essere sia noioso che impreciso.
Se un amministratore di sistema emettesse un comando data in un ciclo come quello mostrato qui sotto, i tempi del sistema sarebbero più vicini di quelli mostrati sopra, ma continuerebbero a variare di tanti secondi quanti ne occorrono per completare il ciclo. E, naturalmente, questa variazione di tempo sarà sempre più significativa se è necessario inserire una password per ogni comando ssh.
for host in `cat host_list`do ssh $host "date 10141045"done
Il comando date è chiaramente solo minimamente utile nella sincronizzazione dei sistemi. Gli orologi di sistema che tendono a guadagnare o perdere tempo, anche se solo nell’ordine di un paio di secondi ogni giorno, amplieranno rapidamente i divari temporali di nuovo. Inoltre, i sistemi configurati per altri fusi orari — come il sistema che riporta l’ora come GMT nella lista mostrata sopra, avrebbero i loro orologi sballati di ore se usassimo il comando date come mostrato.
Il comando rdate
Il comando rdate, una scelta di gran lunga migliore per la sincronizzazione degli orologi su una rete, richiede che un amministratore di sistema selezioni un sistema accessibile alla sua rete, presumibilmente uno che mantenga un orario abbastanza accurato da usare come riferimento temporale per gli altri.
Il seguente ciclo darebbe risultati molto migliori di quello mostrato sopra. Dopo tutto, il tempo richiesto per completare questo ciclo non avrà alcun effetto dannoso poiché ogni comando rdate si sincronizzerà con l’ora sul server di riferimento quando quel comando viene eseguito.
for host in `cat host_list`do ssh $host "rdate timekeeper"done
Inoltre, il comando rdate non sovrascrive il fuso orario sul sistema di destinazione. Invece di impostare letteralmente l’ora ad un valore fornito sulla linea di comando, rdate richiede dati temporali che sono indipendenti dal fuso orario. In altre parole, se si esegue “rdate ” su un sistema che usa GMT, l’ora sul sistema GMT sarà impostata correttamente.
Il comando rdate viene generalmente eseguito all’avvio del sistema o tramite cron una volta al giorno o una volta all’ora per allineare gli orologi sui sistemi in una LAN. Rispetto agli orologi di sistema indisciplinati mostrati prima, questo è un grande miglioramento. Tuttavia, dal punto di vista di ogni sistema il cui orologio viene resettato con rdate, possono accadere alcune cose molto insolite. Gli orologi possono saltare avanti o indietro nel tempo ogni volta che il comando rdate viene eseguito. Questo comportamento può portare ad alcune interpretazioni molto strane di eventi sensibili al tempo.
Comandi NTP
NTP ha chiaramente notevoli vantaggi rispetto ai comandi date e rdate. Per esempio, NTP fornisce un modo per sincronizzare gli orologi di sistema con una precisione inusuale e per fare gli aggiustamenti richiesti senza problemi, evitando i salti nel tempo che comandi come rdate spesso causano. Diamo un’occhiata più da vicino.
NTP fornisce due comandi per la regolazione del tempo: il comando ntpdate — che imposta l’ora del sistema come fa il comando rdate (cioè, facendo riferimento ad un sistema remoto per ottenere l’ora corrente) e il demone NTP — ntpd o xntpd — che fornisce un meccanismo molto più elaborato per arrivare e sincronizzarsi all’ora corretta.
Il comando ntpdate
Il comando ntpdate — generalmente usato, come il comando rdate, all’avvio del sistema, su richiesta o periodicamente tramite cron — sincronizza l’ora su una base “ad hoc” in modo simile a rdate. Tuttavia, il comando ntpdate ha due vantaggi molto importanti rispetto a rdate.
Per prima cosa, ntpdate fa riferimento ad un server NTP, non solo ad un affidabile timekeeper accessibile alla tua rete. Poiché i server NTP sono generalmente legati alla gerarchia NTP (e, in ultima analisi, a un orologio atomico altamente accurato), sono quasi garantiti per essere più precisi di qualsiasi server che ha semplicemente un buon chip orologio.
Inoltre, ntpdate può raccogliere un certo numero di campioni di tempo da un certo numero di fonti temporali (cioè, più server NTP) e poi selezionare il tempo che appare più accurato. Quindi, non solo il comando ntpdate fa riferimento a una fonte di tempo che è più probabile sia accurata di quelle selezionate per l’uso con rdate, ma fa riferimento a un certo numero di tali sistemi e applica un sofisticato processo di selezione.
Un comando ntpdate potrebbe essere simile a questo:
# ntpdate 129.6.15.28
14 Oct 10:52:41 ntpdate: adjust time server 129.6.15.28 offset -0.003350 sec
In effetti, se il comando ntpdate è installato sul vostro sistema (/usr/sbin/ntpdate sulla maggior parte dei sistemi Solaris), potreste provare proprio questo comando ntpdate adesso. Il server di riferimento in questo esempio è un server NTP al NIST di Gaithersburg, Maryland.
In alternativa, si potrebbe provare un comando ntpdate come questo:
# ntpdate 129.6.15.28 216.200.93.8 208.184.49.9
14 Oct 14:57:41 ntpdate: adjust time server 216.200.93.8 offset 0.015733 sec
In questo caso, vengono interrogati più server NTP.
Il demone NTP
Mentre il comando ntpdate fornisce un livello di controllo del tempo che è un ordine di grandezza migliore di rdate, il demone NTP fa un passo da gigante oltre ntpdate con i suoi sofisticati algoritmi per massimizzare la precisione e l’affidabilità. Usato correttamente, il demone NTP usa anche una quantità minima di risorse di rete — esamineremo questo problema la prossima settimana.
Il demone NTP fornisce sofisticati algoritmi che sincronizzano dolcemente gli orologi di sistema attraverso un processo di approssimazione successiva. Più a lungo il demone funziona, più l’ora del sistema corrisponde a quella della sua fonte. Fa grandi aggiustamenti rapidamente e poi aggiustamenti più piccoli nel tempo per evitare di superare l’ora corretta.
Potrebbero volerci minuti o ore perché l’NTP si avvicini a un livello di precisione fine ma, una volta che lo fa, l’affidabilità del tempo sul sistema può essere sorprendentemente accurata. Detto questo, l’accuratezza temporale di NTP è comunque legata in ultima analisi all’accuratezza delle fonti temporali a cui fa riferimento. Ogni server NTP cerca di sincronizzarsi con UTC (cioè Universal Coordinated Time) usando la migliore fonte di tempo e il miglior percorso di trasmissione disponibili. Se l’insieme dei server di riferimento trasmette tempi che non sono in stretta prossimità l’uno dell’altro, NTP considererà uno o più di questi server temporali come guasti e li sconterà. Quindi, per ottenere un orario accurato usando NTP, la vostra scelta dei time server deve essere accurata.
I nuovi arrivati a NTP dovrebbero notare che l’esecuzione del processo del demone NTP NON rende necessariamente un sistema un server NTP. Se un sistema abilitato a NTP gioca il ruolo di client o di server è determinato dai file di configurazione del demone su quel sistema — qualcosa che esamineremo nella colonna della prossima settimana.
Questa storia, “Unix Tip: Comandi NTP” è stato originariamente pubblicato da ITworld.