[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]


109. NTP

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'.

109.1 Accesso a un servente NTP

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'.

109.1.1 # ntpdate

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.

Alcune opzioni

-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.

Esempi

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.

109.2 Preparazione di un servente NTP per l'utilizzo locale

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.

109.2.1 Configurazione con /etc/ntp.conf

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.

109.2.2 # xntpd

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.

Alcune opzioni

-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.

Esempi

#!/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.

Alcune distribuzioni GNU/Linux predispongono uno script del genere, in cui, prima dell'avvio del demone `xntpd' eseguono `ntpdate' per iniziare con un orologio già allineato. In generale, questa potrebbe essere una buona idea; tuttavia, se questo script viene avviato quando non si può accedere ai serventi NTP a cui si vuole fare riferimento, `ntpdate' blocca la procedura di avvio troppo a lungo.

  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.

109.3 Gestire una rete locale collegata saltuariamente alla rete esterna

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 111 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.

109.4 Riferimenti

---------------------------

Appunti Linux 2000.04.12 --- Copyright © 1997-2000 Daniele Giacomini --  daniele @ pluto.linux.it


[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]