Órák szinkronizálása

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen Csaba (vitalap | szerkesztései) 2013. október 27., 23:01-kor történt szerkesztése után volt.

(eltér) ←Régebbi változat | Aktuális változat (eltér) | Újabb változat→ (eltér)

Írta: Reegn Zoltán, 2009. december

Ez a szócikk betekintést nyújt az időszinkronizációs módszerek közötti különbségekbe. Első lépésben áttekintjük a népszerűbb időszinkronizációs protokollokat, majd egyenként megnézünk pár időszinkronizációs csomagot, elemezzük előnyeiket/hátrányaikat.

Tartalomjegyzék

1 Fogalmak

slewing - az időt nem korrigáljuk gyorsabban egy adott sebességnél (max. 0.5ms/s), ha egy bizonyos mértéknél(pl. 128ms-nál) kisebb az eltérés az időszinkronizációs szervertől lekért, és a saját óránk ideje között(lassítjuk/gyorsítjuk az órát)

stepping - ugrás a jó érték becslésére (az órát ugratjuk előre/vissza). Ezt a módszert célszerű csak rendszerindításkor használni, mivel kritikus folyamatokat negatívan befolyásolhat, ha visszaugrunk az időben.

2 Időszinkronizációs protokollok

2.1 DAYTIME Protocol

RFC 867

Az időt egy ASCII stringként adja vissza a protokollt támogató szerver. A 13-as TCP vagy UDP portot használja kommunikációra.

Hátránya, hogy kis körben használják, pontatlan, nem definiált az ASCII string pontos formátuma, ezért problémás a feldolgozása.

2.2 TIME Protocol

RFC 868

A 37-es TCP vagy UDP portot használja kommunikációra. A szerver az időt egy 32 bites bináris alakban küldi, ami az 1900. jan. 1. 00:00 UTC óta eltelt másodpercek számát írja le. Az ilyen formátumú időreprezentáció ~136 évet fed le másodperces felbontással.

2007-ben megkezdődött a protokoll használatának fokozatos leváltása az NTP-re ott, ahol még alkalmazzák.

Hátrány: támgatása megszűnőben van, az időbélyeg később gondokat okozhat(2036-os probléma), SNTP gyakorlatilag ugyanez, csak pontosabb.

2.3 NTP - Network Time Protocol

RFC 778 RFC 891 RFC 956 RFC 1305

A legelterjedtebb Internetes időszinkronizációs protokoll. Az időt több szervertől is megkérdezi, majd átlagolja a kapott időbélyegeket. Az átlagtól legjobban eltérő válaszokat eldobja, majd a többiből ismét átlagot számol. Ezt a második átlagot használja a pontos idő becslésére. A kommunikációt UDP/IP-n keresztül végzi, a 123-as UDP porton. Az NTP időbélyeg egy 64 bites szám, ami egy 32 bites másodperc, és 32 bites töredék másodperc részből áll. Az időbélyeg az 1900 jan. 1 00:00 UTC óta eltelt időt tárolja, felbontása ~200 ps (2^-32). Ebből következik, hogy az NTP által használt időbélyeg 2036-ban fordul át, a 2038-as Unix Millennium Bug előtt.


Előnye, hogy nagy infrastruktúra hálózat épül rá, nagy a támogatottsága, széles körben elterjedt, nem tudományos célokra elég pontosságot biztosít Hátránya, hogy olyan időbélyeggel dolgozik, ami később gondokat okozhat (2036-os probléma)

Kapcsolódó fogalom:

stratum - ntp-nél használt fogalom. Egy hierarchikus rendszert ír le, melyben több rétegen (strata) helyezkednek el az NTP szerverek, mindegyiknek megvan a saját rétegszáma, melyből következtethetünk az általuk szolgáltatott érték pontosságára is. 0-ás rétegben vannak az atomórák és nagy pontosságú órák, az 1-es réteg az ezekhez közvetlenül kapcsolódó számítógépek. A 0-ás réteg gépei nem csatlakoznak közvetlenül az internetre.


Az NTPv4 fontosabb újdonságai az NTPv3-hoz képest:

  • IPv6 címeket is kezel
  • autokey nyilvános kulcsú titkosítást támogat
  • Burst mód (iburst és burst)
  • pontosabb óraszabályozás
  • nanokernel támogatás - nanoszekundumos pontosságot biztosít

2.4 SNTP - Simple Network Time Protocol

RFC 1361 RFC 1769 RFC 2030 RFC 4330

Hasonló az NTP-hez, azonban csak egyetlen NTP szervert kérdez meg az aktuális időről (hasonlóan a daytime vagy time protokollhoz), majd ezt állítja be magának.

Előnye: egyszerűbb, mint az NTP, beágyazott rendszerekbe ezért ideális (kisebb komplexitás - kisebb számítási igény) Hátránya: vakon megbízik egy NTP szerver által szolgáltatott értékben, nem viszonyít más szerverekhez.

3 Időszinkronizációra használt programok

3.1 ntpdate

