Nazwa

ntpd – demon Network Time Protocol (NTP)

Synopsis

ntpd ]

Opis

Program ntpd jest demonem systemu operacyjnego, który ustawia i utrzymuje systemowy czas dnia w synchronizacji z internetowymi standardowymi serwerami czasu. Jest kompletną implementacją Network Time Protocol (NTP) w wersji 4, ale zachowuje także kompatybilność z wersją 3, zdefiniowaną przez RFC-1305, oraz wersjami 1 i 2, zdefiniowanymi odpowiednio przez RFC-1059 i RFC-1119. ntpd wykonuje większość obliczeń w 64-bitowej arytmetyce zmiennoprzecinkowej i wykonuje stosunkowo niezgrabne 64-bitowe operacje stałoprzecinkowe tylko wtedy, gdy jest to konieczne do zachowania ostatecznej precyzji, około 232 pikosekund. Podczas gdy najwyższa precyzja nie jest osiągalna w zwykłych stacjach roboczych i sieciach dzisiejszych czasów, może być wymagana przy przyszłych gigahertzowych zegarach CPU i gigabitowych sieciach LAN.

Jak działa Ntp

Program ntpd działa poprzez wymianę wiadomości z jednym lub więcej skonfigurowanymi serwerami w wyznaczonych odstępach czasu. Po uruchomieniu, czy to po raz pierwszy, czy kolejny, program wymaga kilku wymian z większości tych serwerów, aby algorytmy przetwarzania sygnału i łagodzenia mogły gromadzić i przetwarzać dane oraz ustawiać zegar. W celu ochrony sieci przed wybuchami, interwał początkowego sondowania dla każdego serwera jest opóźniony o interwał losowany w ciągu kilku sekund. Przy domyślnym interwale 64s, może upłynąć kilka minut zanim zegar zostanie ustawiony. Początkowe opóźnienie ustawiania zegara można zmniejszyć za pomocą słowa kluczowego iburst w poleceniu konfiguracji serwera, jak opisano na stronie Opcje konfiguracji.

Większość systemów operacyjnych i współczesnego sprzętu zawiera układ czasu rocznego (TOY) do utrzymywania czasu w okresach, gdy zasilanie jest wyłączone. Po uruchomieniu maszyny układ ten jest używany do inicjalizacji czasu systemu operacyjnego. Po zsynchronizowaniu się maszyny z serwerem NTP, system operacyjny co pewien czas koryguje układ. Jeśli nie ma układu TOY lub z jakiegoś powodu jego czas różni się o więcej niż 1000s od czasu serwera, ntpd zakłada, że coś jest strasznie nie tak i jedynym wiarygodnym działaniem jest interwencja operatora i ręczne ustawienie zegara. Powoduje to, że ntpd kończy pracę z komunikatem panicmessage do logu systemowego. Opcja -g unieważnia to sprawdzenie i zegar zostanie ustawiony na czas serwera niezależnie od czasu układu scalonego. Jednakże, aby zabezpieczyć się przed uszkodzonym sprzętem, takim jak bateria CMOS lub uszkodzony licznik zegara, po ustawieniu zegara, błąd większy niż 1000s spowoduje, że ntpd i tak zakończy pracę.

W zwykłych warunkach ntpd dostosowuje zegar w małych krokach, tak że skala czasu jest efektywnie ciągła i bez nieciągłości. W warunkach ekstremalnego przeciążenia sieci, jitter opóźnienia roundtrip może przekroczyć trzy sekundy, a odległość synchronizacji, która jest równa połowie opóźnienia roundtrip plus warunki budżetu błędu, może stać się bardzo duża. Algorytmy ntpd odrzucają przesunięcia próbek przekraczające 128 ms, chyba że przedział czasu, w którym żadne przesunięcie próbki nie jest mniejsze niż 128 ms nie przekracza 900s. Pierwsza próbka po tym czasie, bez względu na offset, przestawia zegar na wskazany czas. W praktyce redukuje to odsetek fałszywych alarmów, w których zegar jest błędnie ustawiony, do znikomo niskiego poziomu.

