Linuksa Tempo-Sinkronigo: NTP, Chrony kaj systemd-timesyncd

Plej multaj homoj kontrolas tempon. Ni ellitiĝas ĝustatempe por plenumi niajn matenajn ritojn kaj labori, preni tagmanĝan paŭzon, plenumi projektajn limdatojn, festi naskiĝtagojn kaj feriojn, suriri aviadilon, ktp.

Cetere: kelkaj el ni estas obsedita de tempo. Mia horloĝo funkcias per suna energio kaj ricevas precizan horon de la Nacia Instituto pri Normoj kaj Teknologio (NIST) al Fort Collins, Kolorado per longonda radio WWVB. La temposignaloj estas sinkronigitaj kun la atomhorloĝo, ankaŭ situanta ĉe Fort Collins. Mia Fitbit sinkronigas kun mia telefono, kiu sinkronigas kun la servilo NTP, kiu poste sinkronigas kun la atomhorloĝo.

Aparatoj ankaŭ kontrolas tempon

Estas multaj kialoj, kial niaj aparatoj kaj komputiloj bezonas precizan tempon. Ekzemple, en bankado, borsmerkatoj kaj aliaj financaj entreprenoj, transakcioj devas esti faritaj en la ĝusta ordo, kaj precizaj temposekvencoj estas kritikaj por tio.

Niaj telefonoj, tablojdoj, aŭtoj, GPS-sistemoj kaj komputiloj ĉiuj postulas precizajn tempo- kaj datajn agordojn. Mi volas, ke la horloĝo sur la labortablo de mia komputilo montru la ĝustan horon. Mi volas, ke memorigiloj aperu en mia loka kalendaro en la ĝusta tempo. La ĝusta tempo ankaŭ certigas, ke la cron kaj systemd laboroj funkcias en la ĝusta tempo.

Dato kaj tempo ankaŭ gravas por registri, do estas iom pli facile trovi certajn protokolojn bazitajn sur dato kaj horo. Ekzemple, mi iam laboris en DevOps (tiutempe ĝi ne estis nomita tiel) kaj instalis retpoŝtan sistemon en la ŝtato Norda Karolino. Ni kutimis procesi pli ol 20 milionojn da retpoŝtoj ĉiutage. Spurado de retpoŝto per serio de serviloj, aŭ determini la precizan sinsekvon de eventoj uzante protokolojn sur geografie disigitaj gastigantoj, povas esti multe pli facila se la respektivaj komputiloj estas sinkronigitaj ĝustatempe.

Unu fojon - multajn horojn

Linuksaj gastigantoj devas konsideri, ke ekzistas sistema tempo kaj RTC-tempo. RTC (Real Time Clock) estas iomete stranga kaj ne tre preciza nomo por aparata horloĝo.

La aparatara horloĝo funkcias senĉese eĉ kiam la komputilo estas malŝaltita, uzante la kuirilaron sur la sistemplato. La ĉefa funkcio de la RTC estas stoki tempon kiam konekto al temposervilo ne estas disponebla. En la tempoj kiam estis neeble konekti al temposervilo per la Interreto, ĉiu komputilo devis havi precizan internan horloĝon. Operaciumoj devis aliri la RTC ĉe lanĉtempo kaj la uzanto devis mane agordi la sistemtempon uzante la BIOS-hardvaran agordan interfacon por certigi ke ĝi estis ĝusta.

Aparataj horloĝoj ne komprenas la koncepton de horzonoj; RTC nur konservas la tempon, ne la horzonon aŭ ofseton de UTC (Kunordigita Universala Tempo, ankaŭ konata kiel GMT aŭ Greenwich Mean Time). Vi povas instali RTC per ilo, kiun mi traktos poste en ĉi tiu artikolo.

La sistema tempo estas la tempo, kiun la OS montras sur la GUI-horloĝo sur via labortablo, en la eligo de la data komando, en la tempomarkoj de la protokoloj. Ĉi tio ankaŭ validas kiam dosieroj estas kreitaj, modifitaj kaj malfermitaj.

Sur paĝo viro por rtc estas plena priskribo de la RTC kaj la sistema horloĝo.

Kio estas kun NTP?