Az időt több szervertől is megkérdezi, mindekitől többször. Egy adott algoritmussal kiszűri a túl nagy eltérésű szervereket, majd a maradékból egy másik algoritmussal kiválasztja a legpontosabbat. A program pontossága függ a szerverek számától, a minták számától, és a mintavételek között eltelt időtől. Kézileg, vagy rendszerinduláshoz ütemezve ajánlott futtatni. Mivel nem lehet daemonizálni, ezért az nem szabályozza az órát a beállítás után.

Amennyiben a host időbeni eltérése a szervertől fél másodpercen belülre esik, akkor az adjtime() függvényhívással a helyes időre "sietteti" vagy "késlelteti" a host óráját. Amennyiben az eltérés fél másodpercnél nagyobb lenne, akkor a settimeofday() függvényhívással a helyes időpontra ugraszja a host óráját.

Amennyiben ntpd (ntp daemon) is fut azon a gépen, amelyiken az ntpdate-et futtatjuk, akkor az ntpdate nem állítja át az órát.

3.2 openntpd

A fejlesztők szerint az NTPv3 szabvány olyan nagy pontosságot ír le, ami egy linuxos gépen elérhetetlen. Mellőzve a túlzott pontosságot egy egyszerűbb kliensprogramot készítettek. A program ~3kloc (3 kilo line of code - 3000 sor kód), tehát nagyon kompakt. +-50ms-os pontosságot garantál, ami egy linuxos rendszer által biztosított legnagyobb pontosság.

A programban privilégium szeparációt valósítottak meg. Ez azt jelenti, hogy a program több részre van felosztva, és minden rész csak azokkal a jogokkal rendelkezik, amik a feladatának végrehajtásához szükségesek.

Az openntpd-ben a feladatokat két processz látja el:

  • szülő - rootként fut. Ő végzi a kernelhívásokat, amik az időt állítják.
  • ntp engine - _ntp userként ként fut. chroot-ol /var/empty-be. Ezzel lekorlátozódik a fájlrendszerelérése.

A processzek között a kommunikáció egy unix domain socket-páron keresztül történik.

A szülő és az ntp engine között használt üzenetek:

  • IMSG_ADJTIME - ntp engine megkéri a szülőt, hogy hívja meg az adjtime() függvényt
  • IMSG_SETTIME - ntp engine megkéri a szülőt, hogy hívja meg a settime() függvényt
  • IMSG_HOST_DNS - ntpengine megkéri a szülőt, hogy oldja fel a megadott hostnevet (/etc/resolv.conf)

A szülő nem bízik a kliensében, ezért nagyon szigorú az üzenetek formátumát illetően. Ha az üzenet formátuma nem megfelelő, bontja a kapcsolatot a klienssel.

3.3 rdate

Egy szegényes időszinkronizációs program. Lekéri a szervertől az aktuális időt, majd a kapott időt állítja be a host óráján.

3.4 ntpd

Az ntpd egy időszinkronizációs daemon. A többi vizsgált időszinkronizációs módszerrel ellentétben az ntpd már támogatja az NTPv4-et, de kompatibilis maradt az NTPv3-mal is.

3.5 taiclock

A taiclock szerverek az időt TAI64NA formátumban küldik a hostoknak. A TAI64 időbélyegek előnyéről itt lehet többet olvasni. A protokoll UDP/IP fölött is működik.

3.6 chrony

Két programból álló időszinkronizációs csomag. A két program neve chronyd és chronyc. A chronyd egy daemon, amely ntp-szerverekhez szinkronizálja az időt. A következő jellemzőkkel bír:

  • az időt slew módszerrel korrigálja, ha ntp szerverhez tud kapcsolódni
  • nyilvántartja, hogy milyen mértékű a gép órájának pontatlansága, így két szinkronizálás között is viszonylag pontosan tartja az órát
  • újraindítás vagy ki/bekapcsolások között is pontosan tartja az órát, rendszerinduláskor a nyilvántartott pontatlanságból számítja a beállítandó időt

Ezek azt eredményezik, hogy chrony-t használva, egy internetre ritkán csatlakozó gépen tovább marad pontos az idő, mint ha ntpd-t használnánk.

A chronyc egy interfészt szolgáltat a chronyd beállításaihoz. A kettejük közötti kommunikáció kliens-szerver jellegű.

4 Saját NTP-szerver konfigurálása

Alapvető példa egy /etc/ntp.conf fájlra:

# --- GENERAL CONFIGURATION ---
server  0.europe.pool.ntp.org
server  1.europe.pool.ntp.org
server  2.europe.pool.ntp.org
server  3.europe.pool.ntp.org
server  127.127.1.0
fudge   127.127.1.0 stratum 10

# Drift file.
driftfile /etc/ntp/drift

A legegyszerűbb konfigurációban egy NTP-szerver van. A server 127.127.1.0 sor azért kell, mert így tudjuk beállítani az extra opciókat a fudge paranccsal (pl. stratum szintet)

