108.1 Lecke 2
Tanúsítvány: |
LPIC-1 (102) |
---|---|
Verzió: |
5.0 |
Témakör: |
108 Alapvető rendszerszolgáltatások |
Fejezet: |
108.1 Rendszeridő karbantartása |
Lecke: |
2/2 |
Bevezetés
Míg a személyi számítógépek önmagukban is képesek viszonylag pontos időt tartani, a termelési számítógépek és a hálózati környezetek megkövetelik, hogy az idő nagyon pontos legyen. A legpontosabb időt referenciaórák mérik, amelyek jellemzően atomórák. A modern világ kidolgozott egy olyan rendszert, amelyben minden internetre csatlakoztatott számítógépes rendszer szinkronizálható ezekkel a referenciaórákkal az úgynevezett Network Time Protocol (NTP) segítségével. Az NTP-vel rendelkező számítógépes rendszer képes lesz szinkronizálni a rendszerórákat a referenciaórák által megadott időhöz. Ha a rendszeridő és a szervereken mért idő eltér egymástól, akkor a számítógép fokozatosan gyorsítja vagy lassítja a belső rendszeridejét, amíg a rendszeridő meg nem egyezik a hálózati idővel.
Az NTP hierarchikus struktúrát használ az idő terjesztésére. A referenciaórák a hierarchia tetején lévő szerverekhez kapcsolódnak. Ezek a szerverek Stratum 1 gépek, és általában nem nyilvánosak. Az 1. rétegbeli gépek azonban elérhetők a Stratum 2 gépek számára, amelyek elérhetők a Stratum 3 gépek számára, és így tovább. A Stratum 2 szerverek a nyilvánosság számára hozzáférhetők, akárcsak a hierarchiában lejjebb elhelyezkedő gépek. Ha egy nagy hálózat NTP-jét állítjuk be, jó gyakorlat, ha kisszámú számítógép csatlakozik a Stratum 2+ szerverekhez, és ezek a gépek biztosítják az NTP-t az összes többi gép számára. Ily módon a Stratum 2-es gépekkel szemben támasztott követelmények minimálisra csökkenthetők.
Van néhány fontos kifejezés, amely az NTP megvitatásakor felmerül. Ezek közül néhányat azokban a parancsokban használunk, amelyekkel nyomon követhetjük az NTP állapotát a gépeinken:
- Offset
-
Ez a rendszeridő és az NTP-idő közötti abszolút különbségre utal. Ha például a rendszeróra 12:00:02-t mutat, az NTP-idő pedig 11:59:58-at, akkor a két óra közötti eltolódás (offset) négy másodperc.
- Step
-
Ha az NTP-szolgáltató és a fogyasztó közötti időeltolódás nagyobb, mint 128 ms, akkor az NTP a rendszeridő lassítása vagy gyorsítása helyett egyetlen jelentős változást hajt végre a rendszeridőben. Ezt nevezzük stepping-nek.
- Slew
-
A slewing a rendszeridőben bekövetkező változásokra utal, amikor a rendszeridő és az NTP közötti eltolódás kisebb, mint 128 ms. Ha ez a helyzet, akkor a módosítások fokozatosan történnek. Ezt nevezzük slewing-nek.
- Insane Time
-
Ha a rendszeridő és az NTP-idő közötti eltolódás nagyobb, mint 17 perc, akkor a rendszeridő insane-nek (őrült) tekinthető, és az NTP-daemon nem fog változtatni a rendszeridőn. Különleges lépéseket kell tenni annak érdekében, hogy a rendszeridő 17 percen belül legyen a megfelelő időhöz képest.
- Drift
-
A drift azt a jelenséget jelenti, amikor két óra idővel nem szinkronizálódik. Lényegében, ha két óra kezdetben szinkronban van, de az idő múlásával eltolódik, akkor a clock drift jelenséggel találkozunk.
- Jitter
-
A jitter az órajel utolsó lekérdezése óta bekövetkezett eltérés mértékére utal. Tehát ha az utolsó NTP-szinkronizálás 17 perccel ezelőtt történt, és az NTP szolgáltató és a fogyasztó közötti eltolódás 3 milliszekundum, akkor 3 milliszekundum a jitter.
Most a Linux által az NTP megvalósításának néhány konkrét módját fogjuk megvitatni.
timedatectl
Ha a Linux disztribúció a timedatectl
-t használja, akkor alapértelmezés szerint egy SNTP klienst valósít meg, nem pedig egy teljes NTP implementációt. Ez a hálózati idő kevésbé bonyolult megvalósítása, és azt jelenti, hogy a számítógépünk nem fog NTP-t szolgáltatni más csatlakoztatott számítógépeknek.
Ebben az esetben az SNTP csak akkor fog működni, ha a timesyncd
szolgáltatás fut. Mint minden systemd szolgáltatás esetében, a futását a következővel tudjuk ellenőrizni:
$ systemctl status systemd-timesyncd ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-timesyncd.service.d └─disable-with-time-daemon.conf Active: active (running) since Thu 2020-01-09 21:01:50 EST; 2 weeks 1 days ago Docs: man:systemd-timesyncd.service(8) Main PID: 1032 (systemd-timesyn) Status: "Synchronized to time server for the first time 91.189.89.198:123 (ntp.ubuntu.com)." Tasks: 2 (limit: 4915) Memory: 3.0M CGroup: /system.slice/systemd-timesyncd.service └─1032 /lib/systemd/systemd-timesyncd Jan 11 13:06:18 NeoMex systemd-timesyncd[1032]: Synchronized to time server for the first time 91.189.91.157:123 (ntp.ubuntu.com). ...
A timedatectl
SNTP szinkronizálás állapota a show-timesync
használatával ellenőrizhető:
$ timedatectl show-timesync --all LinkNTPServers= SystemNTPServers= FallbackNTPServers=ntp.ubuntu.com ServerName=ntp.ubuntu.com ServerAddress=91.189.89.198 RootDistanceMaxUSec=5s PollIntervalMinUSec=32s PollIntervalMaxUSec=34min 8s PollIntervalUSec=34min 8s NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-23, RootDelay=8.270ms, RootDispersion=18.432ms, Reference=91EECB0E, OriginateTimestamp=Sat 2020-01-25 18:35:49 EST, ReceiveTimestamp=Sat 2020-01-25 18:35:49 EST, TransmitTimestamp=Sat 2020-01-25 18:35:49 EST, DestinationTimestamp=Sat 2020-01-25 18:35:49 EST, Ignored=no PacketCount=263, Jitter=2.751ms } Frequency=-211336
Ez a konfiguráció a legtöbb helyzetben megfelelő lehet, de mint már említettük, nem lesz elégséges, ha egy hálózaton belül több klienst szeretnénk szinkronizálni. Ebben az esetben ajánlott egy teljes körű NTP-kliens telepítése.
NTP Daemon
A rendszeridő rendszeres időközönként összehasonlításra kerül a hálózati idővel. Ahhoz, hogy ez működjön, szükségünk van egy daemon-ra, amely a háttérben fut. Sok Linux rendszerben ennek a a neve ntpd
. Az ntpd
lehetővé teszi, hogy egy gép ne csak time consumer (időfogyasztó) legyen (azaz képes legyen szinkronizálni a saját óráját egy külső forrásból), hanem szolgáltasson is időt más gépeknek.
Tegyük fel, hogy a számítógépünk systemd-alapú, és a systemctl
-t használja a daemonok vezérlésére! Telepítsük az ntp
csomagokat a megfelelő csomagkezelő segítségével, majd az állapotának ellenőrzésével győződjünk meg arról, hogy az ntpd
démonunk fut:
$ systemctl status ntpd ● ntpd.service - Network Time Service Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2019-12-06 03:27:21 EST; 7h ago Process: 856 ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 867 (ntpd) CGroup: /system.slice/ntpd.service `-867 /usr/sbin/ntpd -u ntp:ntp -g
Bizonyos esetekben szükség lehet az ntpd
indítására és engedélyezésére is. A legtöbb Linux gépen ez a következővel érhető el:
# systemctl enable ntpd && systemctl start ntpd
Az NTP lekérdezések a 123-as TCP porton történnek. Ha az NTP nem működik, győződjünk meg róla, hogy ez a port nyitva van és hallgat!
NTP konfiguráció
Az NTP képes több forrást lekérdezni, és kiválasztani a legjobb jelölteket a rendszeridő beállításához. Ha a hálózati kapcsolat megszakad, az NTP a korábbi beállításokat használja az előzményekből a jövőbeli beállítások becsléséhez.
A Linux disztribúciótól függően a hálózati időszerverek listája különböző helyeken lesz tárolva. Tegyük fel, hogy az ntp
telepítve van!
Az /etc/ntp.conf
fájl tartalmazza a rendszer hálózati idővel való szinkronizálásának módjára vonatkozó konfigurációs információkat. Ez a fájl a vi
vagy a nano
segítségével olvasható és módosítható.
Alapértelmezés szerint a használt NTP-szerverek egy ilyen szakaszban lesznek megadva:
# Use public servers from the pool.ntp.org project. # Please consider joining the pool (http://www.pool.ntp.org/join.html). server 0.centos.pool.ntp.org iburst server 1.centos.pool.ntp.org iburst server 2.centos.pool.ntp.org iburst server 3.centos.pool.ntp.org iburst
Az NTP-szerver hozzáadásának szintaxisa így néz ki:
server (IP Address) server server.url.localhost
A szerverek címei lehetnek IP- vagy akár URL-címek is, ha a DNS megfelelően van konfigurálva. Ebben az esetben a szerver mindig lekérdezésre kerül.
A hálózati rendszergazda fontolóra veheti egy pool használatát (vagy létrehozását) is. Ebben az esetben feltételezzük, hogy több NTP-szolgáltató van, amelyek mindegyike NTP-daemont futtat és azonos idővel rendelkezik. Amikor egy kliens lekérdez egy pool-t, véletlenszerűen választ ki egy szolgáltatót. Ez segít elosztani a hálózati terhelést sok gép között, hogy a poolban ne egyetlen gép kezelje az összes NTP-lekérdezést.
Általában az /etc/ntp.conf
egy pool.ntp.org
nevű szerverpoolt tartalmaz. Így például a server 0.centos.pool.ntp.org
a CentOS gépek számára biztosított alapértelmezett NTP-pool.
pool.ntp.org
Az alapértelmezés szerint használt NTP-szerverek nyílt forráskódú projektek. További információ a ntppool.org oldalon található.
Consider if the NTP Pool is appropriate for your use. If business, organization or human life depends on having correct time or can be harmed by it being wrong, you shouldn’t “just get it off the internet”. The NTP Pool is generally very high quality, but it is a service run by volunteers in their spare time. Please talk to your equipment and service vendors about getting local and reliable service setup for you. See also our terms of service. We recommend time servers from Meinberg, but you can also find time servers from End Run, Spectracom and many others. (Mérlegeljük, hogy az NTP-pool megfelel-e az igényeinknek. Ha üzlet, szervezet vagy emberi élet függ a helyes időtől, vagy ha a hibás idő kárt okozhat, akkor nem szabad “csak úgy lekérni az internetről”. Az NTP Pool általában nagyon jó minőségű, de ez egy önkéntesek által szabadidejükben működtetett szolgáltatás. Kérjük, beszéljen a berendezés- és szervizszolgáltatókkal a helyi és megbízható szolgáltatás beállításáról. Lsd. még a szolgáltatási feltételeinket. Mi a Meinberg időszervereit ajánljuk, de az End Run, a Spectracom és sok más cég időszerverei is megtalálhatók.)
ntpdate
A kezdeti beállítás során a rendszeridő és az NTP szinkronizációja komolyan megszűnhet. Ha a rendszeridő és az NTP-idő közötti eltolódás nagyobb, mint 17 perc, akkor az NTP-daemon nem fog változtatni a rendszeridőn. Ebben az esetben kézi beavatkozásra lesz szükség.
Először is, ha az ntpd
fut, akkor le kell állítani a szolgáltatást. Ehhez használjuk a systemctl stop ntpd
parancsot!
Ezután az ntpdate pool.ntp.org
paranccsal végezzünk el egy kezdeti egyszeri szinkronizálást, ahol a pool.ntp.org
egy NTP-szerver IP-címére vagy URL-címére utal! Egynél több szinkronizálásra is szükség lehet.
ntpq
Az ntpq
egy segédprogram az NTP állapotának megfigyelésére. Miután az NTP-daemont elindítottuk és konfiguráltuk, az ntpq
segítségével ellenőrizhetjük az állapotát:
$ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== +37.44.185.42 91.189.94.4 3 u 86 128 377 126.509 -20.398 6.838 +ntp2.0x00.lv 193.204.114.233 2 u 82 128 377 143.885 -8.105 8.478 *inspektor-vlan1 121.131.112.137 2 u 17 128 377 112.878 -23.619 7.959 b1-66er.matrix. 18.26.4.105 2 u 484 128 10 34.907 -0.811 16.123
Ebben az esetben a -p
a print-et jelenti, és egy összefoglalást jelenít meg a peerekről. A hostcímek IP-címként is visszaadhatók az -n
használatával.
remote
-
Az NTP-szolgáltató hostneve.
refid
-
Az NTP-szolgáltató referencia ID-ja.
st
-
A szolgáltató rétege (stratum).
when
-
Az utolsó lekérdezés óta eltelt másodpercek száma.
poll
-
A lekérdezések közötti másodpercek száma.
reach
-
Állapotazonosító, amely jelzi, hogy sikerült-e elérni egy szervert. A sikeres kapcsolatok ezt a számot 1-gyel növelik.
delay
-
A lekérdezés és a szerver által adott válasz közötti idő ms-ban.
offset
-
A rendszeridő és az NTP-idő közti idő ms-ban.
jitter
-
A rendszeridő és az NTP közötti eltolódás ms-ban az utolsó lekérdezéskor.
Az ntpq
rendelkezik egy interaktív móddal is, amely akkor érhető el, ha kapcsolók vagy argumentumok nélkül futtatjuk. A ?
kapcsolóval azon parancsok listáját kapjuk vissza, amelyeket az ntpq
felismer.
chrony
A chrony
egy újabb módja az NTP implementációjának. Egyes Linux rendszereken alapértelmezés szerint telepítve van, de minden nagyobb disztribúcióhoz letölthető. A chronyd
a chrony-daemon, a chronyc
pedig a parancssori interfész. Előfordulhat, hogy a chronyc
-vel való interakció előtt el kell indítani és engedélyezni kell a chronyd
-t.
Ha a chronyt alapértelmezett konfigurációval telepítjük, akkor a chronyc tracking
parancs használatával információt kaphatunk az NTP-ről és a rendszeridőről:
$ chronyc tracking Reference ID : 3265FB3D (bras-vprn-toroon2638w-lp130-11-50-101-251-61.dsl.) Stratum : 3 Ref time (UTC) : Thu Jan 09 19:18:35 2020 System time : 0.000134029 seconds fast of NTP time Last offset : +0.000166506 seconds RMS offset : 0.000470712 seconds Frequency : 919.818 ppm slow Residual freq : +0.078 ppm Skew : 0.555 ppm Root delay : 0.006151616 seconds Root dispersion : 0.010947504 seconds Update interval : 129.8 seconds Leap status : Normal
Ez a kimenet rengeteg információt tartalmaz, többet, mint ami más implementációkból elérhető.
Reference ID
-
Az a referenciaazonosító és név, amellyel a számítógép jelenleg szinkronizálva van.
Stratum
-
Az ugrások (hop) száma a csatlakoztatott referenciaórával rendelkező számítógéphez.
Ref time
-
Ez az az UTC-idő, amikor az utolsó mérés a referenciaforrásból megtörtént.
System time
-
A rendszeróra késése a szinkronizált szervertől.
Last offset
-
Az utolsó órafrissítés becsült eltolódása.
RMS offset
-
Az eltolódás hosszú távú átlaga.
Frequency
-
Ez az a sebesség, amellyel a rendszer órája tévedne, ha a chronyd nem korrigálná azt. Ezt az értéket ppm-ben (parts per million) látjuk.
Residual freq
-
Maradékfrekvencia, amely a referenciaforrásból származó mérések és a jelenleg használt frekvencia közötti különbséget jelzi.
Skew
-
A frekvencia becsült hibahatára.
Root delay
-
A hálózati útvonal késleltetésének összege a rétegszámítógépig, ahonnan a számítógépet szinkronizálják.
Leap status
-
Ez az ugrási állapot, amely a következő értékek egyike lehet: normál, másodperc beszúrása, másodperc törlése vagy nem szinkronizált.
A legutóbbi érvényes NTP-frissítésre vonatkozó részletes információkat is megtekinthetjük:
# chrony ntpdata Remote address : 172.105.97.111 (AC69616F) Remote port : 123 Local address : 192.168.122.81 (C0A87A51) Leap status : Normal Version : 4 Mode : Server Stratum : 2 Poll interval : 6 (64 seconds) Precision : -25 (0.000000030 seconds) Root delay : 0.000381 seconds Root dispersion : 0.000092 seconds Reference ID : 61B7CE58 () Reference time : Mon Jan 13 21:50:03 2020 Offset : +0.000491960 seconds Peer delay : 0.004312567 seconds Peer dispersion : 0.000000068 seconds Response time : 0.000037078 seconds Jitter asymmetry: +0.00 NTP tests : 111 111 1111 Interleaved : No Authenticated : No TX timestamping : Daemon RX timestamping : Kernel Total TX : 15 Total RX : 15 Total valid RX : 15
Végül a chronyc sources
az idő szinkronizálásához használt NTP-szerverekről ad információt:
$ chronyc sources 210 Number of sources = 0 MS Name/IP address Stratum Poll Reach LastRx Last sample ===============================================================================
Jelenleg ezen a gépen nincsenek konfigurálva források. A chrony konfigurációs fájl megnyitásával hozzáadhatunk forrásokat a pool.ntp.org
címről. Ez általában a /etc/chrony.conf
címen található. Ha megnyitjuk ezt a fájlt, látnunk kell, hogy néhány szerver alapértelmezés szerint szerepel a listában:
210 Number of sources = 0 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== # Most computers using chrony will send measurement requests to one or # more 'NTP servers'. You will probably find that your Internet Service # Provider or company have one or more NTP servers that you can specify. # Failing that, there are a lot of public NTP servers. There is a list # you can access at http://support.ntp.org/bin/view/Servers/WebHome or # you can use servers from the 3.arch.pool.ntp.org project. ! server 0.arch.pool.ntp.org iburst iburst ! server 1.arch.pool.ntp.org iburst iburst ! server 2.arch.pool.ntp.org iburst iburst ! pool 3.arch.pool.ntp.org iburst
Ezek a szerverek a saját szervereinkbe való belépéskor szintaxis-útmutatóként is szolgálnak. Ebben az esetben azonban egyszerűen csak eltávolítjuk a !
-t minden sor elejéről, így megszüntetve a kikommentezést, és a pool.ntp.org
projekt alapértelmezett szervereit használjuk.
Ebben a fájlban megváltoztathatjuk továbbá az alapértelmezett konfigurációt a skew és a drift tekintetében, valamint a driftfile és a keyfile helyét.
Ezen a gépen nagy kezdeti órajelkorrekciót kell végeznünk. Úgy döntünk, hogy a következő sort nem kommentezzük ki:
! makestep 1.0 3
A konfigurációs fájl módosításai után indítsuk újra a chronyd
szolgáltatást, majd a chronyc makestep
segítségével manuálisan állítsuk át a rendszerórát:
# chronyc makestep 200 OK
Ezután a korábbiakhoz hasonlóan használhatjuk a chronyc tracking
-t, hogy ellenőrizzük megtörténtek-e a változások.
Gyakorló feladatok
-
Írjuk le a megfelelő kifejezést az egyes definíciókhoz:
Definíció Kifejezés Egy számítógép, amely megosztja velünk a hálózati időt
Távolság a referenciaórától, ugrásban (hop) vagy lépésben (step)
A rendszeridő és a hálózati idő közötti különbség
A rendszeridő és a hálózati idő közötti különbség az utolsó NTP-lekérdezés óta
A hálózati időt szolgáltató és a terhelést egymás között megosztó szerverek csoportja
-
Adjuk meg, hogy melyik parancsot használnánk a következő értékek kimenetéhez:
Érték chronyc tracking
timedatectl show-timesync --all
ntpq -pn
chrony ntpdata
chronyc sources
Jitter
Drift
Interval of Poll
Offset
Stratum
IP Address of Provider
Root Delay
-
Egy Linux szerverből és több Linux asztali számítógépből álló vállalati hálózatot hozunk létre. A szerver statikus IP-címe 192.168.0.101. Úgy döntünk, hogy a szerver csatlakozik a
pool.ntp.org
címre, majd NTP-időt biztosít az asztali számítógépek számára. Írjuk le a szerver és az asztali számítógépek konfigurációját! -
A Linux gépen a helytelen idő van. Írjuk le az NTP hibaelhárításának lépéseit!
Gondolkodtató feladatok
-
Kutassuk fel az SNTP és az NTP közötti különbségeket!
SNTP NTP -
Miért dönthet úgy egy rendszergazda, hogy nem használja a
pool.ntp.org
címet? -
Hogyan tudná eldönteni egy rendszergazda, hogy csatlakozna vagy más módon járulna hozzá a
pool.ntp.org
projekthez?
Összefoglalás
Ebben a leckében megtanultuk:
-
Mi az NTP és miért fontos.
-
Az NTP-daemon konfigurálása a
pool.ntp.org
projektből. -
Az
ntpq
használata az NTP konfiguráció ellenőrzésére. -
A
chrony
használata NTP alternatívaként.
A leckében használt parancsok:
timedatectl show-timesync --all
-
SNTP információk megjelenítése a
timedatectl
használata esetén. ntpdate <address>
-
Manuális, egyszeri NTP step-frissítés (step update).
ntpq -p
-
Az NTP legutóbbi poll előzményeinek megjelenítése. Az
-n
az URL-címeket IP-címekkel helyettesíti. chronyc tracking
-
Az NTP állapotának megjelenítése chrony használata esetén.
chronyc ntpdata
-
NTP-információk megjelenítése a legutóbbi pollról.
chronyc sources
-
NTP-szolgáltatókra vonatkozó információk megjelenítése.
chronyc makestep
-
Manuális, egyszeri NTP-step frissítés chrony használata esetén.
Válaszok a gyakorló feladatokra
-
Írjuk le a megfelelő kifejezést az egyes definíciókhoz:
Definíció Kifejezés Egy számítógép, amely megosztja velünk a hálózati időt
Provider (szolgáltató)
Távolság a referenciaórától, ugrásban (hop) vagy lépésben (step)
Stratum
A rendszeridő és a hálózati idő közötti különbség
Offset (eltolódás)
A rendszeridő és a hálózati idő közötti különbség az utolsó NTP-lekérdezés óta
Jitter
A hálózati időt szolgáltató és a terhelést egymás között megosztó szerverek csoportja
Pool
-
Adjuk meg, hogy melyik parancsot használnánk a következő értékek kimenetéhez:
Érték chronyc tracking
timedatectl show-timesync --all
ntpq -pn
chrony ntpdata
chronyc sources
Jitter
X
X
Drift
Interval of Poll
X
X
X (
when
oszlop)X
X
Offset
X
X
X
Stratum
X
X
X
X
X
IP Address of Provider
X
X
X
X
Root Delay
X
X
-
Egy Linux szerverből és több Linux asztali számítógépből álló vállalati hálózatot hozunk létre. A szerver statikus IP-címe 192.168.0.101. Úgy döntünk, hogy a szerver csatlakozik a
pool.ntp.org
címre, majd NTP-időt biztosít az asztali számítógépek számára. Írjuk le a szerver és az asztali számítógépek konfigurációját!Győződjünk meg róla, hogy a szerveren az SNTP helyett az ntpd szolgáltatás fut! Használjuk a
pool.ntp.org
poolokat az/etc/ntp.conf
vagy/etc/chrony.conf
fájlban! Minden kliens esetében adjuk meg a192.168.0.101
címet minden/etc/ntp.conf
vagy/etc/chrony.conf
fájlban! -
A Linux gépen a helytelen idő van. Írjuk le az NTP hibaelhárításának lépéseit!
Először is győződjünk meg arról, hogy a gép csatlakozik az internethez! Ehhez használjuk a
ping
parancsot! Ellenőrizzük, hogy az ntpd vagy SNTP szolgáltatás fut-e asystemctl status ntpd
vagy asystemctl status systemd-timesyncd
segítségével! Előfordulhat, hogy hibaüzenetek jelennek meg, amelyek hasznos információkkal szolgálnak. Végül, egy olyan paranccsal, mint azntpq -p
vagy achrony tracking
ellenőrizzük, hogy történt-e kérés. Ha a rendszeridő drasztikusan eltér a hálózati időtől, előfordulhat, hogy a rendszeridő “insane”-nek minősül, és kézi beavatkozás nélkül nem módosítható. Ebben az esetben használjuk az előző leckében leírt parancsot vagy egy olyan parancsot, mint azntpdate pool.ntp.org
, hogy egyszeri ntp szinkronizálást hajtsunk végre!
Válaszok a gondolkodtató feladatokra
-
Kutassuk fel az SNTP és az NTP közötti különbségeket!
SNTP NTP kevésbé pontos
pontosabb
kevesebb erőforrást igényel
több erőforrást igényel
nem tud időszolgáltatóként működni
tud időszolgáltatóként működni
csak steps
steps vagy slews
egyetlen forrásból kéri az időt
több NTP-szervert is figyelhet, és az optimális szolgáltatót használhatja
-
Miért dönthet úgy egy rendszergazda, hogy nem használja a
pool.ntp.org
címet?Az ntppool.org oldalról: Ha feltétlenül fontos, hogy pontos idő legyen, akkor meg kell fontolni az alternatívákat. Hasonlóképpen, ha az internetszolgáltatónk rendelkezik időszerverrel, akkor ajánlott azt használni helyette.
-
Hogyan tudná eldönteni egy rendszergazda, hogy csatlakozna vagy más módon járulna hozzá a
pool.ntp.org
projekthez?A www.ntppool.org oldalról: A szervernek statikus IP-címmel és állandó internetkapcsolattal kell rendelkeznie. A statikus IP-cím egyáltalán nem, vagy évente legfeljebb egyszer változhat. Ezen túlmenően a sávszélességi követelmények szerények: 384 - 512 Kbit sávszélesség. Stratum 3 vagy 4 szerverek csatlakozhatnak.