W wyniku takiego zachowania, po ustawieniu zegara, bardzo rzadko odchyla się on o więcej niż 128 ms, nawet w ekstremalnych przypadkach przeciążenia ścieżki sieciowej i jittera. Czasami, zwłaszcza gdy ntpd jest uruchamiany po raz pierwszy, błąd może przekroczyć 128 ms. Może to czasami spowodować, że zegar zostanie ustawiony wstecz, jeśli czas lokalnego zegara jest więcej niż 128 sekund w przyszłości w stosunku do serwera. W niektórych aplikacjach takie zachowanie może być nie do zaakceptowania. Jeśli w wierszu poleceń znajduje się opcja -x, zegar nigdy nie będzie krokowy i będą używane tylko poprawki slew.

Przed podjęciem decyzji o użyciu opcji -x należy dokładnie przeanalizować te kwestie. Maksymalny możliwy slew rate jest ograniczony do 500 parts-per-million(PPM) jako konsekwencja zasad poprawności, na których opiera się protokół NTP i projekt algorytmu. W rezultacie zegar lokalny może potrzebować dużo czasu, aby zrównać się do akceptowalnego offsetu, około 2000 s na każdą sekundę, w której zegar znajduje się poza akceptowalnym zakresem. Podczas tego okresu zegar lokalny nie będzie spójny z żadnym innym zegarem sieciowym i system nie może być używany w aplikacjach rozproszonych, które wymagają prawidłowo zsynchronizowanego czasu sieciowego.

Pomimo powyższych środków ostrożności, czasami, gdy występują duże błędy częstotliwości, wynikowe przesunięcia czasowe wykraczają poza zakres 128 ms i wymagana jest korekta kroku lub czasu obrotu. Jeśli po takiej korekcie błąd częstotliwości jest tak duży, że pierwsza próbka jest poza dopuszczalnym zakresem, ntpd wchodzi w taki sam stan jak wtedy, gdy plik ntp.drift nie jest obecny. Intencją tego zachowania jest szybkie skorygowanie częstotliwości i przywrócenie normalnego trybu śledzenia. W najbardziej ekstremalnych przypadkach (time.ien.it przychodzi na myśl), mogą wystąpić sporadyczne korekty step/slew i kolejne korekty częstotliwości. W takich przypadkach pomaga użycie słowa kluczowego burst podczas konfigurowania serwera.

Dyscyplina częstotliwości

Zachowanie ntpd podczas uruchamiania zależy od tego, czy istnieje plik częstotliwości, zwykle ntp.drift. Plik ten zawiera najnowsze oszacowanie błędu częstotliwości zegara. Gdy ntpd jest uruchamiany i plik ten nie istnieje, ntpd wchodzi w specjalny tryb zaprojektowany do szybkiego przystosowania się do błędu czasu i częstotliwości oscylatora zegara konkretnego systemu. Trwa to około 15 minut, po czym czas i częstotliwość są ustawiane na wartości nominalne i ntpd przechodzi w tryb normalny, w którym czas i częstotliwość są stale śledzone względem serwera. Po jednej godzinie tworzony jest plik częstotliwości, do którego zapisywany jest aktualny offset częstotliwości. Gdy ntpd jest uruchamiane, a plik istnieje, częstotliwość ntpd jest inicjalizowana z pliku i natychmiast przechodzi w tryb normalny. Następnie bieżący offset częstotliwości jest zapisywany do pliku w odstępach godzinnych.

Tryby pracy

ntpd może działać w dowolnym z kilku trybów, w tym symetrycznym aktywnym/pasywnym, klient/serwer broadcast/multicast i manycast, jak opisano na stronie Zarządzanie stowarzyszeniami. Zazwyczaj działa on w sposób ciągły, monitorując niewielkie zmiany częstotliwości i przycinając zegar w celu uzyskania najwyższej precyzji. Może jednak działać w trybie jednorazowym, w którym czas jest ustawiany z zewnętrznego serwera, a częstotliwość jest ustawiana z wcześniej zapisanego pliku częstotliwości. Klient broadcast/multicast lub manycast może wykrywać zdalne serwery, obliczać współczynniki korekcji opóźnienia propagacji między serwerem a klientem i konfigurować się automatycznie. Umożliwia to wdrożenie floty stacji roboczych bez określania szczegółów konfiguracji specyficznych dla lokalnego środowiska.

