Avere l'ora corretta sul modulo è fondamentale per tutti i tipi di attività, tra cui la sincronizzazione dei registri e la convalida dei certificati di sicurezza. A partire dalla versione 15.1, VOS viene fornito con una porta del demone Network Time Protocol (ntpd) e si consiglia vivamente di eseguirlo.
In genere, per eseguire ntpd è necessario fornirgli un elenco di server di tempo, host sulla rete che eseguono anch'essi ntpd e forniranno l'ora a qualsiasi host che lo richieda. Su Internet è disponibile un gran numero di server di tempo 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 server sia meglio utilizzare confrontando le risposte dei server. Se sono elencati solo due server, è possibile che ntpd non sia in grado di prendere una decisione e finisca per non utilizzare nessuno dei due.
Ma cosa fare se le politiche aziendali impediscono l'accesso ai server di riferimento orario su Internet e non si dispone di un server di riferimento orario designato dall'azienda? In tal caso, è possibile utilizzare un controller di dominio (DC) Microsoft Windows locale o un controller di dominio di backup (BDC). La maggior parte dei DC e dei BDC fornisce servizi di riferimento orario.
Quindi, come amministratore VOS, come puoi trovare il DC o il BDC locale? Il modo più semplice è chiedere, ma supponendo che questa non sia un'opzione, puoi eseguire il monitoraggio dei pacchetti e cercare da solo. Sia le workstation che i controller di dominio trasmettono periodicamente sulla porta UDP 138.
Il comando
>system>stcp>command_library>packet_monitor -interface#INTERFACE -numeric
-time_stamp -verbose -pkt_hdr -hex_header -hex_dump -length 1500 -filter -port 138
|
| Figura 1 – Comando packet_monitor |
visualizzerà queste trasmissioni (assicurati di sostituire INTERFACE con il nome della tua interfaccia IP). Sfortunatamente, per trovare i server temporali è necessario esaminare i dati esadecimali nel pacchetto e, dato che probabilmente ci saranno molti pacchetti da esaminare, è necessario scaricare i pacchetti in un file. Il mio comando macro pm.cm (puoi trovare il comando macro qui) creerà automaticamente un file di output ed eseguirà la traccia come processo avviato. Il file di output avrà il nome pm.(data).(ora).out. Il comando sarà
pm#INTERFACE -no_arp -no_icmp -port 138 |
| Figura 2 – Macro del comando pm |
Indipendentemente da come si avvia la traccia, lasciarla in esecuzione per 15-20 minuti e si dovrebbe ottenere una trasmissione da ciascun DC e BDC sulla rete. Cerca quindi le righe contenenti la stringa "c0 3" e "c0 2", ovvero la lettera C minuscola, lo zero, quattro spazi e un tre o un due. Il numero corrisponde al nibble superiore del byte all'offset c0. Quel byte può essere decodificato come
ABCD EFGH ^^^^ ^^^^ |||| ||||-- l'host è una workstation |||| |||--- l'host è un server |||| ||---- l'host NON è un server SQL |||| |----- l'host NON è un controller di dominio ||||------- l'host è un controller di dominio di backup |||-------- l'host è un server di tempo ||--------- l'host NON è un host Apple |---------- l'host NON è un host Novell |
| Figura 3 – Decodifica byte tipo server |
Come puoi vedere, cercando i primi tre o due potresti non ottenere tutti i server temporali, ma a meno che tu non gestisca un sito esclusivo Novel o Apple, dovresti ottenere almeno un DC o un 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 corrispondenti al server di sincronizzazione e al controller di dominio di backup |
Non basta trovare le righe "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ò trovare corrispondenze su più righe.
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 packet_monitor che mostrano i server di tempo rilevati |
L'indirizzo dei server di riferimento temporale appare sulle righe immediatamente sopra la riga "c0". Nella figura sopra 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 server di riferimento orario, come possiamo essere sicuri che funzioneranno? Il comando ntpdate può essere utilizzato per interrogare manualmente ciascun server di riferimento orario. Utilizzate l'argomento "-q" per interrogare solo il server di riferimento orario, poiché in questa fase non vogliamo che ntpdate imposti anche l'ora del modulo.
ntpdate -q 192.168.33.248
Ricerca dell'host 192.168.33.248 e del servizio ntp
host trovato: dc48.noahslab.stratus.com
server 192.168.33.248, stratum 4, offset -0.117418, ritardo 0.04202
6 feb 17:53:10 ntpdate[1427079382]: regola il server orario 192.168.33.248 offset -0
+.117418 sec
pronto 17:53:10
ntpdate -q 192.168.33.249
Ricerca host 192.168.33.249 e servizio ntp
host trovato: dc49.noahslab.stratus.com
server 192.168.33.249, stratum 4, offset -0,038709, ritardo 0,04355
6 feb 17:53:25 ntpdate[1427079382]: regola il server orario 192.168.33.249 offset -0
+.038709 sec
pronto 17:53:25
ntpdate -q 192.168.33.252
Ricerca host 192.168.33.252 e servizio ntp
host trovato: dc52.noahslab.stratus.com
server 192.168.33.252, stratum 3, offset 0,015733, ritardo 0,04216
6 feb 17:53:38 ntpdate[1427079382]: regola il server orario 192.168.33.252 offset 0.
+015733 sec
pronto 17:53:38
|
| Figura 6 – Utilizzo di ntpdate per testare i server di tempo rilevati — server funzionanti |
Supponiamo che uno dei server abbia una politica firewall che gli impedisce di fornire l'ora anche se la pubblicizza, ntpdate mostrerà quanto segue.
ntpdate -q 192.168.33.254
Ricerca dell'host 192.168.33.254 e del servizio ntp
host trovato: dc54.noahslab.stratus.com
server 192.168.33.254, stratum 0, offset 0.000000, ritardo 0.00000
6 feb 17:54:00 ntpdate[1427079382]: nessun server adatto alla sincronizzazione trovato
+d
pronto 17:54:00
|
| Figura 7 – Utilizzo di ntpdate per testare i server di tempo rilevati — server non funzionante |
Ora che sai quali server di tempo puoi usare, puoi scrivere il file >system>ntp>ntp.conf come segue. Tutto ciò che è in nero proviene dal file sample_ntp.conf.17.0, i nuovi caratteri sono in verde. Notate il carattere di commento che è stato aggiunto davanti alla riga "server foo.bar.somewhere.com". Le istruzioni restrict migliorano la sicurezza del sistema impedendo ad altri host di effettuare query non relative al tempo sul demone ntp.
# Le direttive server indicano da dove ottenere l'ora.
# Possono essere valori DNS o IP, uno per direttiva.
# server foo.bar.somewhere.com
server 192.168.33.248 burstiburst
server 192.168.33.249 burst iburst
server 192.168.33.252 burstiburst
# Home il logile. Scegli un buon percorso relativo - VOS assoluto
# I nomi dei percorsi assoluti VOS non possono essere analizzati correttamente.
logfile >system>ntp>ntp.logfile
# Home il driftfile.
driftfile >system>ntp>ntp.drift
# Queste istruzioni impediranno le query non relative al tempo da qualsiasi host tranne l'host locale.
restrict default noquery
restrict 127.0.0.1
|
| Figura 8 – file >system>ntp>ntp.conf aggiornato |
Avvia il comando ntpd (è presente un file sample_start_ntpd.17.0 nella directory >system>ntp) e dopo alcuni minuti dovresti vedere qualcosa di simile a quanto riportato di seguito. Il simbolo "*" davanti a 192.168.33.252 indica che quello è il server da cui ntpd ha scelto di prendere il tempo. Il segno "+" davanti a 192.168.33.248 indica un'altra buona scelta nel caso in cui non ci sia risposta da 192.168.33.252. Finché una delle righe ha un "*" nella colonna uno, sapete che l'ora del modulo sarà sincronizzata con un server di tempo. Ricordate tuttavia che potrebbe essere necessario un po' di tempo prima che gli orari convergano quando la differenza iniziale tra il modulo e il server di tempo è grande.
ntpq -n
ntpq> peer
remote refid st t when poll reach delay offset jitter
==============================================================================
+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 dell'ora |
Infine, ntpd funge sia da client che da server, quindi una volta avviato su un modulo VOS può fungere da server di riferimento temporale per altri moduli o qualsiasi altro elemento della rete.