Sincronització de l'hora de Linux: NTP, Chrony i systemd-timesyncd

La majoria de la gent fa un seguiment del temps. Ens llevem a temps per completar els nostres rituals matinals i anar a treballar, fer una pausa per dinar, complir els terminis dels projectes, celebrar aniversaris i vacances, pujar a un avió, etc.

A més: alguns de nosaltres estem obsessionats amb el temps. El meu rellotge funciona amb energia solar i obté l'hora precisa de l'Institut Nacional d'Estàndards i Tecnologia (NIST) a Fort Collins, Colorado per ràdio d'ona llarga WWVB. Els senyals de temps estan sincronitzats amb el rellotge atòmic, també situat a Fort Collins. El meu Fitbit s'està sincronitzant amb el meu telèfon que s'està sincronitzant amb el servidor NTP, que finalment es sincronitza amb el rellotge atòmic.

Els dispositius també fan un seguiment del temps

Hi ha moltes raons per les quals els nostres dispositius i ordinadors necessiten una hora precisa. Per exemple, a la banca, els mercats de valors i altres negocis financers, les transaccions s'han de dur a terme en l'ordre adequat, i les seqüències de temps precises són fonamentals per a això.

Els nostres telèfons, tauletes, cotxes, sistemes GPS i ordinadors requereixen una configuració precisa de l'hora i la data. Vull que el rellotge de l'escriptori del meu ordinador mostri l'hora correcta. Vull que els recordatoris apareguin al meu calendari local en el moment adequat. L'hora correcta també garanteix que els treballs cron i systemd s'executen en el moment correcte.

La data i l'hora també són importants per al registre, de manera que és una mica més fàcil trobar determinats registres basats en la data i l'hora. Per exemple, una vegada vaig treballar a DevOps (aleshores no es deia així) i estava configurant un sistema de correu electrònic a l'estat de Carolina del Nord. Abans processàvem més de 20 milions de correus electrònics al dia. El seguiment del correu electrònic a través d'una sèrie de servidors, o la determinació de la seqüència exacta d'esdeveniments mitjançant fitxers de registre en amfitrions dispersos geogràficament, pot ser molt més fàcil si els ordinadors respectius es sincronitzen a temps.

Una vegada, moltes hores

Els amfitrions Linux han de tenir en compte que hi ha una hora del sistema i una hora RTC. RTC (Real Time Clock) és un nom una mica estrany i poc precís per a un rellotge de maquinari.

El rellotge de maquinari funciona contínuament fins i tot quan l'ordinador està apagat, utilitzant la bateria de la placa base del sistema. La funció principal de l'RTC és emmagatzemar el temps quan no hi ha una connexió a un servidor de temps disponible. En els dies en què era impossible connectar-se a un servidor de temps per Internet, cada ordinador havia de tenir un rellotge intern precís. Els sistemes operatius havien d'accedir a l'RTC en el moment de l'arrencada i l'usuari havia d'establir manualment l'hora del sistema mitjançant la interfície de configuració de maquinari de la BIOS per assegurar-se que era correcta.

Els rellotges de maquinari no entenen el concepte de zones horàries; RTC només emmagatzema l'hora, no la zona horària ni el desplaçament de l'UTC (temps universal coordinat, també conegut com a GMT o hora mitjana de Greenwich). Podeu instal·lar RTC mitjançant una eina que tractaré més endavant en aquest article.

L'hora del sistema és l'hora que el sistema operatiu mostra al rellotge GUI del vostre escriptori, a la sortida de l'ordre de data, a les marques de temps dels registres. Això també s'aplica quan es creen, es modifiquen i s'obren fitxers.

A la pàgina home per rtc hi ha una descripció completa de l'RTC i del rellotge del sistema.

Què passa amb NTP?

Els ordinadors de tot el món utilitzen NTP (Network Time Protocol) per sincronitzar la seva hora amb rellotges de referència estàndard a través d'Internet mitjançant una jerarquia de servidors NTP. Els principals servidors de temps es troben a la capa 1 i estan connectats directament a diversos serveis horàries nacionals a la capa 0 mitjançant satèl·lit, ràdio o fins i tot mòdems a través de línies telefòniques. Els serveis de temps de capa 0 poden ser un rellotge atòmic, un receptor de ràdio que està sintonitzat amb senyals transmesos per rellotges atòmics o un receptor GPS que utilitza senyals de rellotge molt precises transmeses per satèl·lits GPS.

