Dlaczego ntpd nie aktualizuje czasu na moim serwerze?

Mam NTTP na moim serwerze. To są wszystkie ustawienia domyślne, z wyjątkiem tego, że skomentowałem jego zdolność do bycia serwerem na innych komputerach:

# restrict -4 default kod notrap nomodify nopeer noquery                                                                    
# restrict -6 default kod notrap nomodify nopeer noquery   
restrict default ignore

Jeśli uruchomię ntpdate -q ntp.ubuntu.com, powiedzą mi, że zegar mojej maszyny jest wyłączony o 7 sekund.

Co się dzieje? Jak zdiagnozować, co się dzieje, czy mogę włączyć dziennik?

więcej informacji # 1

# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 91.189.94.4     193.79.237.14    2 u   30   64    7  108.518   -0.136   0.361

więcej informacji # 2

Oto jak to wyglądało, kiedy zadałem pytanie:

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 7.191308, delay 0.13310
10 Jan 20:38:09 ntpdate[31055]: step time server 91.189.94.4 offset 7.191308 sec

A oto, jak wygląda teraz, po ponownym uruchomieniu ntpd kilka razy (zakładam, że to właśnie to naprawiło):

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 0.000112, delay 0.13164
10 Jan 20:47:03 ntpdate[31419]: adjust time server 91.189.94.4 offset 0.000112 sec

więcej informacji # 3

Odinstalowałem ntp, zainstalowałem openntpd i uruchomiłem /usr/sbin/ntpd -d, i widzę takie dane wyjściowe:

reply from 64.73.32.134: offset 6.715003 delay 0.041152, next query 30s
reply from 208.53.158.34: offset 6.700224 delay 0.036263, next query 31s
adjusting local clock by 6.734120s
reply from 72.18.205.156: offset 6.708575 delay 0.035885, next query 30s
reply from 64.73.32.134: offset 6.701463 delay 0.044199, next query 33s

Co dla mnie dość wyraźnie wskazuje, że nie jestem w stanie ustawić czasu na moim serwerze (chociaż przy zwykłym ntp czasami wydaje się aktualizować ...).

więcej informacji # 4

Mój dostawca VPS mówi:

Najnowsze jądra nie powinny blokować twojego systemu na zegarze dom0, aby być bezpiecznym, możesz ustawić xen.independent_wallclock = 1 w swoim sysctl.conf.

Co, jak sądzę, nadal nie rozwiązuje problemu VPS wymagającego dostępnego procesora, aby wykonać prawidłowe obliczenia czasowe.

Możesz włączyć logowanie ntpd, dodając to do ntp.conf:

logfile /var/log/ntpd.log

Źródło: instrukcja ntp

Jeśli wyłączysz ntpd, czy możesz zaktualizować zegar za pomocą wiersza poleceń? Jeśli uruchomisz polecenie ntpdate i otrzymasz taki błąd:

# ntpdate ntp.ubuntu.com
10 Jan 23:47:57 ntpdate[26284]: Can't adjust the time of day: Operation not permitted

Oznacza to, że prawdopodobnie korzystasz z VPS iw takim przypadku nie możesz modyfikować zegara systemowego - można to zrobić tylko na komputerze hosta.

Dobra ludzie, odkąd zadałem to pytanie, ponownie zainstalowałem NTTP z domyślną konfiguracją dostawcy (Ubuntu 10.0.4) i pozwól mi działać przez kilka dni. W chwili pisania tego tekstu ntpdate -q ntp.ubuntu.compokazuje, że mój czas jest dokładny w granicach 0,000216 sekund. Więc problemy, które miałem, musiały być z moją dostosowaną konfiguracją (gdzie próbowałem uniemożliwić zewnętrznym hostom wysłanie zapytania do mojego serwera, co już robię z moją zaporą, więc nie martwię się zbytnio). Oto Ubuntu 10.0.4 ntp.conf w całości, z usuniętymi komentarzami:

