De fleste mennesker holder øje med tiden. Vi står op til tiden for at udføre vores morgenritualer og tage af sted til arbejde, tage en frokostpause, overholde projekts frister, fejre fødselsdage og helligdage, tage et fly, og så videre.
Desuden er nogle af os besatte af tid. Mine ure drives af solenergi og får præcist tidsdata fra National Institute of Standards and Technology () i Fort Collins, Colorado, via en langbølge radiostation . Tidsignalene synkroniseres med atomure, som også er placeret i Fort Collins. Mit Fitbit synkroniseres med min telefon, som synkroniseres med serveren , som til sidst synkroniseres med atomurene.
Enheder holder også øje med tiden
Der er mange grunde til, at vores enheder og computere har brug for præcis tid. For eksempel i banksektoren, på aktiemarkederne og i andre finansielle virksomheder skal transaktioner udføres i korrekt rækkefølge, og præcise tidssekvenser er kritisk vigtige.
Vore telefoner, tablets, biler, GPS-systemer og computere kræver korrekt indstilling af tidspunkt og dato. Jeg vil have, at klokken på min computers skrivebord viser den rigtige tid. Jeg vil have, at påmindelser i min lokale kalender dukker op på det rette tidspunkt. Den rigtige tid sikrer også, at cron- og systemd-opgaver kører til tiden.
Dato og tid er også vigtige for logning, så det er lettere at finde specifikke logs ved at referere til dato og tid. For eksempel arbejdede jeg en gang inden for DevOps (dengang kaldte vi det ikke sådan) og satte et e-mail-system op i North Carolina. Tidligere håndterede vi over 20 millioner e-mails om dagen. At spore e-mails gennem en række servere eller bestemme den præcise rækkefølge af begivenheder ved hjælp af logfiler på geografisk adskilte værter kan være meget lettere, hvis de relevante computere er synkroniseret tidsmæssigt.
Tid er én ting - der er mange ure
Linux-værter skal være opmærksomme på, at der er systemtid og RTC-tid. RTC (Real Time Clock - realtid ur) er et lidt underligt og ikke særlig præcist navn for hardware-uret.
Hardware clocken arbejder kontinuerligt, selv når computeren er slukket, ved hjælp af et batteri på systemets bundkort. Den primære funktion af RTC er at opbevare tiden, når forbindelsen til tidsserveren ikke er tilgængelig. I de dage, hvor det ikke var muligt at oprette forbindelse til en tidsserver via internettet, skulle hver computer have præcise interne ure. Operativsystemerne skulle kontakte RTC under opstarten, og brugeren skulle manuelt indstille systemtiden ved hjælp af den hardwarekonfigurationsgrænseflade, kaldet BIOS, for at sikre, at den var korrekt.
Hardware urene forstår ikke konceptet med tidszoner; RTC gemmer kun tiden, ikke tidszonen eller forskydningen fra UTC (Koordineret universeltid, som også er kendt som GMT eller Greenwich Mean Time). Du kan indstille RTC med et værktøj, som jeg vil fortælle om senere i denne artikel.
Systemtid er den tid, som OS viser på GUI-uret på dit skrivebord, i output fra kommandoen date, i tidsstempler fra logfiler. Det henviser også til tiden for oprettelse, ændring og åbning af filer.
På siden der er en fuld beskrivelse af RTC og systemure.
Hvad med NTP?
Computere verden over bruger NTP (Network Time Protocol) til at synkronisere deres tid med standard referencetimer over internettet ved hjælp af en hierarki af NTP-servere. De primære tidsservere er på niveau 1 og er direkte forbundet til forskellige nationale tidstjenester på niveau 0 via satellit, radio eller endda modemer over telefonlinjer. Tidstjenester på niveau 0 kan være atomure, en radiomodtager indstillet til signaler sendt af atomure, eller en GPS-modtager, der bruger højpræcise timersignaler sendt af GPS-satellitter.
På stort set alle standardservere er der åbnet for flere tusinde offentlige NTP-servere stratum 2, som er tilgængelige for alle. Mange organisationer og brugere (inklusive mig selv), der har mange værter, der har brug for en NTP-server, foretrækker at installere deres egne tidsservere, så kun én lokal vært henvender sig til stratum 2 eller 3. Derefter konfigurerer de de resterende noder i netværket til at bruge den lokale tidsserver. I mit hjemmenetværk er det en server på niveau 3.
Forskellige implementeringer af NTP
Den oprindelige implementering af NTP er ntpd. Senere er to nyere programmer, chronyd og systemd-timesyncd, blevet tilføjet. Alle tre synkroniserer tiden på den lokale vært med en NTP-tidsserver. Tjenesten systemd-timesyncd er ikke lige så pålidelig som chronyd, men er tilstrækkelig til de fleste formål. Hvis RTC ikke er synkroniseret, kan den gradvist justere systemtiden for at synkronisere med NTP-serveren, når den lokale systemtid er let forskudt. systemd-timesync-tjenesten kan ikke bruges som en tidsserver.
— er en implementering af NTP, der indeholder to programmer: dæmonen chronyd og et kommandolinjegrænseflade kaldet chronyc. Chrony har nogle funktioner, der i mange tilfælde er uundgåelige:
- Chrony kan synkronisere med en tidsserver meget hurtigere end den gamle tjeneste ntpd. Dette er godt for bærbare computere eller desktops, der ikke kører konstant.
- Den kan kompensere for uregelmæssigheder i taktfrekevenser, for eksempel når værten skifter til dvaletilstand eller går i dvale, eller når taktfrekevensen ændres på grund af pludselige ændringer i frekevensen, der sænker taktfrekevenserne ved lave belastninger.
- Den løser problemer med tid, der er forbundet med ustabile netværksforbindelser eller netværksbelastning.
- Den justerer forsinkelser i netværket.
- Efter den indledende tidsynkronisering stopper Chrony aldrig uret. Dette sikrer stabile og ensartede tidsintervaller for mange systemtjenester og applikationer.
- Chrony kan fungere selv uden netværksforbindelse. I så fald kan den lokale vært eller server opdateres manuelt.
- Chrony kan fungere som en NTP-server.
Endnu en gang: NTP er en protokol, der kan implementeres på en Linux-vært ved hjælp af Chrony eller systemd-timesyncd.
RPM-pakkerne NTP, Chrony og systemd-timesyncd er tilgængelige i standardrepositoryerne for Fedora. RPM systemd-udev er en kernelhændelseshåndterer, som er forudinstalleret i Fedora, men som ikke er obligatorisk at bruge.
Du kan installere alle tre og skifte imellem dem, men det vil skabe unødvendig hovedpine. Så det er bedre at undgå det. Moderne versioner af Fedora, CentOS og RHEL har skiftet til Chrony som standardimplementering, og de har desuden systemd-timesyncd. Jeg mener, at Chrony fungerer godt, har et bedre interface end NTP-tjenesten, giver meget mere information og øger kontrollen, hvilket helt sikkert vil glæde systemadministratorer.
Deaktivering af NTP-tjenester
Det kan være, at der allerede kører en NTP-tjeneste på din vært. Hvis det er tilfældet, skal du deaktivere den, før du skifter til noget andet. Jeg havde chronyd kørende, så jeg brugte følgende kommandoer til at stoppe og deaktivere den. Kør de relevante kommandoer for enhver NTP-daemon, du bruger på din vært:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Fjernet /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#Kontrollér, at tjenesten er stoppet og deaktiveret:
[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - NTP klient/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 ~]#Kontrol af status før opstart
Status for systemets tids-synkronisering gør det muligt at bestemme, om NTP-tjenesten kører. Da du endnu ikke har startet NTP, vil kommandoen timesync-status antyde dette:
[root@testvm1 ~]# timedatectl timesync-status
Kunne ikke forespørge server: Kunne ikke aktivere ekstern peer.En direkte forespørgsel om status giver vigtige informationer. For eksempel udfører kommandoen timedatectl uden argumenter eller parametre som standard underkommandoen status:
[root@testvm1 ~]# timedatectl status
Lokal tid: Fre 2020-05-15 08:43:10 EDT
Universel tid: Fre 2020-05-15 12:43:10 UTC
RTC tid: Fre 2020-05-15 08:43:08
Tidszone: America/New_York (EDT, -0400)
Systemuret synkroniseret: nej
NTP tjeneste: inaktiv
RTC i lokal TZ: ja
Advarsel: Systemet er konfigureret til at læse RTC-tid i den lokale tidszone.
Denne tilstand kan ikke understøttes fuldt ud. Det vil skabe forskellige problemer
med tidszoneændringer og justeringer for sommertid. RTC
tiden opdateres aldrig, den er afhængig af eksterne faciliteter for at opretholde den.
Hvis det er muligt, skal du bruge RTC i UTC ved at kalde
'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#Dette giver dig den lokale tid for din vært, UTC tid og RTC tid. I dette tilfælde er systemtiden indstillet til tidszonen America/New_York (TZ), RTC er indstillet til tiden i den lokale tidszone, og NTP-tjenesten er ikke aktiv. RTC tiden begynder at afvige en smule fra systemtiden. Dette er normalt for systemer, hvis ure ikke er blevet synkroniseret. Størrelsen på afvigelsen på værten afhænger af den tid, der er gået siden den sidste systemsynkronisering.
Vi modtog også en advarsel om brugen af lokal tid til RTC — det vedrører ændringer i tidszoner og indstillinger for sommertid. Hvis computeren er slukket i det øjeblik, hvor ændringer skal foretages, vil RTC tiden ikke ændre sig. Men for servere eller andre værter, der kører døgnet rundt, er dette slet ikke et problem. Derudover vil enhver tjeneste, der sikrer NTP tidssynkronisering, justere værtsens tid allerede i opstartens tidlige faser, så efter opstart vil tiden igen være korrekt.
Indstilling af tidszone
Normalt angiver du tidszonen under installationsproceduren, og du har ikke behov for at ændre den senere. Men der er tilfælde, hvor det er nødvendigt at ændre tidszonen. Der er flere værktøjer, som kan hjælpe. For at bestemme den lokale tidszone bruger Linux værten tidszonefiler. Disse filer findes i mappen /usr/share/zoneinfo. Som standard angiver mit system dette for min tidszone: /etc/ localtime -> ../usr/share/zoneinfo/America/New_York. Men du behøver ikke at kende disse detaljer for at ændre tidszonen.
Det vigtigste er at vide det officielle navn på tidszonen for din placering og den tilsvarende kommando. Lad os sige, at du vil ændre tidszonen til 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/HelsinkiNu kan du indstille tidszonen. Jeg brugte kommandoen date til at kontrollere ændringerne, men du kan også bruge 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 ~]#Du kan nu ændre tidszonen på din vært til lokal tid igen.
systemd-timesyncd
Systemd timesync demon leverer en NTP-implementering, der er nem at administrere i konteksten af systemd. Den er installeret som standard i Fedora og Ubuntu. Dog kører den som standard kun i Ubuntu. Jeg er ikke sikker med hensyn til andre distributioner. Du kan tjekke det selv:
[root@testvm1 ~]# systemctl status systemd-timesyncdKonfigurering af systemd-timesyncd
Konfigurationsfilen for systemd-timesyncd er /etc/systemd/timesyncd.conf. Det er en simpel fil med færre inkluderede opsætninger end i de ældre NTP og chronyd tjenester. Her er indholdet af denne fil (uden ændringer) på min virtuelle maskine med 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=2048Den eneste sektion, den indeholder, bortset fra kommentarer, er [Time]. Alle andre linjer er kommentarer. Dette er standardindstillinger, og de skal ikke ændres (medmindre du har specifikke grunde til det). Hvis du ikke har en NTP-tidsserver angivet i linjen NTP =, bruges der som standard en backup-tidsserver fra Fedora. Jeg plejer at tilføje min egen tidsserver:
NTP=myntpserverStart timesync
Du kan starte og aktivere systemd-timesyncd på følgende måde:
[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 ~]#Indstilling af hardwareklokker
Her er situationen efter opstart af 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 I begyndelsen er forskellen mellem RTC og lokal tid (EDT) ikke mere end et sekund, og afvigelsen stiger med et par sekunder over de næste par dage. Da RTC ikke har nogen forståelse af tidszoner, skal timedatectl-kommandoen udføre en sammenligning for at bestemme den nødvendige tidszone. Hvis RTC-tiden ikke nøjagtigt svarer til lokal tid, betyder det, at den heller ikke svarer til den lokale tidszone.
I søgen efter ekstra information tjekkede jeg status for systemd-timesync, og her er hvad jeg fandt:
[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Netværkstids-synkronisering
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]#Bemærk meddelelsen i loggen, der siger, at systemtiden ikke er indstillet eller er blevet tilbageført. Tidsynkroniseringstjenesten indstiller systemtiden baseret på tidsstemplet. Tidsstemplet opretholdes af timesync-dæmonen og oprettes ved hver succesfuld synkronisering.
Timedatectl-kommandoen har ikke mulighed for at tage værdien af hardwareklokken fra systemtiden. Den kan kun indstille tid og dato ud fra den værdi, der indtastes i kommandolinjen. Du kan indstille RTC til samme værdi som systemtiden ved hjælp af hwclock-kommandoen:
[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: yesMuligheden —localtime angiver, at hardwareklokken viser lokal tid og ikke UTC.
Hvorfor har du overhovedet RTC?
Enhver implementering af NTP vil indstille systemklokken ved opstart. Hvad er der så brug for RTC til? Det er ikke helt korrekt: dette vil kun ske, hvis du har en netværksforbindelse til en tidsserver. Mange systemer har dog ikke konstant adgang til en netværksforbindelse, så hardwareklokker er nyttige, så Linux kan indstille systemtiden baseret på dem. Det er bedre end at indstille tiden manuelt, selvom den kan afvige fra den reelle tid.
Konklusion
Denne artikel ser på nogle værktøjer til at håndtere dato, tid og tidszoner. Værktøjet systemd-timesyncd leverer en NTP-klient, der kan synkronisere tiden på den lokale vært med en NTP-server. Dog tilbyder systemd-timesyncd ikke en serverfunktion, så hvis du har brug for en NTP-server i dit netværk, skal du bruge noget andet - for eksempel Chrony, til at fungere som server.
Jeg foretrækker at have én enkelt implementering for enhver service i mit netværk, så jeg bruger Chrony. Hvis du ikke har brug for en lokal NTP-server, eller hvis du ikke har noget imod at bruge Chrony som server og systemd-timesyncd som SNTP-klient. Der er jo ingen grund til at bruge de ekstra funktioner i Chrony som klient, hvis du er tilfreds med funktionaliteten i systemd-timesyncd.
Endnu en bemærkning: du er ikke forpligtet til at bruge systemd værktøjer til implementering af NTP. Du kan bruge den gamle version ntpd, Chrony eller en anden NTP-implementering. Systemd består af mange tjenester; mange af dem er valgfrie, så de kan deaktiveres og erstattes med noget andet. Det er ikke en stor monolitisk monster. Man behøver ikke elske systemd eller dets dele, men man bør træffe en velovervejet beslutning.
Jeg kan godt lide NTP-implementeringen i systemd, men jeg foretrækker Chrony, fordi den bedre opfylder mine behov. Det er Linux, baby -)
Annoncering
VDSina tilbyder , et stort udvalg af operativsystemer til automatisk installation, der er mulighed for at installere ethvert OS fra egen , praktisk eget udvikling og daglig betaling. Lad os minde om, at vi har evige servere, som bestemt ikke er påvirket af tidens gang 😉
Kilde: habr.com
