De fleste holder styr på tiden. Vi står op til tiden for at gennemføre vores morgenritualer og tage på arbejde, holde frokostpause, overholde projektdeadlines, fejre fødselsdage og helligdage, gå ombord på et fly og så videre.
Desuden: nogle af os er besat af tid. Mit ur er drevet af solenergi og får nøjagtig tid fra National Institute of Standards and Technology () til Fort Collins, Colorado via langbølgeradio . Tidssignalerne er synkroniseret med atomuret, også placeret ved Fort Collins. Min Fitbit synkroniserer med min telefon, som synkroniserer med serveren , som til sidst synkroniseres med atomuret.
Enheder holder også styr på tiden
Der er mange grunde til, at vores enheder og computere har brug for nøjagtig tid. For eksempel i bankvirksomhed, aktiemarkeder og andre finansielle virksomheder skal transaktioner udføres i den rigtige rækkefølge, og nøjagtige tidssekvenser er afgørende for dette.
Vores telefoner, tablets, biler, GPS-systemer og computere kræver alle nøjagtige klokkeslæt og datoindstillinger. Jeg vil have uret på min computers skrivebord til at vise det korrekte klokkeslæt. Jeg vil gerne have, at påmindelser vises i min lokale kalender på det rigtige tidspunkt. Det korrekte tidspunkt sikrer også, at cron- og systemd-jobbene kører på det rigtige tidspunkt.
Dato og klokkeslæt er også vigtigt for logningen, så det er lidt nemmere at finde bestemte logfiler baseret på dato og klokkeslæt. For eksempel arbejdede jeg engang i DevOps (det hed det ikke dengang) og var ved at oprette et e-mail-system i staten North Carolina. Vi plejede at behandle over 20 millioner e-mails om dagen. Sporing af e-mail gennem en række servere, eller bestemmelse af den nøjagtige rækkefølge af hændelser ved hjælp af logfiler på geografisk spredte værter, kan være meget lettere, hvis de respektive computere er synkroniseret i tide.
Én gang - mange timer
Linux-værter skal tage højde for, at der er en systemtid og en RTC-tid. RTC (Real Time Clock) er et lidt mærkeligt og ikke særlig præcist navn for et hardware-ur.
Hardwareuret kører kontinuerligt, selv når computeren er slukket, ved hjælp af batteriet på systemets bundkort. RTC'ens hovedfunktion er at gemme tid, når en forbindelse til en tidsserver ikke er tilgængelig. I de dage, hvor det var umuligt at oprette forbindelse til en tidsserver over internettet, skulle hver computer have et nøjagtigt internt ur. Operativsystemer skulle have adgang til RTC ved opstart, og brugeren skulle manuelt indstille systemtiden ved hjælp af BIOS-hardwarekonfigurationsgrænsefladen for at sikre, at den var korrekt.
Hardwareure forstår ikke begrebet tidszoner; RTC gemmer kun tiden, ikke tidszonen eller offset fra UTC (Coordinated Universal Time, også kendt som GMT eller Greenwich Mean Time). Du kan installere RTC ved hjælp af et værktøj, som jeg vil dække senere i denne artikel.
Systemtiden er den tid, som operativsystemet viser på GUI-uret på dit skrivebord, i outputtet af datokommandoen, i logfilernes tidsstempler. Dette gælder også, når filer oprettes, ændres og åbnes.
På siden der er en fuldstændig beskrivelse af RTC'en og systemuret.
Hvad er der med NTP?
Computere over hele verden bruger NTP (Network Time Protocol) til at synkronisere deres tid med standard referenceure over internettet ved hjælp af et hierarki af NTP-servere. De vigtigste tidsservere er på lag 1, og de er direkte forbundet til forskellige nationale tidstjenester på lag 0 via satellit, radio eller endda modemer over telefonlinjer. Lag 0-tidstjenester kan være et atomur, en radiomodtager, der er indstillet til signaler, der transmitteres af atomure, eller en GPS-modtager, der bruger meget nøjagtige ursignaler, der transmitteres af GPS-satellitter.
Langt størstedelen af referenceserverne har flere tusinde offentlige NTP stratum 2-servere, der er åbne for offentligheden. Mange organisationer og brugere (inklusive mig selv) med mange værter, der har brug for en NTP-server, vælger at opsætte deres egne tidsservere, så kun én lokal vært får adgang til stratum 2 eller 3. De konfigurerer derefter de resterende noder på netværket til at bruge den lokale tidsserver. I tilfælde af mit hjemmenetværk er dette en lag 3-server.
Forskellige implementeringer af NTP
Den oprindelige implementering af NTP er ntpd. Den fik så selskab af to nyere, chronyd og systemd-timesyncd. Alle tre synkroniserer den lokale værtstid med en NTP-tidsserver. Systemd-timesyncd-tjenesten er ikke så pålidelig som chronyd, men den er god nok til de fleste formål. Hvis RTC'en er ude af synkronisering, kan den gradvist justere systemtiden for at synkronisere med NTP-serveren, når den lokale systemtid glider lidt. Systemd-timesync-tjenesten kan ikke bruges som en tidsserver.
er en implementering af NTP, der indeholder to programmer: chronyd-dæmonen og en kommandolinjegrænseflade kaldet chronyc. Chrony har nogle funktioner, der er uundværlige i mange tilfælde:
- Chrony kan synkronisere med en tidsserver meget hurtigere end den gamle ntpd-tjeneste. Dette er godt til bærbare eller stationære computere, der ikke fungerer hele tiden.
- Det kan kompensere for urudsving, såsom når værten går på vågeblus eller går i dvaletilstand, eller når uret skifter på grund af frekvenshop, hvilket sænker ure ved lav belastning.
- Det løser tidsproblemer relateret til ustabil netværksforbindelse eller overbelastning af netværket.
- Det regulerer netværksforsinkelser.
- Efter den indledende tidssynkronisering stopper Chrony aldrig uret. Dette giver stabile og ensartede tidsintervaller for mange systemtjenester og applikationer.
- Chrony kan fungere selv uden en netværksforbindelse. I dette tilfælde kan den lokale vært eller server opdateres manuelt.
- Chrony kan fungere som en NTP-server.
Endnu en gang er NTP en protokol, der kan implementeres på en Linux-vært ved hjælp af Chrony eller systemd-timesyncd.
NTP-, Chrony- og systemd-timesyncd RPM'erne er tilgængelige i Fedora-standardlagrene. systemd-udev RPM er en kernehændelsesmanager, der er installeret som standard på Fedora, men er valgfri.
Du kan installere alle tre og skifte mellem dem, men det vil skabe en ekstra hovedpine. Så det er bedre at lade være. Moderne udgivelser af Fedora, CentOS og RHEL er flyttet til Chrony som standardimplementering, og de har også systemd-timesyncd. Jeg synes, at Chrony fungerer godt, giver en bedre grænseflade end NTP-tjenesten, giver meget mere information og kontrol, hvilket systemadministratorer helt sikkert vil nyde.
Deaktivering af NTP-tjenester
NTP-tjenesten kører muligvis allerede på din vært. Hvis det er tilfældet, skal du deaktivere det, før du skifter til noget andet. Jeg havde chronyd kørende, så jeg brugte følgende kommandoer til at stoppe og deaktivere det. Kør de relevante kommandoer for enhver NTP-dæmon, du kører på din vært:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#Tjek, at tjenesten er stoppet og deaktiveret:
[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 ~]#Statuskontrol før lancering
Systemurets synkroniseringsstatus giver dig mulighed for at bestemme, om NTP-tjenesten kører. Da du ikke har startet NTP endnu, vil timesync-status kommandoen antyde dette:
[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.En direkte statusanmodning giver vigtige oplysninger. For eksempel udfører timedatectl-kommandoen uden argument eller indstillinger status-underkommandoen som standard:
[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 ~]#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 er begyndt at afvige lidt fra systemtiden. Dette er normalt for systemer, hvis ure ikke er blevet synkroniseret. Mængden af offset på værten afhænger af den tid, der er gået, siden systemet sidst blev synkroniseret.
Vi modtog også en advarsel om brug af lokal tid til RTC - dette gælder for tidszoneændringer og sommertid. Hvis computeren er slukket, når der skal foretages ændringer, ændres RTC ikke. Men for servere eller andre værter, der kører døgnet rundt, er dette slet ikke et problem. Derudover vil enhver tjeneste, der leverer NTP-tidssynkronisering, justere værtens tid under den indledende opstartsfase, så tiden vil være korrekt igen, efter at opstarten er fuldført.
Indstilling af tidszone
Normalt angiver du tidszonen under installationsproceduren, og du har ikke til opgave at ændre den senere. Der er dog tidspunkter, hvor du skal ændre tidszonen. Der er flere værktøjer, der kan hjælpe. Linux bruger tidszonefiler til at bestemme den lokale tidszone for en vært. Disse filer er i mappen /usr/share/zoneinfo. Som standard foreskriver systemet dette for min tidszone: /etc/localtime -> ../usr/share/zoneinfo/America/New_York. Men du behøver ikke kende sådanne finesser for at ændre tidszonen.
Det vigtigste er at kende det officielle tidszonenavn for din placering og den tilsvarende kommando. Lad os sige, at du vil ændre tidszonen til 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>Nu kan du indstille tidszonen. Jeg brugte datokommandoen til at tjekke for ændringer, 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 ~]#Nu kan du ændre din værts tidszone tilbage til lokal tid.
systemd-timesyncd
Systemd timesync-dæmonen giver en NTP-implementering, der er nem at administrere i systemd-konteksten. Det er installeret som standard på Fedora og Ubuntu. Det starter dog kun som standard på Ubuntu. Jeg er ikke sikker på andre distributioner. Du kan selv tjekke:
[root@testvm1 ~]# systemctl status systemd-timesyncdKonfigurerer systemd-timesyncd
Konfigurationsfilen for systemd-timesyncd er /etc/systemd/timesyncd.conf. Dette er en simpel fil med færre muligheder aktiveret end de gamle NTP- og chronyd-tjenester. Her er indholdet af denne fil (uden yderligere ændringer) på min 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=2048Den eneste sektion, den indeholder, udover kommentarer, er [Tid]. Alle andre linjer er kommenteret ud. Disse er standardværdierne og bør ikke ændres (medmindre du har en grund til det). Hvis du ikke har en NTP-tidsserver defineret i NTP=-linjen, er Fedora som standard en reserve-Fedora-tidsserver. Jeg plejer at tilføje min tidsserver:
NTP=myntpserverKører tidssynkronisering
Du kan starte og gøre systemd-timesyncd aktiv på denne 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 hardware-uret
Sådan ser situationen ud efter at have kørt 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 første omgang er forskellen mellem RTC og lokal tid (EDT) mindre end et sekund, og afvigelsen øges med yderligere et par sekunder i løbet af de næste par dage. Da der ikke er noget koncept for tidszoner i RTC, skal timedatectl-kommandoen udføre en sammenligning for at bestemme den korrekte tidszone. Hvis RTC-tiden ikke stemmer overens med den lokale tid, så passer den heller ikke til den lokale tidszone.
På udkig efter mere information, tjekkede jeg status for systemd-timesync og fandt dette:
[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]#Bemærk logmeddelelsen, der siger, at systemtiden ikke er blevet indstillet eller er blevet nulstillet. Timesync-tjenesten indstiller systemtiden baseret på tidsstemplet. Tidsstempler vedligeholdes af timesync-dæmonen og oprettes ved hver vellykket synkronisering.
Timedatectl-kommandoen kan ikke tage værdien af hardware-uret fra systemuret. Den kan kun indstille klokkeslæt og dato fra den værdi, der er indtastet på kommandolinjen. Du kan indstille RTC til samme værdi som systemtiden ved at bruge 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: yesIndstillingen --localtime fortæller hardwareuret at vise lokal tid, ikke UTC.
Hvorfor har du overhovedet brug for RTC?
Enhver implementering af NTP vil indstille systemuret ved opstartstidspunktet. Og hvorfor så RTC? Dette er ikke helt sandt: Dette vil kun ske, hvis du har en netværksforbindelse til tidsserveren. Mange systemer har dog ikke altid adgang til en netværksforbindelse, så et hardwareur er nyttigt for Linux at bruge til at indstille systemtiden. Dette er bedre end at indstille tiden manuelt, selvom den kan afvige fra realtid.
Konklusion
Denne artikel har gennemgået nogle værktøjer til at manipulere dato, klokkeslæt og tidszoner. Systemd-timesyncd-værktøjet giver en NTP-klient, der kan synkronisere tiden på den lokale vært med en NTP-server. Systemd-timesyncd leverer dog ikke en servertjeneste, så hvis du har brug for en NTP-server på dit netværk, skal du bruge noget andet, såsom Chrony, for at fungere som server.
Jeg foretrækker at have en enkelt implementering for enhver tjeneste på 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 trods alt ingen grund til at bruge de ekstra funktioner i Chrony som klient, hvis du er tilfreds med funktionaliteten af systemd-timesyncd.
En anden note: du er ikke forpligtet til at bruge systemd-værktøjerne til at implementere NTP. Du kan bruge en ældre version af ntpd, Chrony eller en anden NTP-implementering. Systemd består jo af en lang række tjenester; mange af dem er valgfrie, så du kan slå dem fra og bruge noget andet i stedet for. Dette er ikke et kæmpe monolitisk monster. Du kan måske ikke lide systemd eller dele af det, men du bør træffe en informeret beslutning.
Jeg kan godt lide systemd's implementering af NTP, men jeg foretrækker Chrony, fordi det passer bedre til mine behov. Det er Linux, skat -)
Om reklamernes rettigheder
VDSina tilbyder , et stort udvalg af operativsystemer til automatisk installation, er det muligt at installere et hvilket som helst operativsystem fra dit eget , komfortabel egen udvikling og daglig betaling. Husk at vi har evige servere, der bestemt er tidløse 😉
Kilde: www.habr.com