La maggior parte di noi tiene d'occhio l'ora. Ci svegliamo in tempo per eseguire i nostri rituali mattutini e andare al lavoro, fare una pausa pranzo, rispettare le scadenze dei progetti, festeggiare i compleanni e le festività, prendere un aereo e così via.
Inoltre, alcuni di noi sono ossessionati dal tempo. I miei orologi funzionano con energia solare e ottengono l'ora esatta dal National Institute of Standards and Technology () a Fort Collins, in Colorado, tramite una stazione radio a onde lunghe. I segnali orari sono sincronizzati con gli orologi atomici, anch'essi ubicati 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 seguono l'ora.
Ci sono molte ragioni per cui i nostri dispositivi e computer hanno bisogno di un'ora esatta. Ad esempio, nel settore bancario, nei mercati finanziari e in altre imprese finanziarie, le transazioni devono avvenire nell'ordine corretto e le sequenze temporali precise sono di importanza critica.
I nostri telefoni, tablet, automobili, sistemi GPS e computer richiedono una precisa impostazione di tempo e data. Voglio che l'orologio sul desktop del mio computer mostri l'ora corretta. Voglio che i promemoria nel mio calendario locale appaiano al momento giusto. Un'ora corretta garantisce anche che i compiti cron e systemd vengano eseguiti al momento giusto.
Data e ora sono importanti anche per la registrazione, quindi è un po' più semplice trovare vari log in base alla data e all'ora. Ad esempio, una volta lavoravo in DevOps (all'epoca non si chiamava così) e gestivo la configurazione del sistema di posta elettronica nella Carolina del Nord. In passato gestivamo oltre 20 milioni di email al giorno. Tenere traccia delle email attraverso una serie di server o determinare l'esatta sequenza di eventi utilizzando file di log su host geograficamente distribuiti può essere molto più semplice se i computer coinvolti sono sincronizzati nel tempo.
Un tempo è unico — ci sono molte ore
I server Linux devono tenere in considerazione che esiste il tempo di sistema e il tempo RTC. L'RTC (Real Time Clock — orologio in tempo reale) è un nome un po' strano e non molto preciso per i clock hardware.
I clock hardware funzionano continuamente, anche quando il computer è spento, utilizzando una batteria sulla scheda madre del sistema. La funzione principale dell'RTC è quella di mantenere il tempo quando la connessione con il server di tempo non è disponibile. In periodi in cui non era possibile connettersi a un server di tempo 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'orario di sistema utilizzando l'interfaccia hardware di configurazione del BIOS, per assicurarsi che fosse corretto.
I clock hardware non comprendono il concetto di fusi orari; nell'RTC è memorizzato solo l'orario, e 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 utilizzando uno strumento di cui parlerò più avanti in questo articolo.
Il tempo di sistema è quello visualizzato dall'OS sull'orologio GUI sul tuo desktop, nei risultati del comando date e nei timestamp dei log. Si riferisce anche ai tempi di creazione, modifica e apertura dei file.
Nella pagina fornisce una descrizione completa del RTC e degli orologi di sistema.
Cosa c'è con NTP?
I computer in tutto il mondo utilizzano NTP (Network Time Protocol) per sincronizzare il loro tempo con orologi di riferimento standard tramite Internet, utilizzando una gerarchia di server NTP. I server di tempo di livello 1 sono direttamente connessi 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 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, ci sono diverse migliaia di server NTP Stratum 2 pubblicamente disponibili per tutti. Molte organizzazioni e utenti (incluso me stesso) con un gran numero di host che richiedono un server NTP preferiscono impostare i propri server di ora, in modo che solo un host locale si connetta ai server Stratum 2 o 3. Successivamente, configurano i rimanenti nodi nella rete per utilizzare il server di tempo locale. Nel caso della mia rete domestica, questo è un server di livello 3.
Diverse implementazioni di NTP
L'implementazione originale di NTP è ntpd. Successivamente, si sono aggiunti due nuovi strumenti, chronyd e systemd-timesyncd. Tutti e tre sincronizzano l'ora dell'host locale con il server di tempo NTP. Il servizio systemd-timesyncd non è affidabile come chronyd, ma è sufficiente per la maggior parte degli scopi. Se l'RTC non è sincronizzato, può correggere gradualmente l'ora di sistema per allinearsi con il server NTP quando l'ora di sistema locale è leggermente disallineata. Il servizio systemd-timesync non può essere utilizzato come server di tempo.
— è l'implementazione di NTP, che comprende due programmi: il demone chronyd e un'interfaccia a riga di comando chiamata chronyc. Chrony offre alcune funzionalità che sono semplicemente indispensabili in molti casi:
- Chrony può sincronizzarsi con un server di tempo molto più rapidamente rispetto al vecchio servizio ntpd. Questo è ottimo per laptop o desktop che non sono sempre accesi.
- Può compensare le fluttuazioni della frequenza di clock, ad esempio quando l'host entra in modalità sospensione o si riattiva, oppure quando la frequenza di clock varia a causa di un cambiamento improvviso che rallenta le frequenze clock a carichi ridotti.
- Risolve i problemi temporali legati a connessioni di rete instabili o sovraccarichi di rete.
- Regola le latenze in rete.
- Dopo la sincronizzazione iniziale del tempo, Chrony non ferma mai l'orologio. Questo garantisce intervalli temporali stabili e coerenti per molti servizi di sistema e applicazioni.
- Chrony può funzionare anche senza una connessione di rete. In questo caso, l'host locale o il server possono essere aggiornati manualmente.
- Chrony può fungere da server NTP.
In breve: NTP è un protocollo che può essere implementato su un host Linux utilizzando Chrony o systemd-timesyncd.
I pacchetti RPM per NTP, Chrony e systemd-timesyncd sono disponibili nei repository standard di Fedora. RPM systemd-udev è un gestore di eventi del kernel, che è preinstallato di default in Fedora, ma non è obbligatorio per l'uso.
Puoi installarli tutti e tre e passare da uno all'altro, ma questo comporterebbe inutili complicazioni. È meglio evitarlo. Le versioni moderne di Fedora, CentOS e RHEL hanno adottato Chrony come implementazione standard e includono anche systemd-timesyncd. Credo che Chrony funzioni bene, offra una migliore interfaccia rispetto al servizio NTP, fornisca molte più informazioni e aumenti il controllo, il che sicuramente piacerà agli amministratori di sistema.
Disabilitazione dei servizi NTP
È possibile che un servizio NTP sia già in esecuzione sul tuo host. Se è così, dovrai disabilitarlo prima di passare a qualcos'altro. Avevo avviato chronyd, quindi ho usato i seguenti comandi per fermarlo e disabilitarlo. Esegui i comandi appropriati per qualsiasi demone NTP che stai utilizzando sul tuo host:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Rimosso /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#Controlla che il servizio sia fermo e disabilitato:
[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - Client/server NTP
Caricato: caricato (/usr/lib/systemd/system/chronyd.service; disabilitato; preset fornitore: abilitato)
Attivo: inattivo (morto)
Documenti: man:chronyd(8)
man:chrony.conf(5)
[root@testvm1 ~]#Verifica dello stato prima dell'avvio
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
Impossibile interpellare il server: impossibile attivare il peer remoto.Una richiesta diretta di stato fornisce informazioni importanti. Ad esempio, il comando timedatectl senza argomenti o parametri esegue la sottocomando status per impostazione predefinita:
[root@testvm1 ~]# timedatectl status
Local time: Fri 2020-05-15 08:43:10 EDT
Universal time: Fri 2020-05-15 12:43:10 UTC
RTC time: Fri 2020-05-15 08:43:08
Time zone: America/New_York (EDT, -0400)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode cannot be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#In questo modo otterrete l'ora locale per il vostro host, l'ora UTC e l'ora RTC. In questo caso, l'ora di sistema è impostata sul fuso orario America/New_York (TZ), l'RTC è impostato sull'ora nel fuso orario locale e il servizio NTP non è attivo. L'ora dell'RTC ha iniziato a deviare leggermente dall'ora di sistema. Questo è normale per i sistemi i cui orologi non sono stati sincronizzati. L'entità della deviazione sull'host dipende dal tempo trascorso dall'ultima sincronizzazione del sistema.
Abbiamo anche ricevuto un avviso sull'uso dell'ora locale per il RTC: questo riguarda i cambiamenti di fuso orario e le impostazioni dell'ora legale. Se il computer è spento nel momento in cui devono essere effettuate le modifiche, il tempo del RTC non verrà cambiato. Ma per i server o altri host che operano 24 ore su 24, questo non è affatto un problema. Inoltre, qualsiasi servizio che offre sincronizzazione dell'ora NTP correggerà il tempo dell'host anche all'inizio del processo di avvio, quindi dopo che l'avvio è completato, il tempo tornerà a essere corretto.
Impostazione del fuso orario
Di solito si specifica il fuso orario durante la procedura di installazione, e non si ha bisogno di cambiarlo in seguito. Tuttavia, ci sono casi 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 directory /usr/share/zoneinfo. Per impostazione predefinita, per il mio fuso orario, il sistema scrive questo: /etc/ localtime -> ../usr/share/zoneinfo/America/New_York. Ma non è necessario conoscere tali dettagli per cambiare il fuso orario.
La cosa principale è conoscere il nome ufficiale del fuso orario per la tua posizione e il comando corrispondente. Ad esempio, se desideri cambiare il fuso orario su 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
Tue 19 May 2020 04:47:49 PM EDT
[root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles
[root@testvm2 ~]# date
Tue 19 May 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 NTP di facile gestione nel contesto di systemd. È installato per impostazione predefinita in Fedora e Ubuntu. Tuttavia, viene avviato per impostazione predefinita solo in Ubuntu. Non sono sicuro sugli altri distribuzioni. Puoi verificare da solo:
[root@testvm1 ~]# systemctl status systemd-timesyncdConfigurazione di systemd-timesyncd
Il file di configurazione per systemd-timesyncd è /etc/systemd/timesyncd.conf. Questo è 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 i valori predefiniti, non è necessario modificarli (a meno che non ci siano motivi per farlo). Se non hai un server NTP specificato nella riga NTP=, Fedora utilizza come server di default il server di tempo di Fedora. Di solito aggiungo il mio server di tempo:
NTP=myntpserverAvvio di timesync
Puoi avviare e attivare 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
Ora locale: Sab 2020-05-16 14:34:54 EDT
Ora universale: Sab 2020-05-16 18:34:54 UTC
Ora 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 divergenza aumenta di altri pochi secondi nei giorni successivi. Poiché l'RTC non considera i 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, allora significa che non corrisponde nemmeno 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
Loaded: caricato (/usr/lib/systemd/system/systemd-timesyncd.service; abilitato; preset del fornitore: disabilitato)
Active: attivo (in esecuzione) da Sab 2020-05-16 13:56:53 EDT; 18h fa
Docs: man:systemd-timesyncd.service(8)
Main PID: 822 (systemd-timesyn)
Status: "Sincronizzazione iniziale con il server di tempo 163.237.218.19:123 (2.fedora.pool.ntp.org)."
Tasks: 2 (limite: 10365)
Memory: 2.8M
CPU: 476ms
CGroup: /system.slice/systemd-timesyncd.service
└─822 /usr/lib/systemd/systemd-timesyncd
May 16 09:57:24 testvm2.both.org systemd[1]: Avvio della sincronizzazione dell'ora di rete...
May 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: L'ora dell'orologio di sistema non è impostata o è tornata indietro, ripristino dal timestamp registrato: Sab 2020-05-16 13:56:53 EDT
May 16 13:56:53 testvm2.both.org systemd[1]: Sincronizzazione dell'ora di rete avviata.
May 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Sincronizzazione iniziale con il server di tempo 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#Si prega di notare il messaggio di registro che indica che l'ora di sistema non è impostata o è stata ripristinata. Il servizio Timesync imposta l'ora di sistema in base al timestamp. I timestamp sono gestiti dal demone timesync e vengono creati ad ogni sincronizzazione confermata.
Il comando timedatectl non può prendere il valore dell'orologio hardware dal sistema. Può impostare solo l'ora e la data in base al valore inserito nella riga di comando. È possibile impostare il RTC sullo stesso valore dell'ora di sistema usando il comando hwclock:
[root@testvm2 ~]# /sbin/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
Local time: Lun 2020-05-18 13:56:46 EDT
Universal time: Lun 2020-05-18 17:56:46 UTC
RTC time: Lun 2020-05-18 13:56:46
Time zone: America/New_York (EDT, -0400)
System clock synchronized: sì
NTP service: attivo
RTC in local TZ: sìL'opzione --localtime indica che l'orologio hardware mostra l'ora locale e non l'UTC.
Perché hai bisogno del RTC?
Qualsiasi implementazione NTP imposterà l'orologio di sistema all'avvio. E perché allora il RTC? Non è esattamente così: questo accadrà solo se hai una connessione di rete con un server di tempo. Tuttavia, molti sistemi non hanno accesso continuo a una connessione di rete, quindi l'orologio hardware è utile affinché Linux possa impostare l'ora di sistema basandosi su di esso. È meglio che impostare l'ora manualmente, anche se potrebbe discostarsi dall'ora reale.
Conclusione
In questo articolo vengono esaminati alcuni strumenti per gestire date, ore e fusi orari. Lo strumento systemd-timesyncd fornisce un client NTP che può sincronizzare l'ora sul 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 una sola 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. Non c'è bisogno di utilizzare le funzionalità aggiuntive di Chrony come client se ti accontenti delle capacità di systemd-timesyncd.
Un'altra osservazione: non sei obbligato a utilizzare gli strumenti di systemd per implementare NTP. Puoi utilizzare una vecchia versione di ntpd, Chrony o un'altra implementazione di NTP. Infatti, systemd è composto da molti servizi; molti di essi sono facoltativi, quindi possono essere disabilitati e sostituiti con qualcos'altro. Non si tratta di un mostro monolitico enorme. 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é meglio soddisfa le mie esigenze. Questo è Linux, baby -)
In pubblicità
VDSina offre , un'ampia scelta di sistemi operativi per installazione automatica, con la possibilità di installare qualsiasi SO dal proprio , comodo sviluppo e pagamento giornaliero. Ricordiamo che abbiamo server eterni, che sono davvero fuori dal tempo 😉
Fonte: habr.com