Komputiloj ĉie en la mondo uzas NTP (Network Time Protocol) por sinkronigi sian tempon kun normaj referenchorloĝoj tra la Interreto uzante hierarkion de NTP-serviloj. La ĉefaj tempserviloj estas ĉe tavolo 1 kaj ili estas rekte konektitaj al diversaj naciaj temposervoj ĉe tavolo 0 per satelito, radio aŭ eĉ modemoj tra telefonlinioj. Tavolo 0 temposervoj povas esti atomhorloĝo, radioricevilo kiu estas agordita al signaloj elsenditaj per atomhorloĝoj, aŭ GPS-ricevilo kiu uzas tre precizajn horloĝsignalojn elsenditajn per GPS-satelitoj.

La granda plimulto de la referencaj serviloj havas plurajn milojn da publikaj NTP-tavolo 2-serviloj malfermitaj al publiko. Multaj organizoj kaj uzantoj (inkluzive de mi) kun multaj gastigantoj, kiuj bezonas NTP-servilon, elektas agordi siajn proprajn tempservilojn do nur unu loka gastiganto aliras stratumon 2 aŭ 3. Ili tiam agordas la ceterajn nodojn en la reto por uzi la lokan. tempservilo. En la kazo de mia hejma reto, ĉi tio estas tavola 3-servilo.

Diversaj efektivigoj de NTP

La origina efektivigo de NTP estas ntpd. Ĝi tiam estis akompanita per du pli novaj, chronyd kaj systemd-timesyncd. Ĉiuj tri sinkronigas la lokan gastigan tempon kun NTP-tempa servilo. La servo systemd-timesyncd ne estas tiel fidinda kiel chronyd, sed ĝi estas sufiĉe bona por plej multaj celoj. Se la RTC estas malsinkronigita, ĝi povas iom post iom ĝustigi la sisteman tempon por sinkronigi kun la NTP-servilo kiam la loka sistema tempo drivas iomete. La servo systemd-timesync ne povas esti uzata kiel tempservilo.

Kroniko estas efektivigo de NTP kiu enhavas du programojn: la chronyd-demono kaj komandlinia interfaco nomita chronyc. Chrony havas kelkajn funkciojn, kiuj estas nemalhaveblaj en multaj kazoj:

• Chrony povas sinkronigi kun temposervilo multe pli rapide ol la malnova ntpd-servo. Ĉi tio estas bona por tekkomputiloj aŭ labortabloj, kiuj ne funkcias ĉiam.
• Ĝi povas kompensi por horloĝfluktuoj, kiel ekzemple kiam la gastiganto endormiĝas aŭ eniras dormreĝimon, aŭ kiam la horloĝo ŝanĝiĝas pro frekvenca saltado, kiu malrapidigas horloĝojn ĉe malaltaj ŝarĝoj.
• Ĝi solvas tempproblemojn rilatajn al malstabila retkonekto aŭ retŝtopiĝo.
• Ĝi reguligas retajn prokrastojn.
• Post la komenca temposinkronigo, Chrony neniam haltigas la horloĝon. Ĉi tio disponigas stabilajn kaj konsekvencajn tempoperiodojn por multaj sistemaj servoj kaj aplikoj.
• Chrony povas funkcii eĉ sen retkonekto. En ĉi tiu kazo, la loka gastiganto aŭ servilo povas esti ĝisdatigita permane.
• Chrony povas funkcii kiel NTP-servilo.

Denove, NTP estas protokolo kiu povas esti efektivigita sur Linuksa gastiganto uzante Chrony aŭ systemd-timesyncd.

La RPM-oj NTP, Chrony kaj systemd-timesyncd estas haveblaj en la normaj deponejoj de Fedora. La systemd-udev RPM estas kerna okazaĵmanaĝero kiu estas instalita defaŭlte sur Fedora, sed estas laŭvola.

Vi povas instali ĉiujn tri kaj ŝanĝi inter ili, sed ĉi tio kreos kroman kapdoloron. Do estas pli bone ne. Modernaj eldonoj de Fedora, CentOS kaj RHEL moviĝis al Chrony kiel la defaŭlta efektivigo, kaj ili ankaŭ havas systemd-timesyncd. Mi trovas, ke Chrony funkcias bone, provizas pli bonan interfacon ol la NTP-servo, provizas multe pli da informoj kaj kontrolo, kiujn sistemaj administrantoj certe ĝuos.

Malebligante NTP-Servojn

