Paweł Goleń, blog

Po co synchronizować czas? Choćby po to, by zdążyć na autobus :) Oczywiście w przypadku systemów informatycznych synchronizacja czasu ma inne, większe znaczenie. Powiedzmy, że ktoś włamuje się do systemu, chcesz powiązać zdarzenia, które zachodzą w różnych jego częściach (lub innych systemach), patrzysz w logi i nic nie pasuje. Okazuje się, że czas pomiedzy systemami jest rozjechany, choćby o kilka sekund, ale zawsze. W takiej sytuacji życzę powodzenia... Oczywiście, najpierw można ustalić o ile czas jest rozjechany między różnymi systemami, potem czasy w logach sprowadzić do "wspólnego mianownika", a na końcu ponownie rozpocząć analizę tak przygotowanego materiału. Tylko po co? A w dodatku co się stanie, jeśli będziesz chciał powiązać zdarzenia, które zaszły w systemach, które nie należą do Ciebie? Choćby dlatego warto jest synchronizować czas. A sprawa jest prosta, służy do tego protokół NTP. Chyba najbardziej znaną implementacją NTP jest ta pochodząca z ntp.org. Trudno zresztą się dziwić, jeśli jest to implementacja "referencyjna".

Demon ntpd daje naprawdę doskonałe wyniki synchronizacji, dobrze również "trzyma" czas jeśli z jakiegoś powodu kontakt z serwerami ntp w sieci nie jest możliwy. Implementacja ta dostępna jest na wiele systemów, w tym dla systemu Windows. Nie używam jej jednak. Od pewnego czasu dostępna jest implementacja OpenNTPD. Pod wieloma względami jest to ubogi krewny implementacji z ntp.org, ale używam właśnie tej wersji i to nie tylko dlatego, że ma fajną maskotkę. Może jestem przykładem minimalisty, ale staram się używać rozwiązań, które spełniają swoją rolę wystarczająco dobrze. Oznacza to, że nie potrzebuję najnowszej wersji oprogramowania za grube $$$, skoro istnieje coś, co zadanie to realizuje równie dobrze. Przykładowo do obróbki (czyli najczęściej zmiany rozmiaru zdjęcia) nie jest potrzebny mi Photoshop (którego 99,9% funkcji i tak nie potrafię wykorzystać), wystarcza mi Gimp. Jeśli chcę zmienić rozmiar zdjęć masowo, to piszę sobie prosty skrypt w Pythonie, który z wykorzystaniem biblioteki PIL zrobi dokładnie to, o co go poproszę. Tak wiem, jestem nienormalny.

Skoro nie wykorzystywałem większości możliwości demona z ntp.org, przesiadłem się na OpenNTPD. Dodatkowym plusem tego demona jest fakt, że od początku tworzony był z myślą o bezpieczeństwie. Choćby tak prosta rzecz jak separacja przywilejów, mała rzecz, a cieszy. Druga sprawa, z czym synchronizować. W sieci dostępnych jest sporo serwerów NTP. Na uwagę zasługuje projekt pool.ntp.org, który (bez wdawania się w szczegóły) dostarcza listę serwerów NTP dostępnych dla każdego. W konfiguracji demona ntpd (nie ważne, czy to ten z ntp.org, czy OpenNTPD) warto podać adres więcej niż jednego serwera. Demony za pomocą wbudowanych algorytmów wybierają sobie serwery najbardziej "godne zaufania" i właśnie z nimi synchronizują się. Jeśli jakiś serwer podaje czas wyraźnie inny od pozostałych, jest czasowo ignorowany i podawany przez niego czas nie jest uwzględniany przy synchronizacji. W zasadzie podanych serwerów nie powinno być mniej niż 3. Wybieranie większej liczby serwerów również nie jest do końca uzasadnione, ja zwykle korzystam z nie więcej niż 5 serwerów. Dzięki pool.ntp.org mogę wpisać po prostu adresy typu 0.pool.ntp.org, 1.pool.ntp.org, a projekt sam "podrzuca mi" odpowiednie serwery. Efekt jest taki, że zwykle zegar mojego serwera linuksowego (uwaga, serwer mroczna-zaloga.org nie jest moim serwerem) nie jest rozjechany bardziej niż o 0.15 sekundy. W przypadku wykorzystania demona z ntp.org różnica w czasie była rzędu setnych sekundy, ale w moich zastosowaniach aż taka dokładność nie była mi potrzebna. W Windows (od Windows 2000) wbudowana jest usługa Windows Timebędąca implementacją protokołu SNTP (w Windows 2000) i protokołu NTP w XP i nowszych. W przypadku, gdy komputer jest dołączony do domeny, automatycznie synchronizuje on się z kontrolerami domeny. Kontrolery domeny z kolei synchronizują się z kontrolerem pełniącym rolę emulatora PDC, ten z kolei powinien być zsynchronizowany z jakimś godnym zaufania zewnętrznym źródłem czasu. Implementacja NTP w Windows jest jednak bardziej uboga, niż w przypadku wcześniej wspominanych demonów, dlatego zawsze starałem się synchronizować PDC z jakimś serwerem linuksowym w mojej sieci, a dopiero serwer ten synchronizować z czymś na zewnątrz. Również w domu swoje komputery synchronizuję z jednym z moich linuksów. Efekt?

C:\>w32tm /stripchart /computer:pool.ntp.org /dataonly Tracking pool.ntp.org [66.115.130.4]. The current time is 2006-05-14 20:57:53 (local time). 20:57:53, -00.0250672s 20:57:56, -00.0236000s 20:57:58, -00.0222903s
    

Oczywiście, nie zawsze działa to tak dokładnie, ale zwykle różnica w czasie nie przekracza 1 sekundy. Całkiem dobry opis usługi Windows Time dostępny jest tutaj. Na uwagę zasługuje parametr NtpServer, a właściwie parametry dodawane do nazw serwerów, z którymi synchronizować ma się Windows. Standardowo jest to 0x01, co powoduje, że czas synchronizowany jest co zadany interwał określony z kolei przez wartość SpecialPoolInterval, co dla komputerów należących do domeny wynosi (standardowo) 3600 sekund, w przypadku komputerów nie należących do domeny wartość ta wynosi aż 604800 sekund (czyli 7 dni!). Ja nie używam parametru 0x01 (czyli niejawnie używam parametru 0x0), wówczas czas co jaki wykonywana jest synchronizacja dobierany jest automatycznie przez usługę Windows Time w zależności od tego, jak bardzo mój zegar jest zsynchronizowany. Wartości te kontrolowane są przez parametry MinPollInterval oraz MaxPollInterval. Niestety, tutaj prawdopodobnie uwidacznia się jakiś błąd w usłudze Windows Time, czas co jaki jest próbkowany zegar zewnętrzny rośnie zgodnie z przewidywaniami od wartości MinPollInterval do MaxPollInterval, po czym pojawia się błąd:

Event Type: Warning Event 
Source: W32Time 
Event Category: None 
Event ID: 36 
Date: 2006-05-14 
Time: 13:36:38 
User: N/A 
Computer: SHREK 
Description: The time service has not been able to synchronize 
the system time for 1536 seconds because none of the time providers
has been able to provide a usable time stamp. The system clock is unsynchronized.

Oczywiście, nie muszę dodawać, że po pierwsze usable time stamp jest cały czas dostarczany, a po drugie stwierdzenie, że system clock is unsynchronized nie jest zgodne z prawdą. No ale trudno, myślę, że można z tym jakoś żyć.