La gran majoria dels servidors de referència tenen diversos milers de servidors públics d'estrat 2 NTP oberts al públic. Moltes organitzacions i usuaris (inclòs jo mateix) amb molts amfitrions que necessiten un servidor NTP opten per configurar els seus propis servidors de temps, de manera que només un amfitrió local accedeix a l'estrat 2 o 3. Després configuren els nodes restants de la xarxa per utilitzar el local. servidor de temps. En el cas de la meva xarxa domèstica, es tracta d'un servidor de capa 3.

Diverses implementacions de NTP

La implementació original de NTP és ntpd. Aleshores se li van unir dos de més nous, chronyd i systemd-timesyncd. Tots tres sincronitzen l'hora de l'amfitrió local amb un servidor d'hora NTP. El servei systemd-timesyncd no és tan fiable com chronyd, però és prou bo per a la majoria de propòsits. Si l'RTC no està sincronitzat, pot ajustar gradualment l'hora del sistema per sincronitzar-se amb el servidor NTP quan l'hora del sistema local varia lleugerament. El servei systemd-timesync no es pot utilitzar com a servidor de temps.

Crònica és una implementació de NTP que conté dos programes: el dimoni chronyd i una interfície de línia d'ordres anomenada chronyc. Chrony té algunes característiques que són indispensables en molts casos:

• Chrony es pot sincronitzar amb un servidor de temps molt més ràpid que l'antic servei ntpd. Això és bo per a portàtils o ordinadors de sobretaula que no funcionen tot el temps.
• Pot compensar les fluctuacions del rellotge, com ara quan l'amfitrió es posa en suspensió o entra en mode de repòs, o quan el rellotge canvia a causa del salt de freqüència, que alenteix els rellotges amb càrregues baixes.
• Soluciona problemes de temps relacionats amb la connexió de xarxa inestable o la congestió de la xarxa.
• Regula els retards de la xarxa.
• Després de la sincronització de l'hora inicial, Chrony no atura mai el rellotge. Això proporciona intervals de temps estables i coherents per a molts serveis i aplicacions del sistema.
• Chrony pot funcionar fins i tot sense connexió de xarxa. En aquest cas, l'amfitrió o servidor local es pot actualitzar manualment.
• Chrony pot actuar com a servidor NTP.

Un cop més, NTP és un protocol que es pot implementar en un host Linux mitjançant Chrony o systemd-timesyncd.

Els RPM NTP, Chrony i systemd-timesyncd estan disponibles als dipòsits estàndard de Fedora. El systemd-udev RPM és un gestor d'esdeveniments del nucli que s'instal·la per defecte a Fedora, però és opcional.

Podeu instal·lar-los tres i canviar entre ells, però això us generarà un mal de cap addicional. Així que és millor no fer-ho. Les versions modernes de Fedora, CentOS i RHEL s'han traslladat a Chrony com a implementació predeterminada i també tenen systemd-timesyncd. Trobo que Chrony funciona bé, proporciona una interfície millor que el servei NTP, proporciona molta més informació i més control, que els administradors del sistema segur que gaudiran.

Desactivació dels serveis NTP

És possible que el servei NTP ja s'està executant al vostre amfitrió. Si és així, heu de desactivar-lo abans de canviar a una altra cosa. Tenia chronyd en execució, així que vaig utilitzar les ordres següents per aturar-lo i desactivar-lo. Executeu les ordres adequades per a qualsevol dimoni NTP que esteu executant al vostre amfitrió:

