Quali sono i pro e i contro tra questi due modi per sincronizzare il tuo server?
Mi sembra che il tuo server probabilmente non andrebbe alla deriva più di 1 secondo ogni giorno, quindi ntpdate su un crontab andrebbe bene. Ma ho sentito che qui potresti usare server NTP ridondanti
http://www.pool.ntp.org/en/use.html
al fine di mantenere il tempo sincronizzato in caso di guasto.
Hai qualche suggerimento?
Risposte:
L'algoritmo NTP include informazioni che consentono di calcolare e correggere la deriva nell'orologio del server. NTPD include la possibilità di utilizzarlo per mantenere sincronizzato l'orologio e verrà eseguito in modo più accurato rispetto a un orologio su un computer che non esegue NTPD. NTPD utilizzerà anche diversi server per migliorare la precisione.
ntpdate non mantiene alcuno stato per eseguire questo servizio per te, quindi non fornirà lo stesso tipo di accuratezza. Ti consentirà di fornirti un elenco di server che utilizzerà per tentare di fornirti un risultato migliore, ma questo non sostituisce i sofisticati algoritmi forniti in NTPD che tracciano la tua deriva da ciascuno dei server nel tempo.
NTPDATE corregge istantaneamente l'ora di sistema, il che può causare problemi con alcuni software (ad es. Distruggere una sessione che ora sembra obsoleta). NTPD corregge intenzionalmente l'ora del sistema lentamente, evitando questo problema. È possibile aggiungere l'opzione -g all'avvio di NTPD per consentire a NTPD di fare per la prima volta l'aggiornamento di uno di grandi dimensioni che è più o meno equivalente all'esecuzione di ntpdate una volta prima di avviare NTPD, che una volta era consigliato pratica.
Per quanto riguarda i problemi di sicurezza, i server ntp non si riconnettono su connessioni non avviate, il che significa che il firewall dovrebbe essere in grado di dire che hai avviato la richiesta ntp e consentire il traffico di ritorno. Non dovrebbe essere necessario lasciare le porte aperte per connessioni arbitrarie al fine di far funzionare NTPD.
Dalla pagina man ntpdate (8):
ntpdate può essere eseguito manualmente, se necessario, per impostare l'orologio host, oppure può essere eseguito dallo script di avvio dell'host per impostare l'orologio all'avvio. Ciò è utile in alcuni casi per impostare l'orologio inizialmente prima di avviare il demone NTP ntpd. È anche possibile eseguire ntpdate da uno script cron. Tuttavia, è importante notare che ntpdate con script cron forzati non sostituisce il demone NTP, che utilizza algoritmi sofisticati per massimizzare l'accuratezza e l'affidabilità minimizzando l'utilizzo delle risorse. Infine, poiché ntpdate non disciplina la frequenza di clock dell'host come ntpd, l'accuratezza che utilizza ntpdate è limitata.
ntpd è preferito su ntpdate perché ottieni una correzione del tempo regolare piuttosto che salti nel tuo orologio. Che senso hai dei tuoi registri quando c'è un salto indietro nel tempo? ntpdate passerà anche in modo trasparente tra i server secondo necessità.
Per quanto riguarda la richiesta di porte aperte (come menzionato da Kyle), le nuove versioni di ntpd (ad es. 4.2.4 sul mio server Debian) possono essere configurate per trasmettere / multicast alla LAN, con autenticazione crittografica.
Modifica: vedi anche questa domanda .
In genere, consiglio di eseguire NTPD e di sincronizzare i server con un server orario designato all'interno dell'organizzazione. Quel server interno si sincronizzerà in genere con uno dei server NTP pubblici (a cui sei collegato).
Ho usato il metodo ntpdate senza alcun problema, ma sembra solo più hacker che eseguire un vero demone ntpd.
Ho sentito parlare di problemi con l'inclinazione dell'orologio su macchine virtuali che eseguono ntpd. Ho anche sentito parlare di persone che correggono questo problema eseguendo regolari lavori cron che chiamano ntpdate su diversi server del pool. Non ho avuto questi problemi, ma ne ho sentito parlare più volte.
Come menzionato altrove, NTP fornisce una correzione del tempo regolare. Se alle applicazioni sul tuo server non importa che mancano interi secondi o che ripeti gli stessi secondi, allora ntpd non ti guadagna molto su ntpdate.
Se invece hai applicazioni sensibili al tempo che sono sensibili ai secondi, o peggio ancora sensibili ai secondi parziali, allora ntpd è di gran lunga la scelta migliore. Gli aggiornamenti di data e ora di Novell eDirectory per la gestione delle collisioni di aggiornamento, che diventa fondamentale se gli aggiornamenti arrivano molto velocemente (come durante la corsa di accesso mattutina). Un server syslog deve avere un tempo preciso di almeno mezzo secondo al fine di mantenere registri sani.
Per la mia scatola MythTV a casa, noto quando mancano anche pochi secondi a ciò che il mio provider via cavo considera il tempo, quindi uso NTP su quello. Per il server di monitoraggio UPS al lavoro uso ntpdate crontabbed per gli stessi motivi che Kyle Hodgson ha sottolineato, poiché è un host bastione che non voglio che quella porta sia aperta anche se ho bloccato l'applicazione; per quella domanda essere un secondo di vero non è terribile.
Per quanto riguarda la ridondanza, manteniamo almeno due time-host sulla nostra rete e puntiamo tutti i nostri host interni su quei due. Questi due tracciano quindi diversi host NTP Internet. Inoltre, sono configurati secondo un accordo tra pari in modo da poter mantenere il tempo tra loro in modo consensuale se il nostro collegamento a Internet si interrompe. NTP robusto è sicuramente possibile progettare.
Su un server in cui l'accesso e il rafforzamento sono fondamentali, ho usato il ragionamento secondo cui xntpd, la versione di ntpd su cui mi basavo, richiedeva una porta UDP aperta 123. Dato che preferivo avere solo tcp 22 e 80 aperti, ho usato ntpdate in un crontab invece. Non ho mai sentito una buona ragione per cui ne avesse bisogno, o non quella che ricordo.
Uno degli svantaggi dell'utilizzo di una chiamata ntpdate crontab è che non è in grado di gestire elegantemente la correzione della deriva. ntpdate, iirc, aggiorna l'orologio non appena può dire che sei obsoleto - i demoni ntp di solito correggono la deriva delicatamente. Ciò ha il vantaggio di mantenere sani i tuoi registri: puoi immaginare, ad esempio, su un server Web occupato che se l'RTC si fosse spostato di qualche minuto, la lettura dei registri Web il giorno successivo potrebbe dedurre che le persone erano in grado di colpire in modo sicuro L'URL è prima dell'accesso, poiché gli hit sul Web sarebbero fuori servizio.
Non è necessario utilizzare crontab, ecco a cosa serve ntpd.
Inizialmente quando il tuo tempo è finito, un modo è semplicemente quello di interrompere ntpd, quindi eseguire ntpdate ntp.server.comper ripristinarlo, quindi riavviare ntp.
Se disponi di una rete di grandi dimensioni, probabilmente configurerei un paio di server ntp locali e farei in modo che tutti gli host li usino.
Vedi questa discussione per capire perché "ntpdate" è ancora desiderato e in uso.
Per riassumere: ntpd è lento in confronto quando si effettua una regolazione massiccia del tempo, anche con l'opzione -g.
Per uso domestico, ntpdate non è un vero problema .. C'è una ragione per cui è "più lento". Chiunque usi un cron con ntpdate in un ambiente PRODUCTION ENTERPRISE è solo un idiota.