Windows NTP kliens nem jó

Microsoft Windows

Van egy Windows 10 Professional Hu oprendszerem. Be van rajta állítva az NTP kliens. Alább látható a beállítása:

https://imgur.com/a/uIYNLop

Ez a gép dual boot-os, néha Linux-ot néha Windows-t indítok róla. A Linux feltételezhetően UTC-re állítja a rendszeridőt. Ezt azért gondolom, mert ha linux után windows-t boot-olok, akkor egy órát késik az óra. Ez önmagában még érthető lenne. Ami nem érthető az az, hogy miért nem szinkronizál? A képernyőképen látszódik, hogy ma február 8 van. És bár az NTP kliens be van kapcsolva, de valójában még sincs. Azt írja, hogy a legutóbbi sikeres szinkronizálás február negyedikén volt.

Szóval be van kapcsolva, de mivel 4 napja nem futott, ezért igazából nincs is.

Az időzónát már manuálisra állítottam, nehogy ez legyen a baj. De így is rossz. Egyértelműen az a baj, hogy nem szinkronizál.

Érdekes módon ha ki- és bekapcsolom a szinkronizálást, akkor 1 másodpercen belül jól beállítja az órát. De magától nem. (Vagy lehet hogy egy hét múlva megcsinálná, de nyilván azt még nem vártam ki.)

Az a legrosszabb az egészben, hogy van egy csomó program amit fejlesztek. Ezek olyan API-kat hívogatnak, amikben az üzenetek időbélyeget is tartalmazó HMAC aláírásokat tartalmaznak. Egy ilyen reboot után egyik se működik, mert az időbélyegek egy órával a múltba kerülnek.

Szóval a kérdések:

* ha be van kapcsolva, akkor miért nem csinál semmit?

* ha ki és bekapcsolom, akkor miért igen?

* hogyan lehetne rávenni arra, hogy legalább system reboot után egyszer szinkronizáljon? (login script-tel esetleg? de pontosan hogy?)

  • 836 megtekintés

( kisbetu v | 2020. 02. 08., szo – 11:41 )

Szerkesztve: 2020. 02. 08., szo – 11:42

"* ha be van kapcsolva, akkor miért nem csinál semmit?"

Milyen időközönként kell szinkronizálnia? Mire van állítva?

Hiszen működik: az azonnali szinkronizálást megcsinálja.

"Normális ember már nem kommentel sehol." (c) Poli

Az én értelmezésem szerint, ha elindítom a gépet és hat napon keresztül egy órát késik, akkor az egyenértékű azzal, hogy nem működik. Próbálhatjuk szépítgetni a dolgot, de egy fizetős (állítólag) felhasználó barát oprendszernél nehogy már kézzel kelljen NTP klienst konfigurálnom. Basszus, nem is tudnék mondani olyan eszközt amiben ez alapból rosszul működik. Kivéve persze ezt.

( mauzi v | 2020. 02. 08., szo – 12:04 )

Szerkesztve: 2020. 02. 08., szo – 12:14

Egyrészt, meg lehet próbálni a Windows-t is helyi idő helyett UTC órával használni, én több éve (és több Windows kiadással ezelőtt) próbáltam utoljára, akkor még eléggé experimental volt, de ma már lehet, hogy megfelelően működik:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=dword:00000001

* ha be van kapcsolva, akkor miért nem csinál semmit?

Csinál az, csak baromi ritkán. Az NTP kliens szinkronizálási intervalluma emlékeim szerint alapból 1 hét, én speciel át szoktam állítani 1 órára (3600 sec):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpClient]
"SpecialPollInterval"=dword:00000e10

* hogyan lehetne rávenni arra, hogy legalább system reboot után egyszer szinkronizáljon?

Én login script helyett inkább bootkor lefutó ütemezett feladatot csinálnék. A google első találata alapján, az alábbi parancsot kellhet beütemezni (nem teszteltem):

W32tm /resync /force

( agostonl | 2020. 02. 08., szo – 12:19 )

Ezt olvasd el!

 

