La maggior parte delle persone si preoccupa dell'orario. Ci svegliamo in tempo per svolgere i nostri rituali mattutini e andare al lavoro, fare una pausa pranzo, rispettare le scadenze dei progetti, festeggiare compleanni e festività, prendere un aereo e così via.
Inoltre: alcuni di noi sono ossessionati dal tempo. I miei orologi sono alimentati da energia solare e ricevono l'ora esatta dal National Institute of Standards and Technology () a Fort Collins (Colorado) tramite una stazione radio a onde lunghe . I segnali temporali sono sincronizzati con orologi atomici situati anch'essi a Fort Collins. Il mio Fitbit si sincronizza con il mio telefono, che si sincronizza con il server , che infine si sincronizza con gli orologi atomici.
Anche i dispositivi tengono traccia del tempo
Ci sono molte ragioni per cui i nostri dispositivi e computer hanno bisogno di un orario preciso. Ad esempio, nel settore bancario, nei mercati azionari e in altre attività finanziarie, le transazioni devono avvenire nell'ordine corretto, e per questo le sequenze temporali esatte sono fondamentali.
I nostri telefoni, tablet, automobili, sistemi GPS e computer richiedono una corretta impostazione di data e ora. Voglio che l'orologio sul desktop del mio computer mostri l'ora corretta. Voglio che nel mio calendario locale gli avvisi appaiano al momento giusto. Un orario corretto garantisce anche che i job cron e systemd vengano eseguiti all'orario prestabilito.
Data e ora sono importanti anche per la registrazione, quindi è più semplice trovare determinati log basandosi su data e ora. Ad esempio, una volta lavoravo in DevOps (all'epoca non lo si chiamava così) e mi occupavo della configurazione di un sistema di posta elettronica nella Carolina del Nord. Gestivamo oltre 20 milioni di email al giorno. Monitorare le email attraverso una serie di server o determinare la sequenza esatta degli eventi usando i file di log su host geograficamente distribuiti può essere molto più semplice se i computer pertinenti sono sincronizzati nell'orario.
C'è un solo tempo, ma molti orologi
I server Linux devono considerare che esiste un'ora di sistema e un'ora RTC. L'RTC (Real Time Clock - orologio in tempo reale) è un nome un po' strano e non particolarmente accurato per gli orologi hardware.
Gli orologi hardware funzionano ininterrottamente, anche quando il computer è spento, utilizzando una batteria sulla scheda madre del sistema. La funzione principale dell'RTC è mantenere il tempo quando la connessione al server temporale non è disponibile. In tempi in cui non era possibile connettersi a un server temporale tramite Internet, ogni computer doveva avere orologi interni precisi. I sistemi operativi dovevano accedere all'RTC durante l'avvio, e l'utente doveva impostare manualmente l'ora di sistema usando l'interfaccia hardware di configurazione del BIOS, per assicurarsi che fosse corretta.
Gli orologi hardware non comprendono il concetto di fusi orari; nell'RTC viene memorizzato solo l'ora, non il fuso orario o lo spostamento dall'UTC (Tempo Coordinato Universale, noto anche come GMT o Tempo Medio di Greenwich). Puoi impostare l'RTC usando uno strumento di cui parlerò più avanti in questo articolo.
L'ora di sistema è il tempo che il sistema operativo visualizza nell'orologio della GUI sul tuo desktop, nell'output del comando date, nei timestamp dei log. Si riferisce anche al tempo di creazione, modifica e apertura dei file.
Nella pagina c'è una descrizione completa dell'RTC e degli orologi di sistema.
Cosa c'è in NTP?
I computer di tutto il mondo utilizzano NTP (Network Time Protocol) per sincronizzare il proprio tempo con orologi di riferimento standard tramite Internet, utilizzando una gerarchia di server NTP. I server temporali principali sono di livello 1 e sono direttamente collegati a vari servizi nazionali di tempo di livello 0 tramite satellite, radio o anche modem su linee telefoniche. I servizi di tempo di livello 0 possono essere orologi atomici, ricevitori radio sintonizzati su segnali trasmessi da orologi atomici o ricevitori GPS che utilizzano segnali orari ad alta precisione trasmessi dai satelliti GPS.
Su quasi tutti i server di riferimento sono aperti migliaia di server NTP stratum 2, accessibili a tutti. Molte organizzazioni e utenti (me compreso) con un numero elevato di host che necessitano di un server NTP preferiscono installare i propri server temporali, in modo che solo un host locale si colleghi a uno stratum 2 o 3. Quindi configurano i restanti nodi nella rete per utilizzare il server temporale locale. Nel mio caso, nella mia rete domestica, si tratta di un server di livello 3.
Diverse implementazioni di NTP
L'implementazione originale di NTP è ntpd. Poi si sono unite due versioni più recenti, chronyd e systemd-timesyncd. Tutti e tre sincronizzano l'ora dell'host locale con un server temporale NTP. Il servizio systemd-timesyncd non è così affidabile come chronyd, ma è sufficiente per la maggior parte degli scopi. Se l'RTC non è sincronizzato, può gradualmente regolare l'ora di sistema per sincronizzarsi con il server NTP quando l'ora di sistema locale è leggermente spostata. Il servizio systemd-timesync non può essere utilizzato come server temporale.
è un'implementazione di NTP che comprende due programmi: il demone chronyd e un'interfaccia della riga di comando chiamata chronyc. Chrony ha alcune funzionalità che in molti casi sono semplicemente indispensabili:
- Chrony può sincronizzarsi con il server temporale molto più velocemente rispetto al vecchio servizio ntpd. Questo è utile per laptop o computer desktop che non sono sempre accesi.
- Può compensare le variazioni della frequenza di clock, ad esempio quando l'host entra in modalità sospensione o quando la frequenza di clock cambia a causa di un'improvvisa variazione della frequenza, che rallenta i clock sotto carichi leggeri.
- Affronta problemi di tempo legati a una connessione di rete instabile o a un sovraccarico della rete.
- Regola le latenze nella rete.
- Dopo la sincronizzazione temporale iniziale, Chrony non ferma mai l'orologio. Ciò garantisce intervalli di tempo stabili e coerenti per molti servizi e applicazioni di sistema.
- Chrony può funzionare anche senza una connessione di rete. In tal caso, l'host locale o il server possono essere aggiornati manualmente.
- Chrony può fungere da server NTP.
Ancora una volta: NTP è un protocollo che può essere implementato su un host Linux utilizzando Chrony o systemd-timesyncd.
I pacchetti RPM NTP, Chrony e systemd-timesyncd sono disponibili nei repository standard di Fedora. RPM systemd-udev è un gestore di eventi del kernel, che in Fedora è installato di default, ma non è obbligatorio per l'uso.
Puoi installare tutti e tre e passare da uno all'altro, ma ciò può creare fastidi inutili. Quindi è meglio evitarlo. Le versioni moderne di Fedora, CentOS e RHEL sono passate a Chrony come implementazione standard e, inoltre, hanno systemd-timesyncd. Penso che Chrony funzioni bene, offra una migliore interfaccia rispetto al servizio NTP, fornisca molte più informazioni e migliori controlli, cosa che piacerà sicuramente agli amministratori di sistema.
Disabilitazione dei servizi NTP
È possibile che un servizio NTP sia già in esecuzione sul tuo host. Se è così, è necessario disabilitarlo prima di passare a qualcos'altro. Avevo in esecuzione chronyd, quindi ho utilizzato i seguenti comandi per fermarlo e disabilitarlo. Esegui i comandi appropriati per qualsiasi demone NTP che utilizzi sul tuo host:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#Verifica che il servizio sia fermo e disabilitato:
[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - Client/server NTP
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:chronyd(8)
man:chrony.conf(5)
[root@testvm1 ~]#Controlla lo stato prima di avviare
Lo stato della sincronizzazione dell'orologio di sistema permette di determinare se il servizio NTP è attivo. Poiché non hai ancora avviato NTP, il comando timesync-status lo suggerirà:
[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.Una richiesta diretta di stato fornisce informazioni importanti. Ad esempio, il comando timedatectl senza argomenti o parametri esegue per impostazione predefinita il sottocomando status:
[root@testvm1 ~]# timedatectl status
Orario locale: ven 2020-05-15 08:43:10 EDT
Orario universale: ven 2020-05-15 12:43:10 UTC
Orario RTC: ven 2020-05-15 08:43:08
Fuso orario: America/New_York (EDT, -0400)
Orologio di sistema sincronizzato: no
Servizio NTP: inattivo
RTC nel fuso orario locale: sì
Attenzione: Il sistema è configurato per leggere l'orario RTC nel fuso orario locale.
Questa modalità non può essere supportata completamente. Creerà vari problemi
con le modifiche del fuso orario e gli aggiustamenti per l'ora legale. L'orario RTC
non viene mai aggiornato, ma si basa su strutture esterne per mantenerlo.
Se possibile, utilizzare RTC in UTC chiamando
'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#In questo modo, otterrete l'orario locale per il vostro host, l'orario UTC e l'orario RTC. In questo caso, l'orario di sistema è impostato sul fuso orario America/New_York (TZ), l'RTC è impostato sull'orario nel fuso orario locale e il servizio NTP non è attivo. L'orario RTC ha cominciato a discostarsi leggermente dall'orario di sistema. Questo è normale per i sistemi i cui orologi non sono stati sincronizzati. L'entità dello scostamento sull'host dipende dal tempo trascorso dall'ultima sincronizzazione del sistema.
Abbiamo anche ricevuto un avviso sull'uso dell'orario locale per l'RTC: questo riguarda le modifiche del fuso orario e le impostazioni dell'ora legale. Se il computer è spento nel momento in cui è necessario apportare modifiche, l'orario RTC non cambierà. Tuttavia, per i server o altri host che operano 24 ore su 24, questo non rappresenta alcun problema. Inoltre, qualsiasi servizio che fornisce sincronizzazione NTP correggerà l'orario dell'host già nelle fasi iniziali di avvio, quindi dopo il completamento dell'avvio l'orario tornerà ad essere corretto.
Impostazione del fuso orario
Di solito, si indica il fuso orario durante la procedura di installazione e non c'è bisogno di cambiarlo in seguito. Tuttavia, ci sono situazioni in cui è necessario modificare il fuso orario. Ci sono diversi strumenti che possono aiutare. Per determinare il fuso orario locale, Linux utilizza i file dei fusi orari. Questi file si trovano nella cartella /usr/share/zoneinfo. Per impostazione predefinita, per il mio fuso orario, il sistema registra quanto segue: /etc/ localtime -> ../usr/share/zoneinfo/America/New_York. Ma non è necessario conoscere questi dettagli per modificare il fuso orario.
L'importante è conoscere il nome ufficiale del fuso orario per la vostra posizione e il comando appropriato. Ad esempio, se volete cambiare il fuso orario in Los Angeles:
[root@testvm2 ~]# timedatectl list-timezones | column
America/La_Paz Europe/Budapest
America/Lima Europe/Chisinau
America/Los_Angeles Europe/Copenhagen
America/Maceio Europe/Dublin
America/Managua Europe/Gibraltar
America/Manaus Europe/HelsinkiOra puoi impostare il fuso orario. Ho usato il comando date per controllare le modifiche, ma puoi anche usare timedatectl:
[root@testvm2 ~]# date
Mar 19 Mag 2020 04:47:49 PM EDT
[root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles
[root@testvm2 ~]# date
Mar 19 Mag 2020 01:48:23 PM PDT
[root@testvm2 ~]#Ora puoi nuovamente cambiare il fuso orario del tuo host all'ora locale.
systemd-timesyncd
Il demone systemd timesync fornisce un'implementazione di NTP che è facile da gestire nel contesto di systemd. Viene installato di default in Fedora e Ubuntu. Tuttavia, viene avviato di default solo in Ubuntu. Non sono sicuro riguardo ad altre distribuzioni. Puoi controllare da solo:
[root@testvm1 ~]# systemctl status systemd-timesyncdConfigurazione di systemd-timesyncd
Il file di configurazione per systemd-timesyncd è /etc/systemd/timesyncd.conf. È un file semplice con meno opzioni attivate rispetto ai vecchi servizi NTP e chronyd. Ecco il contenuto di questo file (senza modifiche aggiuntive) sulla mia macchina virtuale con Fedora:
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.
[Time]
#NTP=
#FallbackNTP=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048L'unica sezione che contiene, oltre ai commenti, è [Time]. Tutte le altre righe sono commentate. Questi sono valori predefiniti, non è necessario modificarli (a meno che tu non abbia motivi per farlo). Se non hai un server NTP definito nella riga NTP =, Fedora utilizza come server di backup il server NTP di Fedora. Di solito aggiungo il mio server NTP:
NTP=myntpserverAvvio di timesync
Puoi avviare e rendere attivo systemd-timesyncd in questo modo:
[root@testvm2 ~]# systemctl enable systemd-timesyncd.service
Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /usr/lib/systemd/system/systemd-timesyncd.service.
[root@testvm2 ~]# systemctl start systemd-timesyncd.service
[root@testvm2 ~]#Impostazione dell'orologio hardware
Ecco come appare la situazione dopo l'avvio di timesyncd:
[root@testvm2 systemd]# timedatectl
Orario locale: Sab 2020-05-16 14:34:54 EDT
Orario universale: Sab 2020-05-16 18:34:54 UTC
Orario RTC: Sab 2020-05-16 14:34:53
Fuso orario: America/New_York (EDT, -0400)
Orologio di sistema sincronizzato: sì
Servizio NTP: attivo
RTC nel fuso orario locale: no Inizialmente, la differenza tra RTC e l'ora locale (EDT) non supera il secondo, e la discrepanza aumenta di ulteriori pochi secondi nei giorni successivi. Poiché in RTC non esiste il concetto di fusi orari, il comando timedatectl deve eseguire un confronto per determinare il fuso orario corretto. Se l'ora RTC non corrisponde esattamente all'ora locale, significa che non corrisponde neanche al fuso orario locale.
Alla ricerca di ulteriori informazioni, ho controllato lo stato di systemd-timesync e ho scoperto quanto segue:
[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Sincronizzazione dell'ora di rete
Caricato: caricato (\/usr\/lib\/systemd\/system\/systemd-timesyncd.service; abilitato; preset del fornitore: disabilitato)
Attivo: attivo (in esecuzione) da Sab 2020-05-16 13:56:53 EDT; 18 ore fa
Documenti: man:systemd-timesyncd.service(8)
PID principale: 822 (systemd-timesyn)
Stato: "Sincronizzazione iniziale con il server di ora 163.237.218.19:123 (2.fedora.pool.ntp.org)."
Compiti: 2 (limite: 10365)
Memoria: 2.8M
CPU: 476ms
CGroup: \/system.slice\/systemd-timesyncd.service
└─822 \/usr\/lib\/systemd\/systemd-timesyncd
Mag 16 09:57:24 testvm2.both.org systemd[1]: Avvio della sincronizzazione dell'ora di rete...
Mag 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: Il tempo dell'orologio di sistema non è impostato o è tornato indietro, ripristinando dalla data e ora registrate: Sab 2020-05-16 13:56:53 EDT
Mag 16 13:56:53 testvm2.both.org systemd[1]: Sincronizzazione dell'ora di rete avviata.
Mag 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Sincronizzazione iniziale con il server di ora 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#Nota il messaggio del registro che indica che l'ora di sistema non è impostata o è stata ripristinata. Il servizio Timesync imposta l'ora di sistema sulla base del timestamp. I timestamp sono gestiti dal demone timesync e vengono creati ad ogni sincronizzazione riuscita.
Il comando timedatectl non ha la possibilità di prendere il valore dell'orologio hardware dagli orologi di sistema. Può impostare data e ora solo in base al valore inserito nella riga di comando. Puoi impostare l'RTC sullo stesso valore dell'ora di sistema utilizzando il comando hwclock:
[root@testvm2 ~]# \/sbin\/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
Ora locale: Lun 2020-05-18 13:56:46 EDT
Ora universale: Lun 2020-05-18 17:56:46 UTC
Ora RTC: Lun 2020-05-18 13:56:46
Fuso orario: America\/New_York (EDT, -0400)
Orologio di sistema sincronizzato: sì
Servizio NTP: attivo
RTC nel fuso orario locale: sìL'opzione —localtime indica che l'orologio hardware mostra l'ora locale, e non UTC.
Perché hai bisogno di RTC?
Qualsiasi implementazione NTP imposterà l'orologio di sistema all'avvio. E allora, a cosa serve RTC? Non è proprio così: questo accadrà solo se hai una connessione di rete con un server temporale. Tuttavia, molti sistemi non hanno accesso continuo a una connessione di rete, quindi gli orologi hardware sono utili per consentire a Linux di impostare l'orario di sistema basandosi su di essi. È meglio che impostare manualmente l'ora, anche se potrebbe discostarsi dal tempo reale.
Conclusione
In questo articolo vengono esaminati alcuni strumenti per la gestione di date, ore e fusi orari. Lo strumento systemd-timesyncd fornisce un client NTP in grado di sincronizzare il tempo sull'host locale con un server NTP. Tuttavia, systemd-timesyncd non fornisce un servizio server, quindi, se hai bisogno di un server NTP nella tua rete, devi usare qualcos'altro, ad esempio Chrony, per funzionare come server.
Preferisco avere un'unica implementazione per qualsiasi servizio nella mia rete, quindi utilizzo Chrony. Se non hai bisogno di un server NTP locale o se non ti dispiace usare Chrony come server e systemd-timesyncd come client SNTP. Infondo non c'è bisogno di utilizzare le ulteriori funzionalità di Chrony come client, se ti accontenti delle funzionalità di systemd-timesyncd.
Un'altra osservazione: non sei obbligato a utilizzare gli strumenti systemd per implementare NTP. Puoi usare una vecchia versione di ntpd, Chrony o un'altra implementazione di NTP. Infatti, systemd è composto da molti servizi; molti di essi sono facoltativi, quindi puoi disabilitarli e utilizzare qualcos'altro al loro posto. Non è un grande mostro monolitico. Puoi non amare systemd o le sue parti, ma devi prendere una decisione informata.
Mi piace l'implementazione di NTP in systemd, ma preferisco Chrony, perché risponde meglio alle mie esigenze. Questo è Linux, baby -)
In base alla pubblicità
VDSina offre , una vasta gamma di sistemi operativi per installazione automatica, possibilità di installare qualsiasi OS dalla propria , comoda sviluppo interno e pagamento giornaliero. Ricordiamo che abbiamo server eterni, che sicuramente sono al di fuori del tempo 😉
Fonte: habr.com
