Názory k článku Přesný čas: nalaďte se podle atomových hodin

Před nějakým časem jsem používal i ntpd, pak jsem se vrátil k ntpdate. Proč? Důvodů je několik.

Zaprvé - existuje strašně moc nepojmenovaných implementací ntpd, nenašel jsem tedy žádný relevantní manuál ke konfiguráku, direktivy z manuálových stránek na webu nefungovaly a prakticky jediné, co se mi povedlo rozchodit, je jednoduchý sync s výchozím nastavením.

Tím chci naznačit, že třeba ACL nebo jakýkoli systém přidělování práv "kdo smí můj ntpd použít pro synchronizaci" prakticky neexistuje na systémové úrovni. Ntpd si myslí, že je pánem světa (a systému) a nenechá si vnutit ani adresu, na které naslouchat, ani interface, na který se bindnout. Od admina se očekává, že prostě přístupy nastaví v ntpd.conf, tudíž jedinou jeho záchranou je netfilter, který, díkybohu, ntpd obejít neumí.

S tím souvisí i rozsáhlé "zaprasení" otevřenými listen sockety, v podobném stylu, jako to dělá postfix s unix sockety.

Velice rád přemigruji všude na nějakou jednoduchou implementaci ntpd, která bude jednoduchostí použití připomínat ntpdate a nebude se snažit o ovládnutí systému.

Jen pro doplnění, abych ušetřil některým snahy o opravy.

Config direktiva "listen on" (jakou je možné najít v BSD manuálech pro ntpd na webu) nefunguje.
Na Debianu Squeeze (resp. současné zmražené verzi) nefunguje ani parametr "-I" u ntpd - "Listen on an interface name or address". Adresu to úplně ignoruje, jméno interface sice uřízne explicitní naslouchání na každém interface zvlášť, ale ti chytřejší si (vedle bindů podle zvoleného interface) všimnou i listen na 0.0.0.0 (tedy INADDR_ANY). Nevím, jestli je to bug nebo nějaký prapodivný záměr.

Na další pokusy si teď z hlavy nevzpomenu, experimentoval jsem s tím na Lennym před pár lety.

Jeste pridam, ze uz se vyskytlo par remote exploitu pres udp response v NTPD.

Vsetky tebou popisane problemy riesi OpenNTPD - http://openntpd.org/ - co je podobne ako OpenSSH podprojekt OpenBSD.

Jako sorráč, ale nejste všichni tři (vč. autora) trochu mimo? Jako mimo mísu, či realitu, chcete-li.

V jakem smyslu?

no jako sorac .. abych pouzil tva slova
tyhle vykriky do tmy fakt miluju
bud vis prd a chces se jen zviditelnit
nebo sve tvrzeni necim smysluplnym podlozis

Z nějakého důvodu používám chrony místo ntpd. Asi mi kdysi někde ntpd nějak zazlobil, anebo mi vadily závislosti, už nevím.

Jinak se mi zdá dobré používat ntpdate dál, ale jen ve startovacím skriptu, protože se může stát, že čas jde sice v systému přesně, ale v HW hodinách je špatně, takže po restartu (třeba po pádu) se čas přečte z HW hodin, jde špatně o víc jak 17 minut a ntpd nejede. Proto ntpdate ve startovacím skriptu srovná čas nahrubo ještě předtím, než se pospouští služby citlivé na skoky v čase a pak už fugnuje i ntpd/chrony...

V takom prípade sa dá jednorázovo nastavič čas (viď článok) a potom podľa neho nastaviť systémové hodiny (tie by sa snáď počas jedného reštartu nemali posunúť o viac ako 17 minút) príkazom
#hwclock --systohc

vice takovych clanku :-)

pri bootu udelat rdate/ntpdate (hned na zacatku pred startem ostatnich daemonu), pak pouzivat ntpd.

fyi openbsd napsali vlastni ntp daemona, ktereho zbavili balastu a ktery ma delat jen to nejvice potrebne, lze ho najit i v debianu/ubuntu.

Když mám LINUX-PC jako pracovní stanici, je s tím nějaký problém jednou za čas to nastavit v biosu dle rádiem řízených hodin ručně(kromě drobného diskomfortu)?
Systém předci nemůže poznat jak dlouho bylo PC vypnuto.
Odchylka jednotek minut mi nevadí :-) .

Jistěže to problém není, ale článek je o automatickém a dlouhodobém udržování času s přesností milisekund. Na pracovní stanici je to celkem fuk, ale stále běžící servery potřebují jednotný čas.

