De fleste holder styr på tiden. Vi står opp i tide for å fullføre morgenritualene våre og dra på jobb, ta en lunsjpause, møte prosjekttidsfrister, feire bursdager og høytider, gå ombord på et fly og så videre.
Dessuten: noen av oss er besatt av tid. Klokken min drives av solenergi og får nøyaktig tid fra National Institute of Standards and Technology () til Fort Collins, Colorado via langbølgeradio . Tidssignalene er synkronisert med atomuret, også plassert ved Fort Collins. Min Fitbit synkroniserer med telefonen min som synkroniserer med serveren , som til slutt synkroniseres med atomuret.
Enheter holder også oversikt over tiden
Det er mange grunner til at enhetene og datamaskinene våre trenger nøyaktig tid. For eksempel, i bank, aksjemarkeder og andre finansielle virksomheter, må transaksjoner utføres i riktig rekkefølge, og nøyaktige tidssekvenser er avgjørende for dette.
Våre telefoner, nettbrett, biler, GPS-systemer og datamaskiner krever alle nøyaktige klokkeslett- og datoinnstillinger. Jeg vil at klokken på datamaskinens skrivebord skal vise riktig tid. Jeg vil at påminnelser skal vises i min lokale kalender til rett tid. Riktig tid sikrer også at cron- og systemd-jobbene kjører til riktig tid.
Dato og klokkeslett er også viktig for logging, så det er litt lettere å finne enkelte logger basert på dato og klokkeslett. For eksempel jobbet jeg en gang i DevOps (det het ikke det på den tiden) og satt opp et e-postsystem i delstaten North Carolina. Vi pleide å behandle over 20 millioner e-poster om dagen. Å spore e-post gjennom en rekke servere, eller bestemme den nøyaktige hendelsesrekkefølgen ved å bruke loggfiler på geografisk spredte verter, kan være mye enklere hvis de respektive datamaskinene er synkronisert i tid.
En gang - mange timer
Linux-verter må ta hensyn til at det er en systemtid og en RTC-tid. RTC (Real Time Clock) er et litt merkelig og lite nøyaktig navn på en maskinvareklokke.
Maskinvareklokken går kontinuerlig selv når datamaskinen er slått av, ved å bruke batteriet på hovedkortet. Hovedfunksjonen til RTC er å lagre tid når en tilkobling til en tidsserver ikke er tilgjengelig. I tiden da det var umulig å koble til en tidsserver over Internett, måtte hver datamaskin ha en nøyaktig intern klokke. Operativsystemer måtte få tilgang til RTC ved oppstart, og brukeren måtte stille inn systemtiden manuelt ved å bruke BIOS-maskinvarekonfigurasjonsgrensesnittet for å sikre at det var riktig.
Maskinvareklokker forstår ikke konseptet med tidssoner; RTC lagrer bare tiden, ikke tidssonen eller forskyvningen fra UTC (Coordinated Universal Time, også kjent som GMT eller Greenwich Mean Time). Du kan installere RTC ved å bruke et verktøy som jeg vil dekke senere i denne artikkelen.
Systemtiden er tiden som OS viser på GUI-klokken på skrivebordet ditt, i utdataene til datokommandoen, i tidsstemplene til loggene. Dette gjelder også når filer opprettes, endres og åpnes.
Side det er en fullstendig beskrivelse av RTC og systemklokken.
Hva er det med NTP?
Datamaskiner over hele verden bruker NTP (Network Time Protocol) for å synkronisere tiden med standard referanseklokker over Internett ved hjelp av et hierarki av NTP-servere. De viktigste tidsserverne er på lag 1 og de er direkte koblet til ulike nasjonale tidstjenester på lag 0 via satellitt, radio eller til og med modemer over telefonlinjer. Lag 0-tidstjenester kan være en atomklokke, en radiomottaker som er innstilt på signaler som sendes av atomklokker, eller en GPS-mottaker som bruker svært nøyaktige klokkesignaler som sendes av GPS-satellitter.
De aller fleste av referanseserverne har flere tusen offentlige NTP stratum 2-servere åpne for publikum. Mange organisasjoner og brukere (inkludert meg selv) med mange verter som trenger en NTP-server velger å sette opp sine egne tidsservere slik at kun én lokal vert får tilgang til stratum 2 eller 3. De konfigurerer så de gjenværende nodene på nettverket til å bruke den lokale tidsserver. Når det gjelder hjemmenettverket mitt, er dette en lag 3-server.
Ulike implementeringer av NTP
Den opprinnelige implementeringen av NTP er ntpd. Den fikk deretter selskap av to nyere, chronyd og systemd-timesyncd. Alle tre synkroniserer den lokale vertstiden med en NTP-tidsserver. Systemd-timesyncd-tjenesten er ikke like pålitelig som chronyd, men den er god nok til de fleste formål. Hvis RTC-en er ute av synkronisering, kan den gradvis justere systemtiden for å synkronisere med NTP-serveren når den lokale systemtiden avviker litt. Systemd-timesync-tjenesten kan ikke brukes som en tidsserver.
er en implementering av NTP som inneholder to programmer: chronyd daemon og et kommandolinjegrensesnitt kalt chronyc. Chrony har noen funksjoner som er uunnværlige i mange tilfeller:
- Chrony kan synkronisere med en tidsserver mye raskere enn den gamle ntpd-tjenesten. Dette er bra for bærbare eller stasjonære datamaskiner som ikke fungerer hele tiden.
- Den kan kompensere for klokkesvingninger, for eksempel når verten går i dvale eller går i dvalemodus, eller når klokken endres på grunn av frekvenshopping, noe som bremser klokkene ved lav belastning.
- Det løser tidsproblemer knyttet til ustabil nettverkstilkobling eller nettverksbelastning.
- Den regulerer nettverksforsinkelser.
- Etter den første tidssynkroniseringen stopper Chrony aldri klokken. Dette gir stabile og konsistente tidsluker for mange systemtjenester og applikasjoner.
- Chrony kan fungere selv uten nettverkstilkobling. I dette tilfellet kan den lokale verten eller serveren oppdateres manuelt.
- Chrony kan fungere som en NTP-server.
Nok en gang er NTP en protokoll som kan implementeres på en Linux-vert ved hjelp av Chrony eller systemd-timesyncd.
RPM-ene for NTP, Chrony og systemd-timesyncd er tilgjengelige i standard Fedora-lagre. Systemd-udev RPM er en kjernehendelsesbehandling som er installert som standard på Fedora, men er valgfri.
Du kan installere alle tre og bytte mellom dem, men dette vil skape ekstra hodepine. Så det er bedre å la være. Moderne utgivelser av Fedora, CentOS og RHEL har flyttet til Chrony som standardimplementering, og de har også systemd-timesyncd. Jeg synes Chrony fungerer bra, gir et bedre grensesnitt enn NTP-tjenesten, gir mye mer informasjon og kontroll, noe systemadministratorer helt sikkert vil ha glede av.
Deaktiverer NTP-tjenester
NTP-tjenesten kan allerede kjøre på verten din. I så fall må du deaktivere den før du bytter til noe annet. Jeg hadde chronyd i gang, så jeg brukte følgende kommandoer for å stoppe og deaktivere den. Kjør de riktige kommandoene for enhver NTP-demon du kjører på verten din:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#Sjekk at tjenesten er stoppet og deaktivert:
[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 ~]#Statussjekk før lansering
Systemklokkesynkroniseringsstatusen lar deg finne ut om NTP-tjenesten kjører. Siden du ikke har startet NTP ennå, vil timesync-status-kommandoen antyde dette:
[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.En direkte statusforespørsel gir viktig informasjon. For eksempel, timedatectl-kommandoen uten argument eller alternativer utfører 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 vil gi deg lokal tid for verten din, UTC-tid og RTC-tid. I dette tilfellet er systemtiden satt til tidssonen America / New_York (TZ), RTC er satt til tiden i den lokale tidssonen, og NTP-tjenesten er ikke aktiv. RTC-tiden har begynt å avvike litt fra systemtiden. Dette er normalt for systemer der klokkene ikke er synkronisert. Mengden offset på verten avhenger av tiden som har gått siden systemet sist ble synkronisert.
Vi fikk også en advarsel om bruk av lokal tid for RTC – dette gjelder tidssoneendringer og sommertid. Hvis datamaskinen er slått av når endringer må gjøres, vil ikke RTC endres. Men for servere eller andre verter som kjører døgnet rundt, er ikke dette noe problem i det hele tatt. I tillegg vil enhver tjeneste som gir NTP-tidssynkronisering justere vertens tid under den første oppstartsfasen, slik at tiden blir riktig igjen etter at oppstarten er fullført.
Stille inn tidssonen
Vanligvis spesifiserer du tidssonen under installasjonsprosedyren, og du har ikke oppgaven med å endre den senere. Det er imidlertid tider når du må endre tidssonen. Det er flere verktøy som kan hjelpe. Linux bruker tidssonefiler for å bestemme den lokale tidssonen til en vert. Disse filene er i katalogen /usr/share/zoneinfo. Som standard, for min tidssone, foreskriver systemet dette: /etc/localtime -> ../usr/share/zoneinfo/America/New_York. Men du trenger ikke å kunne slike finesser for å endre tidssonen.
Det viktigste er å vite det offisielle tidssonenavnet for posisjonen din og den tilhørende kommandoen. La oss si at du vil endre tidssonen 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>Nå kan du stille inn tidssonen. Jeg brukte datokommandoen for å se etter endringer, men du kan også bruke 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 ~]#Nå kan du endre vertens tidssone tilbake til lokal tid.
systemd-timesyncd
Systemd timesync daemon gir en NTP-implementering som er enkel å administrere i systemd-konteksten. Det er installert som standard på Fedora og Ubuntu. Den starter imidlertid bare som standard på Ubuntu. Jeg er ikke sikker på andre distribusjoner. Du kan sjekke selv:
[root@testvm1 ~]# systemctl status systemd-timesyncdKonfigurerer systemd-timesyncd
Konfigurasjonsfilen for systemd-timesyncd er /etc/systemd/timesyncd.conf. Dette er en enkel fil med færre alternativer aktivert enn de gamle NTP- og chronyd-tjenestene. Her er innholdet i denne filen (uten ytterligere modifikasjoner) 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 delen den inneholder, foruten kommentarer, er [Tid]. Alle andre linjer er kommentert ut. Dette er standardverdiene og bør ikke endres (med mindre du har en grunn til det). Hvis du ikke har en NTP-tidsserver definert i NTP=-linjen, er Fedora som standard en reserve-Fedora-tidsserver. Jeg legger vanligvis til min tidsserver:
NTP=myntpserverKjører tidssynkronisering
Du kan starte og gjøre systemd-timesyncd aktiv slik:
[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 ~]#Stille inn maskinvareklokken
Slik ser situasjonen ut etter å ha kjø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 utgangspunktet er forskjellen mellom RTC og lokal tid (EDT) mindre enn et sekund, og avviket øker med ytterligere et par sekunder i løpet av de neste dagene. Siden det ikke er noe konsept med tidssoner i RTC, må timedatectl-kommandoen utføre en sammenligning for å bestemme riktig tidssone. Hvis RTC-tiden ikke stemmer helt med den lokale tiden, stemmer den heller ikke med den lokale tidssonen.
På jakt etter mer informasjon sjekket jeg statusen til systemd-timesync og fant 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]#Legg merke til loggmeldingen som sier at systemtiden ikke er satt eller har blitt tilbakestilt. Timesync-tjenesten setter systemtiden basert på tidsstemplet. Tidsstempler vedlikeholdes av timesync-daemonen og opprettes ved hver vellykket synkronisering.
Timedatectl-kommandoen kan ikke ta verdien av maskinvareklokken fra systemklokken. Den kan bare angi klokkeslett og dato fra verdien angitt på kommandolinjen. Du kan sette RTC til samme verdi som systemtiden ved å bruke 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: yesAlternativet --localtime forteller maskinvareklokken å vise lokal tid, ikke UTC.
Hvorfor trenger du RTC i det hele tatt?
Enhver implementering av NTP vil stille inn systemklokken ved oppstartstid. Og hvorfor da RTC? Dette er ikke helt sant: dette vil bare skje hvis du har en nettverksforbindelse til tidsserveren. Mange systemer har imidlertid ikke alltid tilgang til en nettverkstilkobling, så en maskinvareklokke er nyttig for Linux å bruke for å stille inn systemtiden. Dette er bedre enn å stille inn tiden manuelt, selv om den kan avvike fra sanntid.
Konklusjon
Denne artikkelen har gjennomgått noen verktøy for å manipulere dato, klokkeslett og tidssoner. Systemd-timesyncd-verktøyet gir en NTP-klient som kan synkronisere tiden på den lokale verten med en NTP-server. Systemd-timesyncd tilbyr imidlertid ikke en servertjeneste, så hvis du trenger en NTP-server på nettverket ditt, må du bruke noe annet, for eksempel Chrony, for å fungere som en server.
Jeg foretrekker å ha en enkelt implementering for en hvilken som helst tjeneste på nettverket mitt, så jeg bruker Chrony. Hvis du ikke trenger en lokal NTP-server, eller hvis du ikke har noe imot å bruke Chrony som server og systemd-timesyncd som SNTP-klient. Tross alt er det ikke nødvendig å bruke tilleggsfunksjonene til Chrony som klient hvis du er fornøyd med funksjonaliteten til systemd-timesyncd.
En annen merknad: du er ikke pålagt å bruke systemverktøyene for å implementere NTP. Du kan bruke en eldre versjon av ntpd, Chrony eller en annen NTP-implementering. Systemd består tross alt av et stort antall tjenester; mange av dem er valgfrie, så du kan slå dem av og bruke noe annet i stedet. Dette er ikke et stort monolittisk monster. Du liker kanskje ikke systemd eller deler av det, men du bør ta en informert avgjørelse.
Jeg liker systemds implementering av NTP, men jeg foretrekker Chrony fordi det passer mine behov bedre. Det er Linux, baby -)
Om rettighetene til annonsering
VDSina tilbyr , et stort utvalg av operativsystemer for automatisk installasjon, er det mulig å installere hvilket som helst operativsystem fra ditt eget , behagelig egen utvikling og daglig betaling. Husk at vi har evige servere som definitivt er tidløse 😉
Kilde: www.habr.com