Domyślnie ntpd działa w trybie ciągłym, w którym każdy z ewentualnie kilku zewnętrznych serwerów jest odpytywany w odstępach czasu określonych przez skomplikowaną maszynę stanów. Maszyna stanów mierzy przypadkowe opóźnienie roundtrip jitter oraz wahania częstotliwości oscylatora i określa najlepszy interwał odpytywania używając algorytmu aheurystycznego. Zazwyczaj, w większości środowisk operacyjnych, maszyna stanów rozpocznie od 64s interwałów i ostatecznie zwiększy je do 1024s. Niewielka ilość losowej zmienności jest wprowadzona w celu uniknięcia zgrupowania na serwerach. Dodatkowo, jeśli serwer stanie się nieosiągalny przez jakiś czas, interwałpoll jest zwiększany w krokach do 1024s, aby zmniejszyć obciążenie sieci.

W niektórych przypadkach może nie być praktyczne, aby ntpd działał w sposób ciągły. Powszechnym obejściem jest uruchamianie programu ntpdate z cronjob o wyznaczonych porach. Jednakże, program ten nie posiada spreparowanych algorytmów przetwarzania sygnału, sprawdzania błędów i łagodzenia ich jak ntpd Opcja-q jest przeznaczona do tego celu. Ustawienie tej opcji spowoduje, że ntpd zakończy pracę zaraz po ustawieniu zegara po raz pierwszy na skonfigurowanych serwerach. Procedura wstępnego ustawiania zegara jest taka sama jak w trybie ciągłym; większość aplikacji prawdopodobnie będzie chciała podać słowo kluczoweiburst w poleceniu konfiguracji serwera. Przy tym słowie kluczowym wymieniana jest seria komunikatów w celu zagajenia danych, a zegar jest ustawiany w czasie około 10 s. Jeśli po kilku minutach nic nie słychać, demon kończy pracę i wychodzi. Po odpowiednim okresie żałoby, program ntpdate może zostać wycofany.

Gdy dostępne jest wsparcie jądra dla dyscyplinowania częstotliwości zegara, co ma miejsce w przypadku Solarisa, Tru64, Linuksa i FreeBSD, dostępna jest użyteczna funkcja dyscyplinowania częstotliwości zegara. Po pierwsze, ntpd jest uruchamiany w trybie ciągłym z wybranymi serwerami w celu zmierzenia i zarejestrowania wewnętrznego przesunięcia częstotliwości zegara w pliku częstotliwości. Może to zająć kilka godzin, aby częstotliwość i offset się ustabilizowały. Następnie ntpd jest zatrzymywany i uruchamiany w trybie jednorazowym w zależności od potrzeb. Przy każdym uruchomieniu częstotliwość jest odczytywana z pliku i inicjalizuje częstotliwość jądra.

Poll Interval Control

Ta wersja NTP zawiera skomplikowaną maszynę stanów, aby zmniejszyć obciążenie sieci przy zachowaniu jakości synchronizacji zgodnej z obserwowanym jitterem i wędrowaniem. Istnieje wiele sposobów na dostosowanie operacji w celu zwiększenia dokładności poprzez zmniejszenie interwału lub zmniejszenie obciążenia sieci poprzez jego zwiększenie. Jednakże, użytkownikowi zaleca się uważne rozważenie konsekwencji zmiany zakresu regulacji pollingu od domyślnego minimum 64 s do domyślnego maksimum 1,024 s. Domyślne minimum może być zmienione poleceniem tinker minpoll na wartość nie mniejszą niż 16 s. Ta wartość jest używana dla wszystkich skonfigurowanych asocjacji, chyba że zostanie zastąpiona opcją minpoll w poleceniu konfiguracyjnym. Zauważ, że większość sterowników urządzeń nie będzie działać poprawnie, jeśli interwał pollingu jest mniejszy niż 64 s i że serwer broadcast oraz stowarzyszenia klientów manycast będą również używać wartości domyślnej, chyba że zostanie ona zmieniona.