A drift fájl eltérés-fájl. Idővel az ntpd megtanulja, ohgy mennyi a rendszer tévedése, és ez alapján automatikusan kiigazítja a hibát.

Fontosabb konfigurációs paraméterek:

paraméter hatás
server A szinkronizációs szerver beállítása
fudge További paraméterek beállításának kapcsolója
stratum 10 Ezzel kézileg állíthatjuk be a szerverünk stratum szintjét
driftfile A drift fájl helyét határozhatjuk meg vele

Ha egy szerver asszociációnak az "iburst" (initial burst) opciót adjuk meg, az azt fogja eredményezni, hogy ha a szerverrel megszakad a kapcsolat, akkor mikor újra kapcsolatba tudunk lépni vele, 8db, két-két másodpercenként küldött kérést küld az ntpd a szervernek. Így PPP vagy ISDN internetkapcsolat kiépülésekor percek helyett másodpercek alatt szinkronizál a gépünk. A "dynamic" opciót használva olyan szervert is be tudunk állítani referenciának, ami a konfiguráláskor nem elérhető. Ez az opció feltételezi, hogy a szerver valamikor elérhető lesz. példa:

server 0.europe.pool.ntp.org iburst dynamic

4.1 Restrict

A restrict opcióval korlátozhatjuk, hogy a hálózaton levő rendszerek mit csinálhatnak az NTP-szerverrel:

#A localhostnak teljes hozzáférést biztosítunk
restrict 127.0.0.1

#A beállított időszinkronizációs szervereknek be kell állítani a jogosultságaikat,
#hogy tudjunk róluk szinkronizálni
restrict 0.europe.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 1.europe.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 2.europe.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 2.europe.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery

#A belső privát hálózatunkon levő hostoknak jogokat adunk queryk küldésére
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

Az fontosabb restrict jogosultság korlátozások

korlátozás hatás
ignore az adott hálózatból érkező minden ntp csomagot eldobunk
kod Ha valaki túl gyakran küld lekérdezéseket, küld egy kérést a lassításra
nomodify Az olyan kérések tiltása, amik módosítanák az NTP-szervert
notrap Deny control message trap service
noquery NTP lekérdezések tiltása az adott hálózatból
noserve ntpq / ntpdc kéréseken kívül minden ntp kérést tilt
notrust Csak kriptgráfiailag titkosított kapcsolatok fogadása
nopeer Deny all packets that attempt to establish a peer association

4.2 A szerver indítása

Első alkalommal indításkor érdemes egyet ntpdate-tel szinkronizálni, hogy legyen egy alapidő, amihez hozzáigazodik majd az ntpd.

[bash]# ntpdate -b pool.ntp.org

az ntpd.conf beállítása után újraindítjuk az ntpd-t.

[bash]# /etc/init.d/ntpd restart

A következő paranccsal megbizonyosodhatunk arról, hogy az ntp szerverünk fut:

[bash]# ntpq -p 192.168.1.1

A következőhöz hasonló kimenetet kapunk, ha elérhető az ntp szerver az adott IP-n:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*edge.tillo.ch   192.87.106.2     2 u   14   64    1   66.171   -4.503   2.580
+dns1.rmplc.co.u 193.62.22.98     2 u   13   64    1   74.657   -4.340   1.852
-nx2.xplo-re.net 94.23.99.153     3 u   12   64    1   80.919  -13.224   1.590
+ns1.servbit.ro  80.96.120.252    2 u   11   64    1   87.840  -16.949   1.054
 LOCAL(0)        .LOCL.          10 l   26   64    1    0.000    0.000   0.001

A jelzések a következőket jelentik a címek előtt:

  • csillag: ehez szinkronizálunk jelenleg
  • +:szinkronizálásra jelölt szerver
  • -:nem elég jó minőségű szerver

Amennyiben nem elérhető a szerverünk, a következőhöz hasonló hibát kapunk:

192.168.1.1: timed out, nothing received
***Request timed out

Egy másik gépről a következő paranccsal ellenőrizhetjük azt, hogy fut-e az ntp-szerver:

[bash]# ntpdate 192.168.1.1

4.3 dhcpd beállítása

Amennyiben szeretnénk a magánhálózatunk gépeit dhcp-n keresztül informálni az új időszinkronizációs szerverünk elérhetőségéről, akkor azon a gépen, ahol a dhcpdaemont futtatjuk, módosítsuk az /etc/dhcpd.conf fájlt a következőképpen:

bővítsük a subnet-re érvényes bejegyzést, ahol alkalmazni szeretnénk az új NTP-szerverünket.

subnet 192.168.1.0 netmask 255.255.255.0 { //így néz ki egy subnet bejegyzés

...
    option ntp-servers 192.168.1.1; //az NTP-szerverünk címe a hálózaton
...

}

ezután indítsuk újra az dhcpdaemont:

[bash]# /etc/init.d/dhcpd restart

5 Kapcsolódó irodalom

NTP configuration

openNTPD

NTP eszközök

DHCP server configuration

Személyes eszközök