https://superuser.com/questions/451018/how-can-i-query-an-ntp-server-under-windows/451066

 

Esetleg a tűzfal nem szólhat bele?

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

( nagylzs v | 2020. 02. 08., szo – 14:29 )

Köszönöm a válaszokat. Ha az alap sync intervallum 1 hét, akkor ez úgy szar ahogy van. Ehhez jön még az, hogy legalább boot-kor szinkronizálna magától, de azt se. Ez az egy hét szinte teljesen értelmetlenné teszi az egész NTP klienst. Kíváncsi vagyok hogy aki ezt kitalálta, az miféle ideológiát talált ki hozzá?

Érdekes, hogy Linux alatt meg  tudták csinálni az alap beállítást jóra. De nem baj, ez jobb mert ez pénzbe került. Kicsit emlékeztet a notepad-ra   meg a Windows környezeti változó szerkesztő ablakára. Ez utóbbi legalább 10 éven keresztül rossz volt (átméretezni még mindig nem lehet), de szegény redmondiaknak nem volt pénzük kijavítani. Biztos kellett a pénz a csempés start menüre meg az internet Explorer fejlesztésére.

Most telefonról vagyok, de ha hazaértem kipróbálom amit írtatok.

De hat a kollegak itt jol megmondtak, hogy a Windows 10 jo /a legjobb/, mert nem kell reszelni. Soha. Ilyen esetben sem.

Guggelezni se kell miatta. Mert do'gozunk vele, vannak csempek meg Minecraft ajanlo (az fontos), meg csendes reboot a hatizsakban. Produktivitas van, nincs ido reszelni. Oh wait bro...

(Bocs az off-ert.)

echo crash > /dev/kmem

Nem is kellene reszelni, ha nem lenne mellette egy Linux, ami folyton átállítja az órát. A Linuxban is ugyanígy megadhatod, hogy ne UTC-t használjon, akkor a Windowsban nem kell állítani semmit.

Egyszerűen két rendszer eltérő beállítása miatt van ez a probléma. És ez nem most keletkezett, ezer éve megkérdezik linuxok és bsdk is telepítéskor, hogy mi szerint jár az óra. Csodálkozom, hogy csak most találkoztál vele.

Én pedig úgy gondolom, hogy aki dual bootban futtat Linuxot, annak kell lennie annyi eszének, hogy ismeri és meg tudja oldani ezt a problémát. Tekintve hogy ezer éve létezik, valamint bsdk és linuxok között is ugyanúgy előfordulhat mindenféle Windows nélkül. Mégis honnan tudná a Windows, hogy mikor ő nem fut, akkor egy "manó" átállítja az RTC-t? Főleg hogy valójában ma már ki sem kapcsol teljesen (hibrid alvás). Szerinted az lenne a jó megoldás, hogy NTP-vel "harcoljanak" és állítgassák egymás óráját, ahelyett hogy jó beállítást kapnának? Aztán a logoknak / fájloknak rossz timestampje lesz addig, amíg NTP nem szinkronizál + fájlrendszert feleslegesen ellenőrizze minden indításkor helytelen idő miatt (ilyet is láttam már).

Érdekes olvasmány: https://wiki.archlinux.org/index.php/System_time

És ez is:

UTC in Ubuntu

Ubuntu and its derivatives have the hardware clock set to be interpreted as in "localtime" if Windows was detected on any disk during Ubuntu installation. This is apparently done deliberately to allow new Linux users to try out Ubuntu on their Windows computers without editing the registry.

> A Linuxban is ugyanígy megadhatod, hogy ne UTC-t használjon
Miert ne lehetne a Linux UTC, a Windows meg CET? Miert ne hasznalnal 2 kulonbozo idozonat, ha arra van igeny?

> NTP-vel "harcoljanak" és állítgassák egymás óráját
Miert ne? Ha ez egy jo megoldas. Bootkor lefut, utana idonkent szinten lefut.

