Die meeste mense hou tyd dop. Ons staan betyds op om ons oggendrituele te voltooi en werk toe te gaan, 'n middagete te neem, projeksperdatums na te kom, verjaarsdae en vakansiedae te vier, op 'n vliegtuig te klim, ensovoorts.
Boonop: sommige van ons is behep met tyd. My horlosie word aangedryf deur sonkrag en kry akkurate tyd van die Nasionale Instituut vir Standaarde en Tegnologie () na Fort Collins, Colorado via langgolfradio . Die tydseine word gesinchroniseer met die atoomhorlosie, wat ook by Fort Collins geleë is. My Fitbit sinkroniseer met my foon wat met die bediener sinkroniseer , wat uiteindelik met die atoomhorlosie sinchroniseer.
Toestelle hou ook tyd dop
Daar is baie redes waarom ons toestelle en rekenaars akkurate tyd benodig. Byvoorbeeld, in bankwese, aandelemarkte en ander finansiële besighede moet transaksies in die regte volgorde uitgevoer word, en akkurate tydreekse is van kritieke belang hiervoor.
Ons fone, tablette, motors, GPS-stelsels en rekenaars vereis almal akkurate tyd- en datuminstellings. Ek wil hê die horlosie op my rekenaar se lessenaar moet die regte tyd wys. Ek wil hê dat aanmanings op die regte tyd op my plaaslike kalender verskyn. Die korrekte tyd verseker ook dat die cron- en systemd-take op die regte tyd loop.
Datum en tyd is ook belangrik vir aanteken, so dit is 'n bietjie makliker om sekere logs op grond van datum en tyd te vind. Ek het byvoorbeeld eenkeer in DevOps gewerk (dit is toe nie so genoem nie) en was besig om 'n e-posstelsel in die staat Noord-Carolina op te stel. Ons het vroeër meer as 20 miljoen e-posse per dag verwerk. Om e-pos deur 'n reeks bedieners op te spoor, of om die presiese volgorde van gebeure te bepaal deur loglêers op geografies verspreide gashere te gebruik, kan baie makliker wees as die onderskeie rekenaars betyds gesinchroniseer word.
Een keer - baie ure
Linux-gashere moet in ag neem dat daar 'n stelseltyd en 'n RTC-tyd is. RTC (Real Time Clock) is 'n effens vreemde en nie baie akkurate naam vir 'n hardeware horlosie nie.
Die hardeware horlosie loop deurlopend selfs wanneer die rekenaar afgeskakel is, met behulp van die battery op die stelsel moederbord. Die hooffunksie van die RTC is om tyd te stoor wanneer 'n verbinding met 'n tydbediener nie beskikbaar is nie. In die dae toe dit onmoontlik was om aan 'n tydbediener oor die internet te koppel, moes elke rekenaar 'n akkurate interne klok hê. Bedryfstelsels moes toegang tot die RTC kry tydens selflaaityd en die gebruiker moes die stelseltyd met die hand instel deur die BIOS-hardeware-konfigurasie-koppelvlak te gebruik om seker te maak dit is korrek.
Hardewarehorlosies verstaan nie die konsep van tydsones nie; RTC stoor net die tyd, nie die tydsone of afwyking vanaf UTC (Coordinated Universal Time, ook bekend as GMT of Greenwich Mean Time nie). U kan RTC installeer met behulp van 'n instrument wat ek later in hierdie artikel sal dek.
Die stelseltyd is die tyd wat die bedryfstelsel op die GUI-klok op jou lessenaar vertoon, in die uitvoer van die datumopdrag, in die tydstempels van die logs. Dit geld ook wanneer lêers geskep, gewysig en oopgemaak word.
Op bladsy daar is 'n volledige beskrywing van die RTC en die stelselklok.
Wat is met NTP?
Rekenaars regoor die wêreld gebruik NTP (Network Time Protocol) om hul tyd met standaard verwysinghorlosies oor die internet te sinchroniseer deur 'n hiërargie van NTP-bedieners te gebruik. Die hooftydbedieners is by laag 1 en hulle is direk gekoppel aan verskeie nasionale tyddienste by laag 0 via satelliet, radio of selfs modems oor telefoonlyne. Laag 0-tyddienste kan 'n atoomhorlosie wees, 'n radio-ontvanger wat ingestel is op seine wat deur atoomhorlosies uitgesaai word, of 'n GPS-ontvanger wat hoogs akkurate klokseine gebruik wat deur GPS-satelliete versend word.
Die oorgrote meerderheid van die verwysingsbedieners het etlike duisende openbare NTP-stratum 2-bedieners wat oop is vir die publiek. Baie organisasies en gebruikers (myself ingesluit) met baie gashere wat 'n NTP-bediener benodig, kies om hul eie tydbedieners op te stel sodat slegs een plaaslike gasheer toegang tot stratum 2 of 3 kry. Hulle konfigureer dan die oorblywende nodusse op die netwerk om die plaaslike te gebruik tydbediener. In die geval van my tuisnetwerk is dit 'n laag 3-bediener.
Verskeie implementering van NTP
Die oorspronklike implementering van NTP is ntpd. Dit is toe verbind deur twee nuwers, chronyd en systemd-timesyncd. Al drie sinchroniseer die plaaslike gasheertyd met 'n NTP-tydbediener. Die systemd-timesyncd-diens is nie so betroubaar soos chronyd nie, maar dit is goed genoeg vir die meeste doeleindes. As die RTC nie gesinchroniseer is nie, kan dit die stelseltyd geleidelik aanpas om met die NTP-bediener te sinchroniseer wanneer die plaaslike stelseltyd effens afwyk. Die systemd-timesync-diens kan nie as 'n tydbediener gebruik word nie.
is 'n implementering van NTP wat twee programme bevat: die chronyd-demon en 'n opdragreël-koppelvlak genaamd chronyc. Chrony het 'n paar kenmerke wat in baie gevalle onontbeerlik is:
- Chrony kan baie vinniger met 'n tydbediener sinchroniseer as die ou ntpd-diens. Dit is goed vir skootrekenaars of rekenaars wat nie heeltyd werk nie.
- Dit kan kompenseer vir klokskommelings, soos wanneer die gasheer gaan slaap of in slaapmodus gaan, of wanneer die horlosie verander as gevolg van frekwensiesprong, wat horlosies by lae vragte vertraag.
- Dit los tydprobleme op wat verband hou met onstabiele netwerkverbinding of netwerkopeenhoping.
- Dit reguleer netwerkvertragings.
- Na die aanvanklike tydsinkronisering, stop Chrony nooit die klok nie. Dit bied stabiele en konsekwente tydgleuwe vir baie stelseldienste en toepassings.
- Chrony kan selfs sonder 'n netwerkverbinding werk. In hierdie geval kan die plaaslike gasheer of bediener met die hand opgedateer word.
- Chrony kan as 'n NTP-bediener optree.
Weereens, NTP is 'n protokol wat op 'n Linux-gasheer geïmplementeer kan word met Chrony of systemd-timesyncd.
Die NTP-, Chrony- en systemd-timesyncd RPM's is beskikbaar in die standaard Fedora-bewaarplekke. Die systemd-udev RPM is 'n kerngebeurtenisbestuurder wat by verstek op Fedora geïnstalleer is, maar is opsioneel.
Jy kan al drie installeer en tussen hulle wissel, maar dit sal 'n ekstra hoofpyn skep. Dit is dus beter om nie. Moderne vrystellings van Fedora, CentOS en RHEL het na Chrony geskuif as die verstekimplementering, en hulle het ook systemd-timesyncd. Ek vind Chrony werk goed, bied 'n beter koppelvlak as die NTP-diens, verskaf baie meer inligting en beheer, wat stelseladministrateurs beslis sal geniet.
Deaktiveer NTP-dienste
Die NTP-diens loop dalk reeds op jou gasheer. Indien wel, moet jy dit deaktiveer voordat jy na iets anders oorskakel. Ek het chronyd aan die gang gehad, so ek het die volgende opdragte gebruik om dit te stop en deaktiveer. Voer die toepaslike opdragte uit vir enige NTP-daemon wat jy op jou gasheer gebruik:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#Kontroleer dat die diens gestop en gedeaktiveer is:
[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 ~]#Statuskontrole voor bekendstelling
Die stelselkloksinchronisasiestatus laat jou toe om te bepaal of die NTP-diens loop. Aangesien jy nog nie NTP begin het nie, sal die timesync-status-opdrag hierna verwys:
[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.'n Direkte statusversoek verskaf belangrike inligting. Byvoorbeeld, die timedatectl-opdrag sonder argument of opsies voer die status-subopdrag by verstek uit:
[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 ~]#Dit sal jou die plaaslike tyd vir jou gasheer, UTC-tyd en RTC-tyd gee. In hierdie geval is die stelseltyd ingestel op die Amerika / New_York (TZ) tydsone, die RTC is ingestel op die tyd in die plaaslike tydsone, en die NTP-diens is nie aktief nie. Die RTC-tyd het effens van die stelseltyd begin afwyk. Dit is normaal vir stelsels waarvan die horlosies nie gesinchroniseer is nie. Die hoeveelheid verrekening op die gasheer hang af van die tyd wat verloop het sedert die stelsel laas gesinchroniseer is.
Ons het ook 'n waarskuwing ontvang oor die gebruik van plaaslike tyd vir RTC - dit is van toepassing op tydsoneveranderings en DST-instellings. As die rekenaar afgeskakel is wanneer veranderinge aangebring moet word, sal die RTC nie verander nie. Maar vir bedieners of ander gashere wat die hele klok loop, is dit glad nie 'n probleem nie. Daarbenewens sal enige diens wat NTP-tydsinchronisasie verskaf, die gasheer se tyd tydens die aanvanklike opstartfase aanpas, sodat die tyd weer korrek sal wees nadat opstart voltooi is.
Stel die tydsone in
Gewoonlik spesifiseer jy die tydsone tydens die installasie prosedure en jy het nie die taak om dit later te verander nie. Daar is egter tye wanneer jy die tydsone moet verander. Daar is verskeie hulpmiddels wat kan help. Linux gebruik tydsone-lêers om die plaaslike tydsone van 'n gasheer te bepaal. Hierdie lêers is in die gids /usr/share/zoneinfo. By verstek, vir my tydsone, skryf die stelsel dit voor: /etc/localtime -> ../usr/share/zoneinfo/America/New_York. Maar jy hoef nie sulke subtiliteite te ken om die tydsone te verander nie.
Die belangrikste ding is om die amptelike tydsonenaam vir jou ligging en die ooreenstemmende opdrag te ken. Kom ons sê jy wil die tydsone na Los Angeles verander:
[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>Nou kan jy die tydsone stel. Ek het die datumopdrag gebruik om te kyk vir veranderinge, maar jy kan ook timedatectl gebruik:
[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 ~]#Nou kan jy jou gasheer se tydsone terug na plaaslike tyd verander.
systemd-timesyncd
Die systemd timesync daemon bied 'n NTP implementering wat maklik is om te bestuur in die systemd konteks. Dit is standaard op Fedora en Ubuntu geïnstalleer. Dit begin egter net by verstek op Ubuntu. Ek is nie seker oor ander verspreidings nie. Jy kan self kyk:
[root@testvm1 ~]# systemctl status systemd-timesyncdStel tans systemd-timesyncd op
Die konfigurasielêer vir systemd-timesyncd is /etc/systemd/timesyncd.conf. Dit is 'n eenvoudige lêer met minder opsies geaktiveer as die ou NTP- en chronyd-dienste. Hier is die inhoud van hierdie lêer (sonder verdere wysigings) op my 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=2048Die enigste afdeling wat dit bevat, behalwe kommentaar, is [Tyd]. Alle ander reëls word uitgeteken. Dit is die verstekwaardes en moet nie verander word nie (tensy jy 'n rede daarvoor het). As jy nie 'n NTP-tydbediener het wat in die NTP=-lyn gedefinieer is nie, is Fedora verstek na 'n terugval-Fedora-tydbediener. Ek voeg gewoonlik my tydbediener by:
NTP=myntpserverLoop tydsinkronisering
Jy kan systemd-timesyncd so begin en aktief maak:
[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 ~]#Stel die hardeware horlosie
Hier is hoe die situasie lyk nadat timesyncd uitgevoer is:
[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 Aanvanklik is die verskil tussen RTC en plaaslike tyd (EDT) minder as 'n sekonde, en die verskil neem oor die volgende paar dae met nog 'n paar sekondes toe. Aangesien daar geen konsep van tydsones in RTC is nie, moet die timedatectl-opdrag 'n vergelyking uitvoer om die korrekte tydsone te bepaal. As die RTC-tyd nie presies ooreenstem met die plaaslike tyd nie, pas dit ook nie by die plaaslike tydsone nie.
Op soek na meer inligting, het ek die status van systemd-timesync nagegaan en dit gevind:
[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]#Let op die logboodskap wat sê dat die stelseltyd nie ingestel is nie of teruggestel is. Die Timesync-diens stel die stelseltyd op grond van die tydstempel. Tydstempels word onderhou deur die tydsinkronisering-daemon en word op elke suksesvolle sinkronisering geskep.
Die timedatectl-opdrag het geen manier om die waarde van die hardewareklok van die stelselklok af te neem nie. Dit kan slegs die tyd en datum stel vanaf die waarde wat op die opdragreël ingevoer is. U kan die RTC op dieselfde waarde as die stelseltyd stel deur die hwclock-opdrag te gebruik:
[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: yesDie --localtime opsie vertel die hardeware horlosie om plaaslike tyd te wys, nie UTC nie.
Hoekom het jy RTC enigsins nodig?
Enige implementering van NTP sal die stelselklok by opstarttyd stel. En hoekom dan RTC? Dit is nie heeltemal waar nie: dit sal slegs gebeur as jy 'n netwerkverbinding met die tydbediener het. Baie stelsels het egter nie altyd toegang tot 'n netwerkverbinding nie, so 'n hardewareklok is nuttig vir Linux om te gebruik om die stelseltyd in te stel. Dit is beter as om die tyd handmatig in te stel, al kan dit van intydse tyd afwyk.
Gevolgtrekking
Hierdie artikel het 'n paar nutsmiddels hersien om datum, tyd en tydsones te manipuleer. Die systemd-timesyncd-nutsding verskaf 'n NTP-kliënt wat die tyd op die plaaslike gasheer met 'n NTP-bediener kan sinchroniseer. Systemd-timesyncd verskaf egter nie 'n bedienerdiens nie, so as jy 'n NTP-bediener op jou netwerk benodig, moet jy iets anders gebruik, soos Chrony, om as 'n bediener op te tree.
Ek verkies om 'n enkele implementering vir enige diens op my netwerk te hê, so ek gebruik Chrony. As jy nie 'n plaaslike NTP-bediener nodig het nie, of as jy nie omgee om Chrony as die bediener en systemd-timesyncd as die SNTP-kliënt te gebruik nie. Dit is immers nie nodig om die bykomende kenmerke van Chrony as 'n kliënt te gebruik as u tevrede is met die funksionaliteit van systemd-timesyncd nie.
Nog 'n opmerking: jy hoef nie die systemd-nutsmiddels te gebruik om NTP te implementeer nie. U kan 'n ouer weergawe van ntpd, Chrony of 'n ander NTP-implementering gebruik. Systemd bestaan immers uit 'n groot aantal dienste; baie van hulle is opsioneel, so jy kan hulle afskakel en eerder iets anders gebruik. Dit is nie 'n groot monolitiese monster nie. Jy mag dalk nie van systemd of dele daarvan hou nie, maar jy moet 'n ingeligte besluit neem.
Ek hou van systemd se implementering van NTP, maar ek verkies Chrony omdat dit beter by my behoeftes pas. Dit is Linux, skat -)
Oor die regte van reklame
VDSina bied , 'n groot verskeidenheid bedryfstelsels vir outomatiese installasie, is dit moontlik om enige bedryfstelsel vanaf jou eie te installeer , gemaklik eie ontwikkeling en daaglikse betaling. Onthou dat ons ewige bedieners het wat beslis tydloos is 😉
Bron: will.com