W niektórych przypadkach obejmujących usługi dial up lub płatne, może być użyteczne zwiększenie minimalnego interwału do kilkudziesięciu minut i maksymalnego interwału do jednego dnia lub więcej. W normalnych warunkach pracy, gdy pętla dyscypliny zegara ustabilizuje się, interwał będzie zwiększany w krokach od minimum do maksimum. Zakłada to jednak, że wewnętrzny błąd częstotliwości zegara jest wystarczająco mały, aby pętla dyscyplinująca mogła go skorygować. Zakres przechwytywania pętli wynosi 500 PPM przy odstępie 64s i zmniejsza się o współczynnik dwa przy każdym podwojeniu odstępu. Na przykład, przy minimum 1024 s, zakres przechwytywania wynosi tylko 31 PPM. Jeśli błąd wewnętrzny jest większy niż ten, plik dryftu ntp.drift będzie musiał być specjalnie dostosowany, aby zredukować błąd resztkowy poniżej tego limitu.Gdy to zostanie zrobione, plik dryfu jest automatycznie uaktualniany raz na godzinę i jest dostępny do inicjalizacji częstotliwości przy kolejnych restartach demona.

Filtr Huff-n’-puff

W scenariuszach, w których znaczna ilość danych ma być pobierana lub wysyłana przez modemy telefoniczne, jakość pomiaru czasu może być poważnie pogorszona. Dzieje się tak, ponieważ opóźnienia różnicowe na dwóch kierunkach transmisji mogą być dość duże. W wielu przypadkach pozorne błędy czasu są tak duże, że przekraczają próg kroku, a korekcja kroku może wystąpić w trakcie i po zakończeniu przesyłania danych.

Filtr huff-n’-puff jest przeznaczony do korygowania pozornego przesunięcia czasu w takich przypadkach. Zależy on od wiedzy o opóźnieniu propagacji, gdy nie ma innego ruchu. W typowych scenariuszach występuje to w godzinach innych niż praca. Filtr utrzymuje rejestr przesuwający, który pamięta minimalne opóźnienie w ostatnim przedziale czasu mierzonym zwykle w godzinach. W warunkach dużego opóźnienia filtr koryguje pozorne przesunięcie, wykorzystując znak przesunięcia i różnicę między pozornym opóźnieniem a minimalnym opóźnieniem. Nazwa filtra odzwierciedla ujemną (huff) lub dodatnią (puff) korektę, która zależy od znaku przesunięcia.

Filtr jest aktywowany przez polecenie tinker i słowo kluczowe huffpuff, jak opisano na stronie Miscellaneous Options.

Notes

Jeśli obsługa NetInfo jest wbudowana w ntpd, ntpd będzie próbował odczytać swoją konfigurację z NetInfo, jeśli domyślny plik ntp.conf nie może być odczytany i żaden plik nie jest określony przez opcję -c.

W kontekstach, gdzie oczekiwana jest nazwa hosta, kwalifikator -4 poprzedzający nazwę hosta wymusza rozdzielczość DNS do przestrzeni nazw IPv4, podczas gdy kwalifikator -6 wymusza rozdzielczość DNS do przestrzeni nazw IPv6.

Różne wewnętrzne zmienne ntpd mogą być wyświetlane, a opcje konfiguracyjne zmieniane podczas działania ntpd za pomocą programów narzędziowych ntpq intpdc.

Gdy ntpd startuje, patrzy na wartość umask, i jeśli wynosi ona zero, ntpd ustawi umask na 022