La NTP-servo eble jam funkcias en via gastiganto. Se jes, vi devas malŝalti ĝin antaŭ ol ŝanĝi al io alia. Mi havis chronyd funkcianta do mi uzis la jenajn komandojn por halti kaj malŝalti ĝin. Rulu la taŭgajn komandojn por iu ajn NTP-demono, kiun vi rulas sur via gastiganto:

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

Kontrolu, ke la servo estas haltigita kaj malŝaltita:

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

Kontrolo de stato antaŭ lanĉo

La statuso de sinkronigado de la sistema horloĝo permesas vin determini ĉu la servo NTP funkcias. Ĉar vi ankoraŭ ne komencis NTP, la komando timesync-status aludos ĉi tion:

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

Rekta statuspeto provizas gravajn informojn. Ekzemple, la ordono timedatectl sen argumento aŭ opcioj efektivigas la statusan subkomandon defaŭlte:

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

Ĉi tio donos al vi la lokan horon por via gastiganto, UTC-tempon kaj RTC-tempon. En ĉi tiu kazo, la sistema tempo estas agordita al la horzono de Ameriko / New_York (TZ), la RTC estas agordita al la horo en la loka horzono, kaj la NTP-servo ne aktivas. La RTC-tempo komencis iomete devii de la sistema tempo. Ĉi tio estas normala por sistemoj, kies horloĝoj ne estis sinkronigitaj. La kvanto de ofseto sur la gastiganto dependas de la tempo, kiu pasis de kiam la sistemo estis laste sinkronigita.

Ni ankaŭ ricevis averton pri uzado de loka tempo por RTC - tio validas por horzonŝanĝoj kaj DST-agordoj. Se la komputilo estas malŝaltita kiam ŝanĝoj devas esti faritaj, la RTC ne ŝanĝiĝos. Sed por serviloj aŭ aliaj gastigantoj, kiuj funkcias ĉirkaŭ la horloĝo, ĉi tio tute ne estas problemo. Krome, iu ajn servo, kiu provizas NTP-horan sinkronigon, ĝustigos la tempon de la gastiganto dum la komenca ekfazo, do la tempo estos ĝusta denove post ekfunkciigo.

Agordi la horzonon

Kutime, vi specifas la horzonon dum la instala proceduro kaj vi ne havas la taskon ŝanĝi ĝin poste. Tamen estas tempoj, kiam vi bezonas ŝanĝi la horzonon. Estas pluraj iloj, kiuj povas helpi. Linukso uzas horzonajn dosierojn por determini la lokan horzonon de gastiganto. Ĉi tiuj dosieroj estas en la dosierujo /usr/share/zoneinfo. Defaŭlte, por mia horzono, la sistemo preskribas ĉi tion: /etc/localtime -> ../usr/share/zoneinfo/America/New_York. Sed vi ne bezonas koni tiajn subtilaĵojn por ŝanĝi la horzonon.

La ĉefa afero estas scii la oficialan horzonan nomon por via loko kaj la respondan komandon. Ni diru, ke vi volas ŝanĝi la horzonon al Los-Anĝeleso:

[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>

Nun vi povas agordi la horzonon. Mi uzis la datan komandon por kontroli ŝanĝojn, sed vi ankaŭ povas uzi 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 ~]#

Nun vi povas ŝanĝi la horzonon de via gastiganto reen al loka tempo.

systemd-timesyncd

La systemd timesync-demono disponigas NTP-efektivigon, kiu estas facile administrebla en la systemd-kunteksto. Ĝi estas instalita defaŭlte sur Fedora kaj Ubuntu. Tamen ĝi nur komenciĝas defaŭlte ĉe Ubuntu. Mi ne certas pri aliaj distribuoj. Vi povas kontroli mem:

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

Agordante systemd-timesyncd

La agorda dosiero por systemd-timesyncd estas /etc/systemd/timesyncd.conf. Ĉi tio estas simpla dosiero kun malpli da opcioj ebligitaj ol la malnovaj NTP kaj chronyd-servoj. Jen la enhavo de ĉi tiu dosiero (sen pliaj modifoj) sur mia Fedora VM:

#  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

La sola sekcio, kiun ĝi enhavas, krom komentoj, estas [Tempo]. Ĉiuj aliaj linioj estas komentitaj. Ĉi tiuj estas la defaŭltaj valoroj kaj ne devus esti ŝanĝitaj (krom se vi havas kialon). Se vi ne havas NTP-temposervilon difinitan en la NTP=-linio, Fedora defaŭlte al rezerva temposervilo Fedora. Mi kutime aldonas mian tempservilon:

