[>a2141.html>] [<a2139.html<] [^a2.html^]
Il protocollo NTP, Network Time Protocol consente di gestire una serie di nodi di rete in grado di sincronizzare tra loro l'orologio interno di ognuno. Il problema della gestione di un orologio uniforme a livello globale terrestre, non è facile da gestire, e nemmeno da descrivere. Lo scopo di questo capitolo è solo quello di mostrare in che modo utilizzare un servizio pubblico di questo tipo, per l'allineamento di un nodo di rete locale, con il quale si possono poi allineare gli altri nodi della propria rete.
La dipendenza dall'esterno per quanto riguarda la gestione degli orologi dei propri elaboratori, può costituire un problema di sicurezza. A questo proposito, il protocollo NTP offre anche la possibilità di utilizzare comunicazioni cifrate e altri sistemi di sicurezza, che comunque qui non vengono descritti. |
Per l'accesso a un servente NTP in qualità di cliente, e per la gestione di servente in proprio, si utilizza generalmente la «distribuzione NTP», rappresentata in pratica da un pacchetto che dovrebbe chiamarsi Xntp, o qualcosa del genere. I componenti più importanti di questa distribuzione sono il demone xntpd e il programma ntpdate.
Per lo scopo di questo capitolo, si accede a un servente NTP solo per ottenere l'informazione sull'ora esatta. Questo si ottiene molto facilmente con il programma ntpdate, che è anche in grado di aggiustare l'orario del sistema. Tuttavia, prima di vedere come funziona, occorre sapere dove è possibile ottenere tale servizio, e quali sono le regole di comportamento.
Trascurando i problemi legati alla gestione dei serventi NTP pubblici, quello che c'è da sapere è che questi sono organizzati in modo gerarchico a due livelli. L'accesso ai serventi del primo livello è da escludere in generale, a meno che questo serva per gestire un servizio privato dal quale attingono un numero molto grande di altri clienti; l'accesso ai serventi di secondo livello è consentito quasi a tutti (ognuno ha la sua politica), e in generale il risultato è accurato in modo più che sufficiente. Una volta chiarito che si accede di norma solo ai serventi di secondo livello, è opportuno sceglierne alcuni relativamente vicini (per quanto questo non sia indispensabile). L'elenco dei serventi NTP, con l'indicazione delle politiche rispettive, si trova a partire dall'URI <http://www.eecis.udel.edu/~mills/ntp/servers.html>. Ai fini degli esempi che si vogliono mostrare, verranno utilizzati gli indirizzi di fantasia a.ntp.dg, b.ntp.dg e c.ntp.dg.
ntpdate [opzioni] servente_ntp...
Lo scopo principale di ntpdate è quello di acquisire l'ora esatta da uno o più serventi NTP, e di aggiustare di conseguenza l'orario del sistema locale. L'utilizzo di ntpdate è adatto particolarmente per gli elaboratori che sono connessi alla rete esterna solo saltuariamente, dal momento che si può effettuare l'allineamento esattamente nel momento in cui ciò è possibile. Con l'uso delle opzioni necessarie, si può evitare che ntpdate allinei l'orario del sistema, limitandosi a mostrare il risultato; in questi casi, può essere utilizzato anche dagli utenti comuni, e non soltanto da root.
ntpdate non può essere avviato se è già in funzione il demone xntpd, o un altro analogo. |
-b
In condizioni normali, ntpdate può scegliere di aggiustare l'orario aggiungendo o sottraendo secondi, oppure intervenendo sulla frequenza della base dei tempi. Per evitare che venga scelta la seconda ipotesi, si utilizza questa opzione, che limita la possibilità alla modifica dell'orario senza altri interventi. In condizioni normali, dovrebbe essere preferibile l'uso di ntpdate con questa opzione.
-d
Invece di allineare l'orario del sistema, vengono mostrati i passi compiuti da ntpdate, a scopo diagnostico.
-q
Invece di allineare l'orario del sistema, mostra solo il risultato dell'interrogazione dei serventi.
-s
Invece di mostrare i messaggi sullo schermo, li devia nel registro del sistema, cosa che facilita l'utilizzo di ntpdate all'interno di script avviati automaticamente in circostanze determinate.
#
ntpdate -q a.ntp.dg b.ntp.dg c.ntp.dg
Visualizza l'ora esatta ottenuta dai serventi a.ntp.dg, b.ntp.dg e c.ntp.dg.
#
ntpdate -b a.ntp.dg b.ntp.dg c.ntp.dg
Aggiusta l'orario del sistema in base a quanto determinato dai serventi a.ntp.dg, b.ntp.dg e c.ntp.dg.
#
ntpdate -b -s a.ntp.dg b.ntp.dg c.ntp.dg
Come nell'esempio precedente, con la differenza che ogni segnalazione viene inviata nel registro del sistema.
La preparazione di un servente NTP per offrire il servizio solo alla propria rete locale, senza pretendere di contribuire alla rete NTP pubblica, è un'operazione abbastanza semplice. In particolare, se il nodo di rete che svolge tale ruolo è connesso continuamente alla rete esterna, si può usare lo stesso demone xntpd per allineare l'orologio dell'elaboratore in cui si trova a funzionare, senza bisogno di utilizzare ntpdate, che tra le altre cose non può essere avviato se è già attivo il demone.
Il funzionamento del demone xntpd dipende dalla configurazione stabilita attraverso il file /etc/ntp.conf
, mentre il programma ntpdate ignora questo file completamente.
Il file /etc/ntp.conf
è il più importante per ciò che riguarda il funzionamento del demone xntpd. È composto da direttive che occupano ognuna una riga; i commenti sono preceduti dal simbolo #, e nello stesso modo sono ignorate le righe bianche e quelle vuote. Senza entrare nel dettaglio delle varie direttive disponibili, viene descritto un esempio di massima.
# /etc/ntp.conf logfile /var/log/xntpd driftfile /var/lib/ntp/ntp.drift statsdir /var/log/ntpstats/ statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable # Serventi server a.ntp.dg server b.ntp.dg server c.ntp.dg
Con la direttiva logfile viene dichiarato il percorso del file delle registrazioni. Se non venisse utilizzata tale direttiva, i messaggi di questo tipo sarebbero diretti normalmente al registro del sistema. Nel caso dell'esempio, si fa riferimento al file /var/log/xntpd
.
logfile file_delle_registrazioni
Con la direttiva driftfile viene dichiarato il percorso del file utilizzato da xntpd per annotarsi lo scarto tra la frequenza dell'oscillatore locale e ciò che dovrebbe essere in realtà. Dal momento che xntpd deve poter cambiare nome al file e ricrearlo nuovamente, non può trattarsi di un collegamento simbolico. In generale, è sufficiente lasciare che sia xntpd a occuparsi di creare e gestire questo file.
driftfile file_dello_scarto
Con la direttiva statsdir viene dichiarato il percorso di una directory all'interno della quale possono essere creati dei file di informazioni statistiche, dichiarati a loro volta attraverso le direttive statistics e filegen.
statsdir directory_dei_file_statistici
I tipi di informazioni statistiche che si vogliono accumulare sono definiti attraverso la direttiva statistics, per mezzo di parole chiave prestabilite: loopstats, peerstats e clockstats. In generale, conviene attivare la gestione di tutti i tipi di informazioni statistiche, così come si vede nell'esempio.
statistics tipo_statistica...
Per abbinare all'accumulo di un tipo di statistica un file vero e proprio, si utilizza la direttiva filegen. Nell'esempio vengono creati tre file, con il nome corrispondente al tipo di statistica di cui si occupano.
filegen tipo_statistica [file file] [type tipo_di_analisi] [enable|disable]
Per la precisione, la direttiva filegen serve anche per definire il modo in cui vanno gestite diverse generazioni dei file che vengono creati. In pratica, il tipo stabilito attraverso l'argomento dell'opzione type, permette di indicare con quale frequenza devono essere archiviati i file. L'esempio mostra la richiesta di utilizzare generazioni giornaliere (l'argomento day), e questo, salvo esigenze particolari, dovrebbe andare bene in generale.
Infine, le direttive più importanti per lo scopo che ci si prefigge in questo capitolo, sono quelle che stabiliscono i nomi dei serventi di riferimento per ottenere le informazioni sull'orario. In generale, più sono questi serventi, meglio è.
server host [prefer]
Se uno di questi serventi viene considerato come quello più attendibile, si può aggiungere la parola chiave prefer, come si vede nello schema sintattico.
xntpd [opzioni]
Il demone xntpd serve da una parte per allineare continuamente l'orario del sistema locale, quando questo si trova connesso costantemente a una rete che gli consente di accedere ai suoi serventi di riferimento, in base alla configurazione del file /etc/ntp.conf
, con le direttive server. Dall'altra parte, questo demone offre anche il servizio NTP, basandosi sull'orologio del sistema locale.
In una rete chiusa, in cui non ci sia la possibilità di raggiungere altri serventi NTP, il demone xntpd può essere utile per allestire il proprio servizio NTP locale, in modo da assicurare la sincronizzazione degli altri elaboratori della propria rete.
All'interno di questi due estremi, in una rete in cui un nodo abbia saltuariamente accesso alla rete esterna, quel nodo può essere allineato (quanto possibile), al tempo di riferimento ottenuto dall'esterno, e quindi può fungere da servente locale per l'allineamento successivo della propria rete. Tuttavia, in questo caso si aggiunge il problema di procedere all'allineamento in base alle fonti esterne, esattamente nel momento in cui il collegamento è disponibile; ma per questo si utilizza prevalentemente il programma ntpdate, che però non può essere avviato quando il demone è già in funzione. Questo problema verrà riproposto in seguito.
-c file_di_configurazione
In generale, il file di configurazione utilizzato da xntpd è /etc/ntp.conf
. Con questa opzione si può indicare un file differente, oppure si può confermare la collocazione standard, nel caso i sorgenti siano stati compilati indicando posizioni differenti.
-d
La presenza di questa opzione, che può essere indicata anche ripetutamente, aumenta il livello di dettaglio delle informazioni diagnostiche che si ottengono (nel registro del sistema o in un altro file stabilito in base alla configurazione).
-l file_delle_registrazioni
Equivalente alla direttiva logfile nel file di configurazione.
-f file_dello_scarto
Equivalente alla direttiva driftfile nel file di configurazione.
-s directory_dei_file_statistici
Equivalente alla direttiva statsdir nel file di configurazione.
#!/bin/sh test -f /usr/sbin/xntpd || exit 0 case "$1" in start) echo -n "Avvio del servizio NTP: " /usr/sbin/xntpd echo ;; stop) echo -n "Disattivazione del servizio NTP: " killall xntpd echo ;; *) echo "Utilizzo: xntpd {start|stop}" exit 1 esac
L'esempio mostra uno script molto semplificato per l'avvio e la conclusione del servizio NTP, attraverso il controllo del demone xntpd. In pratica, il demone viene avviato senza opzioni di alcun tipo, confidando che legga correttamente il file di configurazione.
start) echo -n "Avvio del servizio NTP: " /usr/sbin/ntpdate -b -s a.ntp.dg b.ntp.dg c.ntp.dg /usr/sbin/xntpd echo ;;
Il pezzo di script che si vede rappresenta proprio il caso in cui viene avviato anche ntpdate prima di mettere in funzione xntpd. Si osservi il fatto che nella riga di comando devono apparire i serventi NTP, perché il file di configurazione di xntpd non lo riguarda.
Da quanto scritto fino a questo punto, in questo capitolo dedicato a NTP, si dovrebbe riuscire già a immaginare in che modo ci si potrebbe comportare per allestire un servizio NTP locale, sfruttando un accesso esterno saltuario, per esempio attraverso una connessione PPP con una linea commutata (PSTN o ISDN). Di certo, conviene collocare il servente locale nell'elaboratore che compie saltuariamente questa connessione, e che in quel momento ha un accesso normale all'esterno: nel momento in cui si può accedere alla rete esterna, si può utilizzare ntpdate per allineare l'orario dell'elaboratore stesso.
Come è già stato accennato, si pone un problema a causa del fatto che lo stesso elaboratore deve avere in funzione il demone xntpd, che impedisce l'avvio di ntpdate. Evidentemente, per risolvere il problema, occorre giocare sulla conclusione e riavvio del demone. La soluzione proposta è molto semplice: per prima cosa, lo script che avvia il demone xntpd nella procedura di inizializzazione del sistema, non deve comprendere anche l'avvio di ntpdate; quindi occorre predisporre l'avvio di ntpdate solo quando la connessione PPP è disponibile (capitolo 112 e successivi).
#!/bin/sh /etc/init.d/xntpd stop /usr/sbin/ntpdate -b -s a.ntp.dg b.ntp.dg c.ntp.dg /etc/init.d/xntpd start
Quello che si vede è uno script molto semplice, il cui scopo è quello di disattivare il servizio NTP, richiamando lo script /etc/init.d/xntpd
con l'argomento stop, prima di avviare ntpdate (eventualmente questo script potrebbe trovarsi in un'altra directory, e il suo nome potrebbe essere differente). Dopo l'allineamento, il servizio NTP viene riavviato in modo analogo.
Per fare in modo che tutto avvenga in modo automatico, questo script potrebbe essere avviato attraverso /etc/ppp/ip-up
, che è un altro script avviato automaticamente dal demone pppd ogni volta che si attiva una connessione PPP.
La predisposizione dei clienti della rete locale non dovrebbe costituire alcun problema: si dispone di un solo servente di riferimento e ci si può limitare a utilizzare ntpdate, eventualmente riavviandolo periodicamente attraverso Cron.
David L. Mills, Public NTP Time Servers