Bez użycia opcji -n, -d lub -D, ntpd zmienia bieżący katalog roboczy na katalog główny, więc wszelkie opcje lub polecenia określające ścieżki muszą używać ścieżki bezwzględnej lub ścieżki względnej do korzenia.

Opcje wiersza poleceń

-4 Wymuś rozdzielczość DNS nazw hostów na przestrzeń nazw IPv4. -6 Wymuś rozdzielczość DNS nazw hostów do przestrzeni nazw IPv6. -a Wymagaj uwierzytelniania kryptograficznego dla klienta rozgłoszeniowego, klienta multicastowego i symetrycznych stowarzyszeń pasywnych. Jest to ustawienie domyślne. -A Nie wymagaj uwierzytelniania kryptograficznego dla klienta rozgłoszeniowego, klienta multicastowego i symetrycznych stowarzyszeń pasywnych. To prawie nigdy nie jest dobry pomysł. -b Zezwól klientowi na synchronizację z serwerami rozgłoszeniowymi. -c conffile Określa nazwę i ścieżkę dostępu do pliku konfiguracyjnego, domyślnie /etc/ntp.conf -d Określa tryb debugowania. Opcja ta może wystąpić więcej niż raz, przy czym każde jej wystąpienie oznacza większą szczegółowość wyświetlania. -D poziom Określa bezpośrednio poziom debugowania. -f driftfile Określa nazwę i ścieżkę dostępu do pliku częstotliwości. Jest to taka sama operacja jak w przypadku polecenia konfiguracyjnego driftfile driftfile. -g Normalnie, ntpd kończy pracę z komunikatem do logu systemowego, jeśli przesunięcie przekroczy próg paniki, który domyślnie wynosi 1000 s. Opcja ta pozwala na ustawienietime na dowolną wartość bez ograniczeń; jednak może się to zdarzyć tylko raz. Jeśli po tym czasie próg zostanie przekroczony, ntpd zakończy pracę z komunikatem do logu systemowego. Opcja ta może być używana z opcjami -q i -x. Zobacz polecenie tinker dla innych opcji. -i jaildir Chrootuje serwer do katalogu jaildir Opcja ta oznacza również, że serwer próbuje pozbyć się uprawnień roota przy starcie (w przeciwnym razie, chroot daje bardzo niewielkie dodatkowe bezpieczeństwo), i jest dostępna tylko jeśli system operacyjny obsługuje uruchamianie serwera bez pełnych uprawnień roota. Możesz potrzebować również opcji -u. -I iface Listen on interface. Ta opcja może pojawić się nieograniczoną ilość razy. -k keyfile Określenie nazwy i ścieżki dostępu do pliku klucza symetrycznego. Jest to taka sama operacja jak w przypadku polecenia konfiguracyjnego keys keyfile. -l logfile Określa nazwę i ścieżkę dostępu do pliku dziennika. Domyślnie jest to plik dziennika systemowego. Jest to taka sama operacja jak polecenie logfile logfileconfiguration. -L Nie nasłuchuj wirtualnych adresów IP. Domyślnie jest to nasłuchiwanie. -m Zablokuj pamięć. -n Nie rozwidlaj. -N W zakresie dozwolonym przez system operacyjny, uruchamiaj ntpd z najwyższym priorytetem. -p pidfile Określa nazwę i ścieżkę dostępu do pliku używanego do zapisu identyfikatora procesu ntpd. Jest to ta sama operacja, co polecenie pidfile pidfileconfiguration. -P priority W zakresie dozwolonym przez system operacyjny, uruchamiaj ntpd z podanym priorytetem. -q Wyjdź z ntpd zaraz po pierwszym ustawieniu zegara. Zachowanie to naśladuje działanie programu ntpdate, który ma zostać wycofany. Z tą opcją mogą być używane opcje-g i -x. Uwaga: Z tą opcją wyłączona jest dyscyplina czasowa jądra. -r broadcastdelay Określa domyślne opóźnienie propagacji z serwera broadcast/multicast do tego klienta. Jest to konieczne tylko wtedy, gdy opóźnienie nie może być obliczane automatycznie przez protokół. -s statsdir Określa ścieżkę katalogu dla plików tworzonych przez obiekt statystyk. Jest to ta sama operacja, co polecenie konfiguracyjne statsdir statsdir. -t key Dodanie numeru klucza do listy zaufanych kluczy. Opcja ta może wystąpić więcej niż jeden raz. -u user Określenie użytkownika i opcjonalnie grupy, na którą ma nastąpić przełączenie. Opcja ta jest dostępna tylko wtedy, gdy system operacyjny pozwala na uruchomienie serwera bez pełnych uprawnień roota. Obecnie opcja ta jest obsługiwana w systemach NetBSD (konfiguracja z –enable-clockctl) i Linux (konfiguracja z –enable-linuxcaps). -U interface update interval Ilość sekund jaka ma upłynąć pomiędzy skanowaniami listy interfejsów w celu wykrycia nowych i usunięcia interfejsów sieciowych. Ustawiona na 0 wyłącza dynamiczną aktualizację listy interfejsów. Domyślnie skanowanie odbywa się co 5 minut. -v zmienna-V zmienna Dodaj zmienną systemową wymienioną domyślnie. -x Normalnie czas jest przestawiany, jeśli przesunięcie jest mniejsze niż próg kroku, który domyślnie wynosi 128 ms, a przestawiany, jeśli przekracza ten próg. Ta opcja ustawia próg na 600 s, co mieści się w oknie dokładności pozwalającym na ręczne ustawienie zegara. Uwaga: Ponieważ szybkość przesuwu typowych jąder Unixa jest ograniczona do 0.5 ms/s, każda sekunda regulacji wymaga interwału amortyzacji 2000 s. Tak więc regulacja trwająca 600 s zajmie prawie 14 dni. Zobacz polecenie tinker dla innych opcji. Uwaga: Przy tej opcji wyłączana jest dyscyplina czasowa jądra.