Na servrech je to jasné a opodstatněné,
ale přirozená línost říka, že celková časová náročnost je menší
pro 2x ročne ručnou změnu času, než si zprovozňovat NTP.

FreeBSD 8.0 a vyssi uz ma tez ntpd demona v zakladnim systemu vcetne pripraveneho jednoducheho konfiguraku. Staci jen povolit demona a o nic dalsiho se nemusite starat. Tez jsem na nej presel, protoze pro jeho zprovozneni nemusim delat temer nic :-)

Jeden instalační příkaz a je nafurt hotovo. Distribuce už to mívají nakonfigurované přímo v balíčku (debian, ubuntu, k ostatním nemám přístup). To je daleko rychlejší, než jednou čekat u čerstvě zapnutého kompu a lézt do biosu :)

A na Fedore pri instalaci jen neco ve stylu "[x] Synchronize time over Internet"...

Tak to taky delam. NTP jsem zkousel tvarilo se to napred ze to funguje ale po delsi dobe byly hodiny uplne spatne.

Mit system a spolehat se ze jsou na nem presne hodiny kdyz jsou tam hodiny spatne je pro me jeste horsi jak mit system u ktereho vim ze se na hodiny nemuzu spolehnout.

Doma mam radiovy budik ten me jeste nezklamal.

Díky za pěkný článek a příkaz ntpq -p :)

jen drobnost, pool nevybira servery blizko ale nahodne:
uses DNS round robin to make a random selection

da se vybrat podle kontinentu ale stejne je to random, autor by si mohl precist stranky na ktery odkazuje.

jinak v cr doporucuju servery:

tik.cesnet.cz
tak.cesnet.cz

oba rizeny primo podle GPS a na pateri cesnetu. Na doma asi zbytecny ale na servery idealni.

"primo z GPS"

Nema nejaky NTP server AV CR URE nebo UTIA nebo tak nekdo kdo ma atomovky primo v dome? U GPS se obavam aby nejaka porucha prijmu signalu nezpusobila poruchu hodin.

Ano, onen NTP server (time.ufe.cz) je v ÚFE AV ČR (bývalém ÚRE).

Žiji v představě, že ntpdate pokud je rozdíl času systémového a zjištěného přes NTP menší než nějaká mez, tak nenastaví čas skokově, ale dá kernelu povel zvolna čas systémovy sladit (tzn. chvíli plyne rychleji nebo pomaleji, dokud se rozdíl nesrovná).

ano presne tak,
v manualu je uvedeno ze je ten casovy interval 128 ms, ale v zdrojakach je videt 1/2 sekundy.

Pokud je offset vetsi nez 1/2 sekundy, provede se settimeofday (tedy nastavi se novy cas hrubou silou).

Jak uz bylo receno, parametr -B zajisti adjtime() misto settimeofday(), tudiz zrejme asi to same jako ntpd. Obecne se v manualu pise, ze ntpd ma nejaky sofistikovanejsi algoritm, ale nevim, zdrojaky jsem nestudoval.

mam momentalne jednu taku aktualnu otazku a to ako sa to sprava pri zmene casu (letny zimny) pretoze prave vtedy by mal vzniknut ten schod vacsi ako 1000 sekund a predsa ntpd nespadne

On se mění jen lokální čas. UTC (ITU, GMT, nebo jak se to teď správně nazývá) je pořád stejný.

ntpd pracuje s UTC. U UTC k zadnym posunum ohledne letniho nebo zimniho casu nedochazi. K problemum muze dojit, pokud si uzivatel spatne nastavi, zda ma v BIOSu UTC nebo lokalni cas. V tom pripade je ale reseni trivialni: nastavit to spravne :-)

To je otázka, umím si představit situaci, kdy uživatel/admin chce, aby HW čas počítače byl též v příslušné zóně, nikoliv v UTC. "Hodiny v BIOSu" si během své činnosti ntpd rovná sám, pro přechod na letní/zimní čas (pro hnidopichy: ano, vím, že označení "zimní čas" je věcně nesprávné ;) ) stačí dát do crona:

01 03 25-31 mar,oct * /sbin/hwclock -w 1>/dev/null 2>&1

ntp daemona to nerozruší a nesejme, odzkoušeno ;)

Když už mám chytrý telefon, ať je na něm přesný čas. :-)

Nesyncuje se cas na telefonech ze site GSM?

Len ak to siet podporuje (nie kazdy operator to podporuje) a je to na telefone nastavene.