driftfile /var/lib/ntp/ntp.drift

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server ntp.ubuntu.com

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

restrict 127.0.0.1
restrict ::1

Czekam na opinie na temat tego, jak można poprawić tę konfigurację.

Zrobiłem również bilet z moim dostawcą VPS, prosząc go o szczegółową rekomendację dotyczącą najlepszych rzeczy do zrobienia. Wskazałem je na ten wątek i kilka innych dokumentów wskazujących, że być może przydzielenie procesora spowodowałoby problem z taktowaniem. Oto, co powiedzieli:

Najnowsze jądra nie powinny blokować twojego systemu na zegarze dom0, aby być bezpiecznym, możesz ustawić xen.independent_wallclock = 1 w swoim sysctl.conf. Dzięki temu instancja serwera nie będzie podążać za zegarem na serwerze hosta.

i:

Myślę, że źle rozumiesz, w jakim stopniu ten problem wpływa na klientów NTP w zwirtualizowanym środowisku. Z mojego doświadczenia na zwirtualizowanym systemie na hoście Xen (takim jak nasza konfiguracja w Rackspace Cloud), niedokładność odziedziczona przez brak dedykowanego zegara systemowego do przetwarzania przerwań wynosi ułamki sekundy, nawet w przypadku bardzo obciążonych systemów. Ta niewielka niedokładność jest łatwo zarządzana przez NTP, nawet jeśli jest ustawiona tylko na aktualizację serwerów raz dziennie (lub nawet rzadziej).

Jeden z twoich komentarzy mówi, że korzystasz z vhosta. W tym przypadku prawdopodobnie nie odniesiesz większego sukcesu, ponieważ poczucie czasu twojego vhosta będzie zależało zarówno od prawdziwego hosta, na którym działa, jak i od ogólnego obciążenia hosta.

W zależności od zastosowanej wirtualizacji vhost może nie uzyskać stałego udziału przerwań w danym okresie czasu. Dzięki temu zegar będzie działał szybciej lub wolniej niż w rzeczywistości. Ponieważ ntp próbuje zmierzyć zmiany przy założeniu, że twój zegar jest o stałej częstotliwości szybszy lub wolniejszy niż reszta świata, to przyspieszenie i spowolnienie da pasujące ntp i prawdopodobnie ostatecznie po prostu się podda, z wynikiem który ntp -nppokazuje serwery czasu, które ntp uznało za nieodpowiednie.

Najlepszym rozwiązaniem, jeśli tak jest, jest prawdopodobnie brutalna siła rdate -s $serverco jakiś czas (jak co sześć godzin) szarpanie zegara za nos, aby nie dryfował nadmiernie zsynchronizowany. Ale drobnoziarnista dokładność jest prawdopodobnie poza zasięgiem.

Rzeczy, które znalazłem w przeszłości, kiedy używałem ntpd zamiast openntpd:

1. Musisz zezwolić na dostęp do localhost, aby ntpd zaczął poprawnie działać i faktycznie wykonywał różne czynności

   restrict 127.0.0.1
   restrict ::1
   

2. Chociaż możesz używać nazw hostów do reguł serwera, otwarcie dziury w celu rozmowy z tymi serwerami oznacza użycie restrictwymagającego adresu IP, więc ostatecznie i tak musiałem używać adresów IP do wszystkiego.

3. Nie wspominasz o używaniu restrictdo otwierania kopii zapasowej na swoich serwerach. To jest problem. Wypróbuj bloki takie jak następujące:

   # ntp.xs4all.nl
   server          194.109.22.18
   restrict        194.109.22.18
   

4. Potrzebujesz wielu peerów lub serwerów dla ntpd, ponieważ próbuje on użyć zasad większości głosów, aby poradzić sobie ze złym aktorem. Co najmniej 4, aby nadal mieć większość, gdy ją stracisz, najlepiej 5.