Plik konfiguracyjny

Zwyczajowo, ntpd czyta plik konfiguracyjny ntp.conf w czasie startu, aby określić źródła synchronizacji i tryby pracy.Możliwe jest również określenie działającej, choć ograniczonej, konfiguracji całkowicie w linii poleceń, co eliminuje potrzebę pliku konfiguracyjnego. Może to być szczególnie użyteczne, gdy lokalny host ma być skonfigurowany jako klient broadcast/multicast, z wszystkimi rówieśnikami określanymi przez nasłuchiwanie transmisji w czasie uruchamiania.

Zazwyczaj plik konfiguracyjny jest instalowany w katalogu /etc, ale może być zainstalowany gdzie indziej (zobacz opcję wiersza poleceń -c conffile). Format pliku jest podobny do innych plików konfiguracyjnych systemu Unix – komentarze zaczynają się od znaku # i ciągną się do końca linii; puste linie są ignorowane.

Komendy konfiguracyjne składają się z początkowego słowa kluczowego, po którym następuje lista argumentów, z których niektóre mogą być opcjonalne, oddzielonych białymi spacjami. Polecenia nie mogą być kontynuowane w wielu liniach. Argumentami mogą być nazwy hostów, adresy hostów zapisane w postaci liczbowej, liczby całkowite, liczby zmiennoprzecinkowe (przy podawaniu czasów w sekundach) i łańcuchy tekstowe. Argumenty opcjonalne są w poniższych opisach ograniczone przez, podczas gdy alternatywne są oddzielone przez | Notacja ta oznacza opcjonalne, nieokreślone powtórzenie ostatniego elementu przed

Kody wyjścia

Niezerowy kod wyjścia oznacza błąd. Wszelkie komunikaty o błędach są domyślnie rejestrowane w dzienniku systemowym.

Kod wyjścia wynosi 0 tylko wtedy, gdy ntpd jest zakończone przez sygnał, lub gdy użyta jest opcja -q i ntpd pomyślnie ustawia zegar systemowy.

Zobacz także

ntp.conf(5), ntpq(8), ntpdc(8)

.