[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#

Comproveu que el servei estigui aturat i desactivat:

[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - NTP client/server
     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 ~]#

Comprovació d'estat abans del llançament

L'estat de sincronització del rellotge del sistema us permet determinar si el servei NTP s'està executant. Com que encara no heu iniciat NTP, l'ordre timesync-status indicarà això:

[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.

Una sol·licitud d'estat directa proporciona informació important. Per exemple, l'ordre timedatectl sense argument ni opcions executa la subordre status per defecte:

[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 ~]#

Això us donarà l'hora local del vostre amfitrió, l'hora UTC i l'hora RTC. En aquest cas, l'hora del sistema s'estableix a la zona horària d'Amèrica/Nova_York (TZ), l'RTC s'estableix a l'hora de la zona horària local i el servei NTP no està actiu. L'hora RTC ha començat a desviar-se lleugerament de l'hora del sistema. Això és normal per als sistemes els rellotges dels quals no s'han sincronitzat. La quantitat de compensació a l'amfitrió depèn del temps que hagi passat des de la darrera sincronització del sistema.

També hem rebut un avís sobre l'ús de l'hora local per a RTC; això s'aplica als canvis de zona horària i a la configuració d'horari d'estiu. Si l'ordinador s'apaga quan cal fer canvis, el RTC no canviarà. Però per als servidors o altres amfitrions que funcionen durant tot el dia, això no és cap problema. A més, qualsevol servei que proporcioni sincronització d'hora NTP ajustarà l'hora de l'amfitrió durant la fase inicial d'inici, de manera que l'hora tornarà a ser correcta un cop finalitzada l'inici.

Configuració de la zona horària

Normalment, especifiqueu la zona horària durant el procediment d'instal·lació i no teniu la tasca de canviar-la més endavant. Tanmateix, hi ha moments en què cal canviar la zona horària. Hi ha diverses eines que poden ajudar. Linux utilitza fitxers de zona horària per determinar la zona horària local d'un amfitrió. Aquests fitxers es troben al directori /usr/share/zoneinfo. Per defecte, per a la meva zona horària, el sistema prescriu això: /etc/localtime -> ../usr/share/zoneinfo/America/New_York. Però no cal conèixer aquestes subtileses per canviar la zona horària.

El més important és conèixer el nom oficial de la zona horària de la vostra ubicació i l'ordre corresponent. Suposem que voleu canviar la zona horària a Los Angeles:

[root@testvm2 ~]# timedatectl list-timezones | column
<SNIP>
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/Helsinki
<SNIP>

Ara podeu configurar la zona horària. Vaig utilitzar l'ordre date per comprovar si hi ha canvis, però també podeu utilitzar 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 ~]#

Ara podeu tornar a canviar la zona horària del vostre amfitrió a l'hora local.

systemd-timesyncd

El dimoni systemd timesync proporciona una implementació NTP que és fàcil de gestionar en el context systemd. S'instal·la per defecte a Fedora i Ubuntu. Tanmateix, només s'inicia per defecte a Ubuntu. No estic segur d'altres distribucions. Pots comprovar tu mateix:

[root@testvm1 ~]# systemctl status systemd-timesyncd

Configuració de systemd-timesyncd

El fitxer de configuració per a systemd-timesyncd és /etc/systemd/timesyncd.conf. Aquest és un fitxer senzill amb menys opcions activades que els antics serveis NTP i chronyd. Aquí teniu el contingut d'aquest fitxer (sense més modificacions) a la meva màquina virtual 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=2048

L'única secció que conté, a més de comentaris, és [Time]. Totes les altres línies estan comentades. Aquests són els valors predeterminats i no s'han de canviar (tret que tingueu una raó per fer-ho). Si no teniu un servidor de temps NTP definit a la línia NTP=, Fedora s'utilitzarà per defecte un servidor temporal de Fedora. Normalment afegeixo el meu servidor de temps:

NTP=myntpserver

S'està executant la sincronització temporal

Podeu iniciar i activar systemd-timesyncd així:

[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 ~]#

Configuració del rellotge del maquinari

A continuació es mostra com es veu la situació després d'executar timesyncd:

[root@testvm2 systemd]# timedatectl
               Local time: Sat 2020-05-16 14:34:54 EDT  
           Universal time: Sat 2020-05-16 18:34:54 UTC  
                 RTC time: Sat 2020-05-16 14:34:53      
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes                          
              NTP service: active                      
          RTC in local TZ: no    

Inicialment, la diferència entre RTC i hora local (EDT) és inferior a un segon, i la discrepància augmenta un parell de segons més durant els propers dies. Com que no hi ha cap concepte de zones horàries a RTC, l'ordre timedatectl ha de realitzar una comparació per determinar la zona horària correcta. Si l'hora RTC no coincideix exactament amb l'hora local, tampoc coincideix amb la zona horària local.

Buscant més informació, vaig comprovar l'estat de systemd-timesync i vaig trobar això:

[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-05-16 13:56:53 EDT; 18h ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 822 (systemd-timesyn)
     Status: "Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org)."
      Tasks: 2 (limit: 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]: Starting Network Time Synchronization...
May 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: System clock time unset or jumped backwards, restoring from recorded timestamp: Sat 2020-05-16 13:56:53 EDT
May 16 13:56:53 testvm2.both.org systemd[1]: Started Network Time Synchronization.
May 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#

Observeu el missatge de registre que diu que l'hora del sistema no s'ha establert o que s'ha restablert. El servei Timesync estableix l'hora del sistema en funció de la marca de temps. Les marques de temps es mantenen pel dimoni timesync i es creen en cada sincronització correcta.

L'ordre timedatectl no té cap manera de prendre el valor del rellotge de maquinari del rellotge del sistema. Només pot establir l'hora i la data a partir del valor introduït a la línia d'ordres. Podeu establir l'RTC al mateix valor que l'hora del sistema mitjançant l'ordre hwclock:

[root@testvm2 ~]# /sbin/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
               Local time: Mon 2020-05-18 13:56:46 EDT  
           Universal time: Mon 2020-05-18 17:56:46 UTC  
                 RTC time: Mon 2020-05-18 13:56:46      
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes                          
              NTP service: active                      
          RTC in local TZ: yes

L'opció --localtime indica al rellotge del maquinari que mostri l'hora local, no UTC.

Per què necessiteu RTC?

Qualsevol implementació de NTP establirà el rellotge del sistema a l'hora d'inici. I per què llavors RTC? Això no és del tot cert: això només passarà si teniu una connexió de xarxa al servidor de temps. Tanmateix, molts sistemes no sempre tenen accés a una connexió de xarxa, de manera que un rellotge de maquinari és útil per a Linux per configurar l'hora del sistema. Això és millor que configurar l'hora manualment, tot i que pot desviar-se del temps real.

Conclusió

En aquest article s'han revisat algunes eines per manipular la data, l'hora i les zones horàries. L'eina systemd-timesyncd proporciona un client NTP que pot sincronitzar l'hora de l'amfitrió local amb un servidor NTP. Tanmateix, systemd-timesyncd no ofereix un servei de servidor, de manera que si necessiteu un servidor NTP a la vostra xarxa, heu d'utilitzar una altra cosa, com Chrony, per actuar com a servidor.

Prefereixo tenir una implementació única per a qualsevol servei de la meva xarxa, així que faig servir Chrony. Si no necessiteu un servidor NTP local, o si no us importa utilitzar Chrony com a servidor i systemd-timesyncd com a client SNTP. Després de tot, no cal utilitzar les funcions addicionals de Chrony com a client si esteu satisfets amb la funcionalitat de systemd-timesyncd.

Una altra nota: no cal que utilitzeu les eines de systemd per implementar NTP. Podeu utilitzar una versió anterior de ntpd, Chrony o una altra implementació NTP. Després de tot, systemd consta d'un gran nombre de serveis; molts d'ells són opcionals, de manera que podeu desactivar-los i utilitzar una altra cosa. Aquest no és un monstre monolític enorme. És possible que no us agradi systemd o parts d'ell, però hauríeu de prendre una decisió informada.

M'agrada la implementació de NTP de systemd, però prefereixo Chrony perquè s'adapta millor a les meves necessitats. És Linux, nena -)

Sobre els drets de publicitat

VDSina ofereix servidors per a qualsevol tasca, una gran selecció de sistemes operatius per a la instal·lació automàtica, és possible instal·lar qualsevol sistema operatiu des del vostre ISO, còmode panell de control desenvolupament propi i pagament diari. Recordeu que tenim servidors eterns que són definitivament atemporals 😉

Font: www.habr.com