5. Aby zablokować domyślny dostęp, mogę użyć:

   restrict default notrust nomodify
   

   aby nadal móc wysyłać zapytania, ale skończyło się restrict default ignorena tym, że używasz, gdy ntpd 4.2 zmieniło znaczenie notrust. westchnienie

6. Jeśli nie zapewniasz czasu innym, prawdopodobnie nie potrzebujesz pełnej mocy zwykłego ntpd i powinieneś rozważyć openntpd. Napisany przez ekipę OpenBSD jest to znacznie bardziej minimalna implementacja, wykorzystująca separację uprawnień i znacznie prostszy plik konfiguracyjny. Podobno nie zapewni bardzo dokładnego czasu, jaki ntpd zrobi, ale z łatwością jest wystarczający dla zwykłego serwera lub stacji roboczej.

• Jeśli ntpd nie będzie mógł połączyć się ze zdalnym serwerem, nie zobaczysz przesunięcia dla tego serwera.
• Jeśli ntpq zostanie zablokowany przez ntpd, zobaczysz wyraźny komunikat o błędzie z ntpq.
• Jeśli jakaś inna usługa ustawi również czas (np. Narzędzia vmware), zobaczysz przeskakujące przesunięcie dla serwera (uruchamiaj ntpq -p co 70 sekund).

Dane reach 7wyjściowe in ntpq wskazują, że pozwalasz ntpd działać tylko przez około 4 minuty. 7 to 111 binarne, co oznacza, że ​​serwer został osiągnięty już 3 razy. ntp osiąga co 64 sekundy ( pollwartość) i czekał już 30 sekund ( whenwartość) od ostatniego kontaktu.

offset -0.136Wskazano, że system jest już zsynchronizowane. Tylko ntpd nie oznaczył jeszcze serwera jako źródła. Daj mu więcej czasu, a pojawi się mała gwiazda.

Tak więc właściwie twój NTTP synchronizował się. Ale ntpd zwykle nie synchronizuje się w jednym dużym skoku (jak ntpdate), ale próbuje powoli dostosowywać czas i zapewnia przez kilka cykli, że czas jest stabilny.

PS: Mam świadomość, że pytanie jest bardzo stare. Ale problem jest ponadczasowy. Wszystkie pozostałe odpowiedzi wprowadzają w błąd IMHO. ntpd jest nawet zalecany przez VMWare do synchronizacji czasu.

Znalazłem wyłączony system i zastanawiałem się, dlaczego zegar HW nie synchronizował się z zegarem systemowym przy czystym wyłączeniu. Wydaje się, że w sysconfig jest ustawienie NTP, które wymaga edycji, aby tak się stało.

W /etc/sysconfig/ntpd:

# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no

Ustawiłem to na yes. Oczywiście najpierw sprawdź, czy masz solidny serwer NTP, a zegar systemowy jest niezawodny.

Wiedziałem, że to było to - moje przekrzywienie wyniosło 47 sekund, a mój zegar HW również 47 sekund. Bingo! Moją pierwszą wskazówką były awarie protokołu Kerberos widoczne w dziennikach. Kerberos i wiele serwerów NAS nie będzie działać, jeśli przekrzywienie zegara jest zbyt duże.

Miłego dnia!

Jeśli korzystasz z vhosta na vmware, zapoznaj się z następującym artykułem .. powinien pomóc http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf

Hai ..

Przejrzyj to odniesienie, aby sprawdzić, czy może pomóc w rozwiązaniu problemu:

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_: Ch24 : _The_NTP_Server

możesz opublikować zawartość pliku ntpd.conf, dane wyjściowe poleceń debugowania, takie jak ntpq -p

I sprawdź swoją datę / godzinę?

I sprawdź to również, uruchom ntpdate i uruchom ntpd, czy czas jest zsynchronizowany?

z najlepszymi życzeniami