A kollega irta:
> Érdekes módon ha ki- és bekapcsolom a szinkronizálást, akkor 1 másodpercen belül jól beállítja az órát.
Ott lenne a megoldas Win10 oldalon. Meg tudja csinalni. Csak automatikusan nem akarja.

echo crash > /dev/kmem

Ez nem megoldás, hanem workaround.

Ez olyan mintha csak egy autónk lenne feleségemmel és nem tudnánk megállapodni, hogy autóban UTC vagy helyi időt mutasson az óra. Aztán mikor beszállunk az autóba, akkor mindig meg kellene néznünk az időt egy weblapon vagy felhívni pontos időt, majd a szerint átállítani az órát attól függően, hogy ki vezet. Nagyon jó megoldás, ahelyett hogy megállapodnánk vagy UTC-ben vagy helyi időben..

Azt kellene megérteni, hogy van egy tárolt és egy megjelenített idő, a kettő pedig nem feltétlenül kell, hogy ugyanazt az időzónát használja. A Windows hagyományosan az RTC-t helyi időként kezeli, vagyis a tárolt és a megjelenített idő időzónája megegyezik. A Linuxod ettől eltérően az RTC-t UTC-ként kezeli, a megjelenített időt ebből a helyi időzóna ismeretében számolja. Mivel az RTC nem tárol időzóna információt, a két rendszer nem tud automatikusan megegyezni a tárolt idő időzónájában, ebből ered a problémád. A megoldás az, hogy az egyik rendszert átállítod, hogy az RTC-t ugyanúgy kezeljék. Az ettől független, hogy a két rendszer milyen időzónában jeleníti meg az időt, ha épp ahhoz van kedved ez a két időzóna akár el is térhet.

Pl. ha UTC szerint 12:34:56 van, a helyi időzóna CET (UTC+1) és mindezt PST-ben (UTC-8) szeretnéd megjeleníteni:

RTC időzóna RTC idő PST - RTC PST idő
CET 13:34:56 -09:00:00 04:34:56
UTC 12:34:56 -08:00:00 04:34:56

Régebben én is belefutottam ebbe. Már nem emlékszem melyik rendszert állítottam át, de működött. Pont azt a postot nem találtam meg, de ubuntu.hu-n keresve az "egy órát"* kulcsszóra kb a második oldalon részletes magyarázat van a kommentek között a mindenre is,  még egy olyan noob-nak is, mint én vagyok.

*téli-nyári átállás miatt vagy 1, vagy 2 óra a probléma tárgya. Amit én találtam, az egy órás, Júniusi. :)

"A fejlesztők és a Jóisten versenyben vannak. Az előbbiek egyre hülyebiztosabb szerkezeteket csinálnak, a Jóisten meg egyre hülyébb embereket. És hát a Jóisten áll nyerésre." By:nalaca001 valahol máshol

Sose fulld trollba a kretént.

( nagylzs v | 2020. 02. 09., v – 08:48 )

Na kipróbáltam a registrity beállítást, önmagában a két bejegyzés módosítása semmit nem csinált vele. Most újraindítom, hátha attól megjavul.

( nagylzs v | 2020. 02. 09., v – 08:54 )

Újraindítástól megjavult annyira, hogy elkezdte UTC-ként értelmezni az alaplapi RTC idejét. Szóval újraindítás után már a jó időpontot látom. De a frissítést így se hajlandó megcsinálni. Még mindig azt írja ki, hogy utoljára feb. 4-én frissítette.

Azt is felháborítónak tartom, hogy nincsen a felületen lehetőség megadni saját ntp szervert. Ha visszamegyek a régi control panel-be (ami még Windows 7-es típusú) akkor ott van, de az új Win 10-esben nincsen. Ezt is elrontották (többek között). Szerintem tisztában is vannak vele, máskülönben nem hagyták volna meg az összes régi admin felületet. Az újak kivétel nélkül roszabbak.

Marad a TimeSyncTool, és köszönöm a tippet!

Az MS meg bekaphatja.

( Raynes v | 2020. 02. 09., v – 19:21 )