Taky by mě to zajímalo. Ale na druhou stranu, při hraní si s Androidem jsem mnohokrát zrušil nastavení data a času a po bootu ROM byl vždy atomově přesný (kontroloval jsem přes aplikaci v Marketu). Tak že by to přeci jen fungovalo?

Mě synchro u O2 funguje.

Me to teda na mobilu e52 funguje bez problemu. Sit mam t-mobile, ale fungovalo mi to i v jinych (i v jinych statech).

V ČR si pamatuju, že Oskar to nepodporoval, po akvizici Vodafonem to za pár měsíců začalo fungovat. Nedávno jsem to zkoušel u O2, tam to funguje bez problémů. T-Mobile to dodnes zprovozněné nemá a nikdy neměl, pokud se na to budete vyptávat na infolince (zkuste to), tak vám řeknou, že si máte vyplnit APN a navázat datové spojení, pak se snad čas srovná (nezkoušel jsem).

Zalezi, co povazujete za opetatora u Vodafonu se mi na telefonu hodiny nastavovaly podle GSM snad uz za Oskara.

Pro Symbian neporadím, ale čekal bych, že stejně jako pro maemo (který je ze stejný stáje) a obecně pro každý rozumny smart phone os, bude součástí kdejaký GPS aplikace i nastavení přesného času přímo ze satelitů.
Když už se s ním pří non_asisted gps výpočtech stejně musí pracovat, proč jej přímo onboard nevyužít i k přesnému nastavení času systému.
N900 a maemo: není problém si pustit ntp klienta či daemona, ale nestálo mi to zato, když si to umí oblíznout (třeba pomocí app GPS recorder) čas přímo ze satelitů kdykoliv použiju gpsku telefonu.

čas - je miraž, zkacuje se v moment štestí, a roztahuje se když se trápime

Koukám, že se v článku docela pěkně pomotaly stratum servery. Pro pořádek GPS přijímač není stratum 0 ale stratum 1. Stratum 0 jsou hodiny, které létají v té pixle na obloze. Pěkně je to vyobrazeno u tohoto článku na Wikipedii http://en.wikipedia.org/wiki/Network_Time_Protocol . Ostatně i výrobci GPS NTP serverů se k tomu hrdě hlásí viz. http://www.timetools.co.uk/products/s5500-dual-ntp-server.htm .
Pokud si někdo chce takový NTP server pořídit a má strach o to, že se mu začnou hodiny rozcházet v případě ztráty signálu, tak samozřejmě tyto zařízení je možno pořídit s přesným oscilátorem, který zajistí stabilitu hodin viz link výše, nebo http://www.spectracomcorp.com/ .
Velmi zajímavé čtení o synchronizaci času nejen přes internet vydal před časem americký NIST tf.nist.gov/ge­neral/pdf/1383­.pdf

Ntpdate samozřejmě také umí šetrně posouvat hodiny. Ono především záleží na míře odchylky od zdrojového serveru. Dá se rovněž vynutit patřičným přepínačem. Pokud někdo potřebuje přesnější řízení hodin, tak musí samozřejmě zajistit častější spouštění synchronizace a ne pouze při startu systému.

Podla mna je to v clanku dobre (a konzistentne s clankom z Wikipedie na ktory odkazujes). Stratum 0 je hardverove zariadenie, povedzme GPS prijimac (ci atomove hodiny), ktoreho cas je povazovany za uplne presny (GPS prijimac si NEnastavuje cas pomocou NTP protokolu). Pocitac je pripojeny k stratum 0 zariadeniu a teda ten pocitac uz nema presny cas, je stratum 1.

u ntpq "Položka when odpočítává sekundy do dalšího měření." by melo byt ".. od posledniho mereni"
u ntpd -gxq "Je možné ale tento režim obejít a pomocí parametrů vynutit časový skok" parametr x naopak potlaci casovy skok, pokud je rozdil casu mensi nez 600s
v defaultni konfiguraci ntpd nemeni odchylku vetsi nez 1000s (lze nastavit v ntpd.conf parametrem 'panic'), odchylka vetsi nez 128ms se meni skokove (lze nastavit v ntp.conf parametrem 'step') a mensi rozdil se dorovna plynule (0.5ms za s)

Používáte někdo v 32bit Ubuntu (Gnome panel) u výchozích hodin zobrazení vteřinovky? Jak se Vám to chová? Ty vteřiny tam někdy celkem plavou, nenaskakují v pravidelných intervalech a některé to dokonce úplně vynechává ... na stroji neběží nic co by jej vytěžovalo natolik, aby nezvládnul vteřinovku bezproblémově vykreslovat, už jsem si toho všimnul na více strojích...