NTP=myntpserver

Kurante timesync

Vi povas komenci kaj aktivigi systemd-timesyncd tiel:

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

Agordi la aparatan horloĝon

Jen kiel aspektas la situacio post funkciado de 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    

Komence, la diferenco inter RTC kaj loka tempo (EDT) estas malpli ol sekundo, kaj la diferenco pliiĝas je pliaj du sekundoj dum la sekvaj tagoj. Ĉar ekzistas neniu koncepto de horzonoj en RTC, la timedatectl-komando devas fari komparon por determini la ĝustan horzonon. Se la RTC-tempo ne precize kongruas kun la loka horo, tiam ĝi ankaŭ ne kongruas kun la loka horzono.

Serĉante pliajn informojn, mi kontrolis la staton de systemd-timesync kaj trovis ĉi tion:

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

Rimarku la protokolmesaĝon, kiu diras, ke la sistema tempo ne estas agordita aŭ rekomencigita. La Timesync-servo fiksas la sisteman tempon surbaze de la tempomarko. Tempmarkoj estas konservitaj de la timesync-demono kaj estas kreitaj en ĉiu sukcesa sinkronigo.

La ordono timedatectl ne havas manieron preni la valoron de la aparatara horloĝo de la sistema horloĝo. Ĝi nur povas agordi la tempon kaj daton de la valoro enigita sur la komandlinio. Vi povas agordi la RTC al la sama valoro kiel la sistema tempo uzante la komandon 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

La opcio --localtime diras al la aparatara horloĝo montri lokan horon, ne UTC.

Kial vi entute bezonas RTC?

Ajna efektivigo de NTP starigos la sisteman horloĝon je ektempo. Kaj kial do RTC? Ĉi tio ne estas tute vera: tio okazos nur se vi havas retan konekton al la temposervilo. Tamen, multaj sistemoj ne ĉiam havas aliron al retkonekto, do aparatara horloĝo estas utila por Linukso por agordi la sisteman horon. Ĉi tio estas pli bona ol permane agordi la tempon, kvankam ĝi povas devii de reala tempo.

konkludo

Ĉi tiu artikolo reviziis kelkajn ilojn por manipuli daton, horon kaj horzonojn. La systemd-timesyncd-ilo provizas NTP-klienton, kiu povas sinkronigi la tempon sur la loka gastiganto kun NTP-servilo. Tamen, systemd-timesyncd ne provizas servilon, do se vi bezonas NTP-servilon en via reto, vi devas uzi ion alian, kiel Chrony, por funkcii kiel servilo.

Mi preferas havi ununuran efektivigon por iu ajn servo en mia reto, do mi uzas Chrony. Se vi ne bezonas lokan NTP-servilon, aŭ se vi ne ĝenas uzi Chrony kiel la servilon kaj systemd-timesyncd kiel la SNTP-kliento. Post ĉio, ne necesas uzi la kromajn funkciojn de Chrony kiel kliento se vi estas kontenta pri la funkcieco de systemd-timesyncd.

Alia noto: vi ne bezonas uzi la systemd-iloj por efektivigi NTP. Vi povas uzi pli malnovan version de ntpd, Chrony aŭ alian NTP-efektivigon. Post ĉio, systemd konsistas el granda nombro da servoj; multaj el ili estas laŭvolaj, do vi povas malŝalti ilin kaj uzi ion alian anstataŭe. Ĉi tio ne estas grandega monolita monstro. Vi eble ne ŝatas systemd aŭ partojn de ĝi, sed vi devus fari informitan decidon.

Mi ŝatas la efektivigon de NTP de systemd, sed mi preferas Chrony ĉar ĝi pli bone konvenas al miaj bezonoj. Ĝi estas Linukso, bebo -)

Pri la Rajtoj de Reklamado

VDSina proponas serviloj por ajna tasko, grandega elekto de operaciumoj por aŭtomata instalado, eblas instali ajnan OS de via propra ISO, komforta kontrola panelo propra disvolviĝo kaj ĉiutaga pago. Memoru, ke ni havas eternajn servilojn, kiuj certe estas sentempaj 😉

fonto: www.habr.com