Avere il tempo corretto sul modulo è fondamentale per tutti i tipi di attività, tra cui la sincronizzazione dei log e la convalida dei certificati di sicurezza. A partire dalla release 15.1 VOS spedito con una porta del demone Network Time Protocol (ntpd) ed è fortemente raccomandato di eseguirlo.
In genere, per eseguire ntpd è necessario fornirgli una lista di time server, host sulla rete che eseguono anche ntpd e che forniranno il tempo a qualsiasi host che lo richieda. Ci sono un gran numero di time server disponibili su internet che è possibile utilizzare. Date un'occhiata a http://www.pool.ntp.org/en/ che organizza i server per regione.
Suggerisco di elencare uno o tre (o più) server, mai due. ntpd cerca di capire quale sia il server migliore da utilizzare confrontando le risposte dei server. Se vengono elencati solo due server è possibile che ntpd non sia in grado di fare una determinazione e finisca per non utilizzarne nessuno dei due.
Ma cosa dovete fare se le politiche della vostra azienda vi impediscono di accedere ai time server su Internet e non avete un time server designato dalla vostra azienda? In tal caso potreste essere in grado di utilizzare un controller di dominio Microsoft Windows (DC) o un controller di dominio di backup (BDC) locale. La maggior parte dei DC e dei BDC fornirà servizi temporali.
Quindi, come amministratore VOS, come si fa a trovare il DC o il BDC locale? Il modo più semplice è quello di chiedere, ma supponendo che non sia un'opzione, è possibile eseguire il monitoraggio dei pacchetti e cercare da soli. Sia le workstation che i controller di dominio trasmettono periodicamente sulla porta UDP 138.
Il comando
>sistema>stcp>biblioteca_comando>biblioteca>pacchetto_monitor -interfaccia #INTERFACE -numerico
-time_stamp -verbose -pkt_hdr -hex_header -hex_dump -lunghezza 1500 -filtro -port 138
|
| Figura 1 - comando packet_monitor |
visualizzerà queste trasmissioni (assicuratevi di sostituire INTERFACE con il nome della vostra interfaccia IP). Sfortunatamente, per trovare i time server è necessario guardare i dati esadecimali nel pacchetto e poiché probabilmente ci saranno molti pacchetti da esaminare, è necessario scaricare i pacchetti in un file. La mia macro di comando pm.cm (la macro la trovate qui) creerà automaticamente un file out ed eseguirà la traccia come processo avviato. Il file out avrà il nome pm.(data).(tempo).out. Il comando sarà
pm #INTERFACE -no_arp -no_icmp -port 138 |
| Figura 2 - macro comando pm |
Comunque iniziate la traccia, lasciatela girare per 15-20 minuti e dovreste ricevere una trasmissione da ogni DC e BDC della vostra rete. Poi cercate le linee con la stringa 'c0 3' e 'c0 2'; cioè C minuscola, zero, quattro spazi e un tre o un due. Il numero corrisponde al morso superiore del byte all'offset c0. Quel byte può essere decodificato come
ABCD EFGH ^^^^ ^^^^ |||| L'host è una postazione di lavoro |||| L'host è un server |||| L'host NON è un server SQL |||| L'host NON è un controllore di dominio ||||------- L'host è un controller di dominio di backup ||||-------------- host è un time server |||------------- l'ospite NON è un ospite Apple |---------------- L'ospite NON è un ospite Novell |
| Figura 3 - Decodifica byte tipo server |
Come si può vedere la ricerca di quel primo tre o due potrebbe non ottenere tutti i server di tempo, ma a meno che non si esegue un romanzo esclusivo o un sito Apple dovrebbe ottenere almeno un DC o BDC.
d pm.11-02-06.17:25:06.out -match 'c0 2'
ready 17:47:13
d pm.11-02-06.17:25:06.out -match 'c0 3'
%phx_vos#m15_mas>SysAdmin>Noah_Davids>pm.11-02-06.17:25:06.out 11-02-06 17:47
c0 33 10 82 0 f 1 55 aa 0 3 <<U*
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
c0 33 10 82 0 f 1 55 aa 0 3 <<U*
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
c0 33 10 82 0 f 1 55 aa 0 3 <<U*
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
c0 33 10 82 0 f 1 55 aa 0 3 <<U*
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
ready 17:47:29
|
| Figura 4 - linee packet_monitor che corrispondono al time server e al controllore di dominio di backup |
Non basta trovare le linee "c0". È necessario trovare anche l'indirizzo dell'host che ha inviato il pacchetto. Il comando grep che si trova nella directory >system>gnu_library>bin può corrispondere su più linee
grep -e 'c0 3' -e 'c0 2' -e UDP pm.11-02-06.17:25:06.out
. . . .
UDP from 192.168.33.180.138 to 192.168.33.255.138 Cksum 7ca3, 220 data bytes.
UDP from 192.168.33.249.138 to 192.168.33.255.138 Cksum c89a, 209 data bytes.
c0 33 10 82 0 f 1 55 aa 0 3 <<U*
. . . .
UDP from 192.168.33.50.138 to 192.168.33.255.138 Cksum 9526, 193 data bytes.
UDP from 192.168.33.248.138 to 192.168.33.255.138 Cksum d05f, 209 data bytes.
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
. . . .
UDP from 192.168.33.202.138 to 192.168.33.255.138 Cksum cf35, 219 data bytes.
UDP from 192.168.33.253.138 to 192.168.33.255.138 Cksum 9505, 209 data bytes.
c0 33 10 82 0 f 1 55 aa 0 3 <<U*
. . . .
UDP from 192.168.33.131.138 to 192.168.33.255.138 Cksum aa35, 222 data bytes.
UDP from 192.168.33.252.138 to 192.168.33.255.138 Cksum 7343, 209 data bytes.
c0 33 10 84 0 f 1 55 aa 0 3 <<U*
. . . . .
|
| Figura 5 - linee di packet_monitor che mostrano i server di tempo scoperti |
L'indirizzo dei time server appare sulle righe immediatamente sopra la riga "c0". Nella figura precedente abbiamo identificato 192.168.33.249, 192.168.33.248, 192.168.33.253 e 192.168.33.252.
Ora che abbiamo identificato gli host che si pubblicizzano come time server, come possiamo essere sicuri che funzioneranno? Il comando ntpdate può essere usato per interrogare manualmente ogni time server. Utilizzate l'argomento "-q" per interrogare solo il time server, a questo punto non vogliamo che ntpdate imposti anche l'orario del modulo.
ntpdate -q 192.168.33.248
Ricerca di host 192.168.33.248 e servizio ntp
host trovato : dc48.noahslab.stratus.com
server 192.168.33.248, strato 4, offset -0.117418, ritardo 0.04202
6 Feb 17:53:10 ntpdate[1427079382]: regolare il time server 192.168.33.248 offset -0
+,117418 sec.
pronto 17:53:10
ntpdate -q 192.168.33.249
Ricerca di host 192.168.33.249 e servizio ntp
host trovato : dc49.noahslab.stratus.com
server 192.168.33.249, strato 4, offset -0.038709, ritardo 0.04355
6 Feb 17:53:25 ntpdate[1427079382]: regolare il time server 192.168.33.249 offset -0
+,038709 sec
pronto 17:53:25
ntpdate -q 192.168.33.252
Ricerca di host 192.168.33.252 e servizio ntp
host trovato : dc52.noahslab.stratus.com
server 192.168.33.252, strato 3, offset 0.015733, ritardo 0.04216
6 Feb 17:53:38 ntpdate[1427079382]: regolare il time server 192.168.33.252 offset 0.
+015733 sec
pronto 17:53:38
|
| Figura 6 - utilizzo di ntpdate per testare i server di tempo scoperti - server funzionanti |
Diciamo che uno dei server ha una politica di firewall che gli impedisce di dare il tempo anche se lo avvantaggia, ntpdate mostrerà quanto segue.
ntpdate -q 192.168.33.254
Ricerca di host 192.168.33.254 e servizio ntp
host trovato : dc54.noahslab.stratus.com
server 192.168.33.254, strato 0, offset 0.000000, ritardo 0.00000
6 Feb 17:54:00 ntpdate[1427079382]: nessun server adatto alla fontana di sincronizzazione
+d
pronto 17:54:00
|
| Figura 7 - utilizzo di ntpdate per testare i server temporali scoperti - server non funzionanti |
Ora che sai quali server temporali puoi usare puoi scrivere il file >sistema>ntp>ntp.conf come segue. Tutto in nero proviene dal file sample_ntp.conf.17.0, i nuovi caratteri sono in verde. Si noti il carattere di commento che è stato aggiunto davanti alla riga "server foo.bar.somewhere.com". Le istruzioni di restrizione migliorano la posizione di sicurezza del sistema impedendo ad altri host di effettuare interrogazioni non temporali contro il demone ntp.
# le direttive del server indicano da dove prendere il tempo.
# Possono essere valori DNS o IP, uno per direttiva.
# server foo.bar.somewhere.com
server 192.168.33.248 burst iburst
server 192.168.33.249 burst iburst
server 192.168.33.252 burst iburst
# Home per il logile. Scegli un buon percorso relativo - VOS assoluto
# I nomi dei percorsi non possono essere analizzati correttamente.
file di log >sistema>ntp>ntp.logfile
# Home per il driftfile.
driftfile >sistema>ntp>ntp.drift
# Queste dichiarazioni eviteranno le richieste non temporali da parte di qualsiasi ospite che non sia un ospite locale.
limitare la noquery di default
limitare 127.0.0.0.1
|
| Figura 8 - file >sistema>ntp>ntp.conf aggiornato |
Avviare il comando ntpd (c'è un sample_start_ntpd.17.0 nella directory >system>ntpd.17.0 nella directory >system>ntp) e dopo pochi minuti si dovrebbe vedere qualcosa come il seguente. L'*" davanti a 192.168.33.252 indica che quello è il server da cui ntpd ha scelto di prendere il suo tempo. Il "+" davanti a 192.168.33.248 indica un'altra buona scelta nel caso non ci sia una risposta da 192.168.33.252. Finché una delle righe come "*" nella prima colonna si sa che il tempo del modulo sarà sincronizzato con un time server. Ricordate però che potrebbe essere necessario un po' di tempo prima che i tempi convergano quando la differenza iniziale tra il modulo e il time server è grande.
ntpq -n
ntpq> peer
Rifiutate a distanza quando il ritardo del sondaggio raggiunge il jitter di offset di compensazione
==============================================================================
+192.168.33.248 192.168.33.252 4 u - 1024 377 1.312 -1549.3 639.489
192.168.33.249 192.168.33.252 4 u 626 1024 377 132.423 15.202 27.797
*192.168.33.252 192.168.33.51 3 u 802 1024 377 0.964 -27.486 2.993
|
| Figura 9 - utilizzo di ntpq per confermare la sincronizzazione temporale |
Infine, ntpd agisce sia come client che come server, quindi una volta in esecuzione su un modulo VOS può fungere da time server per altri moduli o per qualsiasi altra cosa sulla vostra rete.