Anche se questo è il primo articolo che scrivo su questo tema, sono sempre stato attratto dagli strumenti che servono per gestire e sincronizzare l’orario. Il mio metodo preferito per la sincronizzazione dell’orologio di un sistema è NTP (Network Time Protocol) e la sua implementazione su linux: ntpd.
Negli anni ho visto tantissime configurazioni diverse applicate da colleghi sistemisti e anche molti sistemi in cui questa configurazione era stata trascurata. Avere l’orologio di sistema sincronizzato tuttavia è cruciale per tantissimi scenari e dovrebbe essere una priorità assicurarsi che la sincronizzazione dell’ora sia effettuata in modo efficace.
Alcuni esempi di servizi infrastrutturali dove mantenere l’orologio sincronizzato è fondamentale possono essere: gli Host contenenti macchine virtuali, server DHCP e LDAP, server di autenticazione Kerberos.
Molte distribuzioni Linux hanno delle preconfigurazioni per quanto riguarda ntpd o systemd-timesyncd e queste di solito sono valide, ma usano normalmente solo server pubblici e questi potrebbero non essere sempre disponibili nelle reti private. Alcune implementazioni inoltre possono anche utilizzare i server NTP che vengono passati all’host dal server DHCP. Lascerò quest’ultima implementazione, insieme a quelle che usano systemd-timesyncd per il mondo desktop e mobile.
In un sistema server, che sia Linux, Windows, un appliance o altro, un sistemista solitamente cambia i server NTP preconfigurati per mettere quelli disponibili nella LAN e qui entrano in gioco le Best Practices che possono essere molto diverse da quello che uno si aspetta e da quelle utilizzate per altri protocolli come ad esempio DNS o DHCP.
Qui riporto l’RFC che riguarda questo tema, che in realtà mi sembra abbastanza leggibile già di suo:
https://datatracker.ietf.org/doc/rfc8633/
Quello che vedo pranticamente tutti i giorni nel mio lavoro, è che le persone sono sempre avare con il numero di server NTP che si impostano in ntpd per la sincronizzazione dell’ora. So che questa è principalmente una questione filosofica, in quanto ci sono sistemi configurati con pochi time server che hanno funzionato per anni senza avere alcun problema, ma perché rischiare di avere soprese anche dopo anni?
La parte prettamente filosofica è la seguente:
- un uomo ha solo un orologio che può controllare e quindi deve assumere che questo orologio sia corretto.
- un uomo ha due orologi che può controllare. Se i due orologi mostrano la stessa ora, allora l’uomo può assumere che sia corretta. Se i due orologi mostrano un orario diverso l’uomo non può sapere quale sia giusto.
- un uomo ha tre orologi che può controllare. Se nessuno dei tre si rompe mai, l’uomo sceglierà uno dei due orologi che mostrano un orario più prossimo a vicenda. Se uno dei tre orologi si rompe però, anche per poco tempo, si ricade però nella situazione precedente in cui si hanno solo 2 orologi.
In queste situazioni, con degli orologi fisici è molto difficile che si abbiano dei problemi così spesso: se si parla invece di server in LAN con ntpd il fatto che uno di loro vada giù può accadere più spesso, ad esempio quando si riavvia il sistema operativo per fare gli aggiornamenti. Per quanto riguarda i server pubblici NTP, ci sono una marea di “false ticker”, server che riportano di essere sincronizzati e affidabili quando invece ti mostrano l’ora errata, e questi server pubblici possono andare giù o dire che non sono più sincronizzati in qualsiasi momento, perché essendo gratuiti non danno alcuna assicurazione di continuità di servizio.
Per difendersi da queste evenienze le Best Practice dicono che bisogna configurare 4 time server o più, e se non si può, di metterne solo 1. Il mio suggerimento, se si usano server pubblici poi, è di usarne quanti si pensa sia meglio usare a seconda della qualità percepita dei server impostati. NTP è un protocollo molto leggero e non c’è alcuno svantaggio a configurare anche 10 time server ad esempio. Di solito ne metto tra 4 e 8: penso che più di questi non abbia molto senso metterne, ma non c’è veramente un limite. Si possono anche mescolare server privati e pubblici senza problemi.
Ci sono poi anche altre Best Practices, oltre a quella del numero di server, per esempio quelle legate all’utilizzo del parametro peer in ntpd, ci sono discussioni se sia un bene usare un orologio su un hardware virtualizzato o si possono trovare diversi modi di litigare con systemd, ma lascerò queste discussioni per la prossima volta.