Windows esetén registry hack kell, hogy a gép hardveres óráját UTC-ben tárolja. Default helyi időben tárolja. A Linux meg mindenképpen UTC-be, és abból még átszámítja a helyi időt. És sajnos linuxxxxéknak van igaza, ebben is, mert a fájlrendszereknél is az az elfogadott, hogy UTC-ban vannak a dátumok. Azért, hogy ha valaki időzónákon repül át, akkor ne az legyen, hogy egy később mentett, újabb verziós doksi régebbinek látszódik, mint a valójában régebbi verzió. Meg a gép hardveres óráját sem kell így oda-vissza állítgatni, nem esik ki idő.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( Zsugabubus | 2020. 02. 10., h – 11:22 )

Eleve az NTP megbaszása, hogy időkönként szinkronizál(na). NTP-nek az lenne a lényege, hogy a kezdeti sync után szépen kövesse az időt, úgy, hogy sose haladjon visszafelé. Ez ilyen cronban ntpdate-t hívunk.

A cron is időközönként fut le és időközönként szinkronizál.
Szerintem nem ismered az NTP protokollban lévő "polling interval" fogalmát.

"NTP-nek az lenne a lényege, hogy a kezdeti sync után szépen kövesse az időt,"

Az idő követése pedig micsoda? Sync.

"úgy, hogy sose haladjon visszafelé."

Nem lehetséges megoldani, ha az órád siet.

 

Szerintem te nem érted, hogyan működik az NTP.

Szerintem én értem:

As the result of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path congestion and jitter. Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on occasion cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the -x option is included on the command line, the clock will never be stepped and only slew corrections will be used.

 

Nagyon ritka esetben lépteti vissza az órát, de még ez is megtiltható. Semmiképpen sem azonos egy "tegyünk ntpdatet cronba" megoldással. Ugye a sync nem feltétlenül azt jelenti, hogy na állítsuk azonosra az órákat, hanem a helyi időt lehet siettetni vagy késleltetni némileg, hogy utolérjék egymást.

 

Ha az "órád siet"-nél az RTC-re gondolsz, annak meg semmi szerepe az OS idejében, legfeljebb ha bootnál (vagy hwclock-kal) rászinkronizál.

Nézd meg, mire való a g kapcsoló az ntpd-ben.

Ha egy okos előreállította több, mint 1000 másodperccel az időt, akkor az NTP szabvány szerint (mivel több, mint 1000 másodperc különbség van), PANIC az állapot, és NTP-vel nem lehet időt állítani.

Az NTPd implementációja olyan, hogy 1000 másodpercnél meg is kér arra, hogy légyszíves, állítsd át kézzel az időt, és utána ő tud dolgozni már, vagy ha megadod neki a -g kapcsolót, akkor ő fog kézzel nagyot állítani rajta.

Szóval van olyan eset, amikor visszafelé KELL állítani az időt, és az Ubuntu/Windows UTC/helyi idő szerinti RTC tipikusan ez az eset, akármennyire is gondoljuk azt, hogy az NTP majd megoldja ezt. Nem oldja meg, le is van írva a szabványban, hogy mikor nem. 

https://tools.ietf.org/html/rfc5905#section-11.3

The process terminates immediately if the offset is greater than the
   panic threshold PANICT (1000 s).

Tudom, hogy van ilyen kapcsoló, és azt is tudom, hogy mire szolgál - ha nagy az eltérés bármeylik irányba, akkor én az ntpd-t leállítom, ntpdate-tel helyrehúzom az órát, és utána bízom az ntpd-re a dolgot. Aztán ha mégis elmászna,a kkor a monitoringmajd szól, hogy nincs ntpd és/vagy a gép órája nagyon eltér az ntp-szerverétől.

Ja, és ha ilyen méretes eltérés van, akkor annak az okát is célszerű megkeresni.

( bennyh | 2020. 02. 11., k – 05:46 )

Na pont ezért használtam a fentebb linkelt NetTime-ot hibás RTC-s AD tag gépen, mert valami 30 évig fel lehet benne tolni a küszöböt és szolgáltatásként már a login előtt belőtte az órát.