apt-get install ntp

che installa i pacchetti server e client, qualora mancassero. Se vogliamo dare il debug delle richieste ntp (generalmente dal client verso il server) installiamo anche:

apt-get install ntpdate

A questo punto, la configurazione va effettuata nel file /etc/ntp.conf, che contiene le sia le direttive per il client ntp che per il server. Le direttive che dobbiamo modificare sono quelle relative a server, in cui specificheremo il nostro/i nostri server ntp ed a restrict che serve a limitare i client che possono richiederci le informazioni ntp. Per quanto riguarda la direttiva server, basta modificare, qualora sia necessario, le righe già presenti ed avere qualcosa del tipo:

server 0.debian.pool.ntp.org iburst dynamic
server 1.debian.pool.ntp.org iburst dynamic
server 2.debian.pool.ntp.org iburst dynamic
server 3.debian.pool.ntp.org iburst dynamic

Per quanto riguarda la direttiva restrict, se bisogna consentire a tutti l’accesso, basta commentare le righe presenti, es:

#restrict 127.0.0.1
#restrict ::1

oppure inserire dopo la direttiva restrict gli IP a cui consentire le connessioni ntp.

Ora bisogna verificare di aver aperta la porta 123 UDP in ingresso sul server e chiaramente la porta 123 in uscita sui vari client.
Infine basta riavviare il servizio con:

/etc/init.d/ntp restart

Consiglio di attendere qualche minuto affinché il server si sincronizzi con il proprio server e succesivamente si potrà procedere alla configurazione dei vari client.

La configurazione del client sarà la stessa vista in precedenza, solo che nella direttiva server, andrà inserito l’IP o il FQDN del server ntp che abbiamo appena creato

Comandi utili

Aggiornare l’orario del client, ipotizzando che il server si chiami vs-prod. Digitare sul client:

ntpdate -q vs-prod

Avere un debug della richiesta al server ntp da parte del client:

ntpdate -d vs-prod
28 Apr 12:00:42 ntpdate[30065]: ntpdate 4.2.4p6@1.1549-o Wed Feb 18 18:27:27 UTC 2009 (1)
transmit(10.109.7.200)
receive(10.109.7.200)
transmit(10.109.7.200)
receive(10.109.7.200)
transmit(10.109.7.200)
receive(10.109.7.200)
transmit(10.109.7.200)
receive(10.109.7.200)
transmit(10.109.7.200)
server 10.109.7.200, port 123
stratum 5, precision -20, leap 00, trust 000
refid [10.109.7.200], delay 0.02582, dispersion 0.00000
transmitted 4, in filter 4
reference time:    d0ebcd4f.ed0dbe8e  Thu, Apr 28 2011 11:54:07.925
originate timestamp: d0ebceda.6bb5c9bc  Thu, Apr 28 2011 12:00:42.420
transmit timestamp:  d0ebceda.6c4c5974  Thu, Apr 28 2011 12:00:42.423
filter delay:  0.02597  0.02583  0.02582  0.02583 
         0.00000  0.00000  0.00000  0.00000 
filter offset: -0.00244 -0.00245 -0.00245 -0.00245
         0.000000 0.000000 0.000000 0.000000
delay 0.02582, dispersion 0.00000
offset -0.002454

28 Apr 12:00:42 ntpdate[30065]: adjust time server 10.109.7.200 offset -0.002454 sec

Più il valore di stratum è basso, e più il nostro server si aggiorna in modo diretto con i server ntp ufficiali; pertanto se il valore di stratum è troppo alto (diciamo oltre 10), le sincronizzazioni saranno non molto accurate e si potrebbe addiritutra avere l’errore: “no server suitable for synchronization found”

Conoscere lo stato del server, es vs-prod, da un client. Digitare sul client:

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*vs-prod       125.109.1.9       5 u   42   64    1    0.687   -3.405   3.342