Dlaczego zegar VPS wykazuje odchylenia i jak go naprawić

Dlaczego zegar VPS wykazuje odchylenia

Zegar VPS wykazuje odchylenia, ponieważ nie jest korygowany. Jądro systemu odlicza czas na podstawie licznika sprzętowego, który pracuje nieco za szybko lub za wolno. Brak działającego klienta synchronizacji czasu powoduje, że ten niewielki błąd narasta z każdą godziną. Wewnątrz maszyny wirtualnej występuje druga przyczyna: system gościa współdzieli fizyczny procesor z innymi gośćmi, więc momenty, w których nie jest on przydzielony do procesora, są momentami, w których nie może on zliczać czasu.

W przypadku współczesnego gościa KVM sam licznik rzadko stanowi rzeczywisty problem. Parawirtualne źródło kvm-clock odczytuje wartość utrzymywaną przez hosta, dzięki czemu poprawnie działający gość ściśle śledzi czas hosta. Zegary, które wykazują widoczne błędy, zazwyczaj mają bardziej prozaiczną przyczynę. Nie działa żaden demon synchronizacji, działają dwa i wchodzą ze sobą w konflikt, lub ruch wychodzący na porcie UDP 123 jest blokowany w sieci dostawcy. Gość pobiera dyscyplinę czasu z hosta lub za pośrednictwem NTP (network time protocol), a nie z własnego oscylatora.

Skutki nieprawidłowego czasu systemowego

• Kody uwierzytelniania dwuskładnikowego TOTP (time-based one-time password) przestają być zgodne, co uniemożliwia dostęp do serwera mimo posiadania poprawnego hasła i klucza.
• Certyfikat wystawiony przed chwilą jest odrzucany, a curl zwraca błąd SSL certificate problem: certificate is not yet valid.
• apt update odmawia obsługi repozytorium z powodu E: Release file for ... is not valid yet (invalid for another 1d 2h 3min 4s).
• Zadania zaplanowane uruchamiają się w niewłaściwym momencie, a skok czasu może spowodować dwukrotne wykonanie jednego zadania przy jednoczesnym pominięciu innego.
• Dzienniki z dwóch serwerów nie dają się zsynchronizować, co zmusza do odtwarzania osi czasu incydentu na podstawie domysłów.

Tolerancja jest mniejsza, niż powszechnie się uważa. Poniższe wartości to udokumentowane ustawienia domyślne, a nie wyniki pomiarów testowych.

[
  {
    "label": "TLS certificate boundary",
    "tolerance_seconds": 0,
    "documented_in": "RFC 5280"
  },
  {
    "label": "chrony steps instead of slewing",
    "tolerance_seconds": 1,
    "documented_in": "Debian and Ubuntu chrony.conf"
  },
  {
    "label": "TOTP code, one time step",
    "tolerance_seconds": 30,
    "documented_in": "RFC 6238"
  },
  {
    "label": "Kerberos clock skew",
    "tolerance_seconds": 300,
    "documented_in": "MIT krb5 default"
  }
]

Kod TOTP jest obliczany na podstawie licznika, który zmienia się co 30 sekundy, a większość weryfikatorów akceptuje jeden krok w obie strony. Pół minuty błędu w każdą stronę wyczerpuje cały dostępny margines. Protokół Kerberos jest znacznie bardziej wyrozumiały, z domyślną tolerancją odchylenia wynoszącą 300 sekund. Certyfikat nie wybacza błędów: jest sprawdzany względem sztywnych punktów czasowych z okresem karencji wynoszącym 0 sekund, więc zegar spóźniony o sekundę odrzuci certyfikat, który jest w pełni poprawny.

Trzy zegary i który z nich jest istotny

Zegar systemowy jest tym, który ma znaczenie. Jest to CLOCK_REALTIME jądra: liczba sekund od 1 stycznia 1970 UTC, przechowywana w pamięci i odczytywana przez każdy proces wymagający znacznika czasu. Wiersze logów, weryfikacja certyfikatów, kody TOTP oraz czasy modyfikacji plików pochodzą właśnie z niego. Gdy ktoś twierdzi, że czas na serwerze jest nieprawidłowy, odnosi się właśnie do tego zegara.

Zegar sprzętowy, nazywany również RTC (real time clock), to oddzielny licznik, który działa również po wyłączeniu maszyny. Na maszynie fizycznej jest to układ zasilany bateryjnie. Wewnątrz maszyny wirtualnej jest on emulowany przez hypervisor, więc stanowi głównie artefakt hosta. Linux odczytuje go raz podczas startu w celu ustalenia wartości początkowej, a następnie prowadzi własne zliczanie. timedatectl wyświetla go w wierszu RTC time. Nie należy przeprowadzać debugowania na podstawie tego wiersza na VPS, ponieważ informuje on o czasie z perspektywy hosta, a nie o stanie synchronizacji zegara systemowego. W kontenerze zazwyczaj nie ma dostępu do /dev/rtc, dlatego hwclock --show kończy się błędem hwclock: Cannot access the Hardware Clock via any known method..

Clocksource to mechanizm, za pomocą którego jądro zlicza czas pomiędzy odczytami. Aby sprawdzić, który z nich został wybrany przez jądro, należy wykonać polecenie:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

W środowisku KVM zazwyczaj widoczny jest kvm-clock. Odczytuje on wartość utrzymywaną przez hosta, dlatego gość KVM bez klienta NTP przez pewien czas zachowuje w miarę poprawny czas. tsc to licznik samego procesora. Goście Xen zgłaszają xen, a goście Hyper-V zgłaszają źródło hyperv. Nie należy zmieniać tego ustawienia bez uzasadnionego powodu, ponieważ jądro automatycznie wybiera najlepsze źródło, któremu ufa na danym sprzęcie.

Niektórzy dostawcy udostępniają gościom urządzenie PTP (precision time protocol), które pozwala chrony odczytywać zegar hosta bezpośrednio, zamiast przez sieć. Warto to sprawdzić, choć często jest to niedostępne na współdzielonych serwerach VPS:

sudo modprobe ptp_kvm
ls /dev/ptp*
cat /sys/class/ptp/ptp0/clock_name

Jeśli modprobe kończy się niepowodzeniem lub urządzenie nie jest widoczne, host nie oferuje tej funkcji i jedynym rozwiązaniem pozostaje sieciowy NTP. Jeśli clock_name wskazuje na wirtualny zegar KVM, chrony może go wykorzystać za pomocą dyrektywy refclock PHC /dev/ptp0 poll 2 w pliku konfiguracyjnym.

Odczyt stanu czasu na własnej maszynie

Zacznij od jednego polecenia. Odpowiada ono na pytanie „czy cokolwiek dba o poprawność tego zegara” na jednym ekranie.

timedatectl

Przeczytaj te linie, zamiast polegać na zapamiętanej liczbie:

• Local time oraz Universal time to ten sam moment wydrukowany w Twojej strefie czasowej oraz w UTC. Jeśli są identyczne, maszyna pracuje już w czasie UTC.
• RTC time to zegar sprzętowy opisany powyżej. Na serwerze VPS zignoruj go.
• Time zone to format, którego system używa do wyświetlania czasu lokalnego.
• System clock synchronized to własna flaga jądra. Demon czasu ustawia ją, gdy zaufa swoim źródłom, więc no oznacza, że od momentu uruchomienia systemu nic nie korygowało tego zegara.
• NTP service raportuje stan usługi systemd-timesyncd. n/a jest normalnym stanem na maszynie z uruchomionym chrony, ponieważ timesyncd nie jest tam zainstalowany. System clock synchronized: yes wraz z NTP service: n/a oznacza, że chrony wykonuje swoją pracę, a jądro systemu to potwierdza.

Następnie sprawdź, jak duże jest odchylenie. Nie oceniaj go „na oko” względem telefonu. Jeśli chrony jest uruchomiony:

chronyc tracking
chronyc sources -v

chronyc tracking wyświetla liczby, które odpowiadają na to pytanie. System time to bieżące przesunięcie względem czasu NTP, po którym następuje słowo fast lub slow. Last offset to wielkość ostatniej korekty. Frequency to błąd częstotliwości, który chrony zmierzył w zegarze i który jest już kompensowany. Leap status powinno wskazywać Normal. Jeśli wskazuje Not synchronised, a Reference ID ma wartość 00000000 (), oznacza to, że chrony nie wybrał jeszcze źródła czasu.

chronyc sources -v drukuje legendę nad listą, dzięki czemu nie trzeba pamiętać symboli. Dwie kolumny niosą większość informacji. Znak stanu na początku każdej linii określa, jak chrony ocenia dane źródło, przy czym * oznacza źródło aktualnie używane, a ? w każdej linii oznacza, że nikt nie odpowiada. Reach to historia odpowiedzi z ostatnich ośmiu odpytań zapisana w systemie ósemkowym: 377 oznacza, że wszystkie osiem zostało odebranych, 0 oznacza, że żadna.

Jeśli za czas odpowiada systemd-timesyncd:

timedatectl timesync-status
timedatectl show-timesync --all

timesync-status wyświetla serwer, z którym nawiązano połączenie, interwał odpytywania oraz wartość Offset. Jeśli polecenie zwraca błąd dotyczący usługi zamiast wyświetlać status, oznacza to, że timesyncd nie jest demonem zarządzającym czasem na tej maszynie, co samo w sobie jest odpowiedzią na Twoje pytanie.

Aby przeprowadzić szybką weryfikację względem świata zewnętrznego bez dodatkowych narzędzi, porównaj zegar z nagłówkiem HTTP Date, który jest serwowany w czasie GMT z dokładnością do jednej sekundy:

date -u
curl -sI https://www.cloudflare.com | grep -i '^date:'

Różnica rzędu sekundy lub dwóch jest normalna i nie oznacza problemu. Różnica rzędu minuty wskazuje na błąd w konfiguracji.

chrony czy systemd-timesyncd na VPS

Systemy Ubuntu i Debian domyślnie dostarczają systemd-timesyncd. Jest to klient SNTP (simple network time protocol): odpytuje on jeden serwer na raz i koryguje zegar w jego kierunku. Na maszynie, która pozostaje w trybie online i startuje z w miarę poprawnym czasem, jest to wystarczające rozwiązanie, które nie obciąża zasobów.

chrony to pełna implementacja NTP i lepszy wybór domyślny dla maszyny wirtualnej, co wynika z danych wyjściowych tego narzędzia. Odpytuje ono kilka źródeł jednocześnie i odrzuca te, których wskazania są rozbieżne. Mierzy błąd dryftu zegara i zapisuje go w pliku drift, dzięki czemu koryguje tendencję zegara, zamiast reagować na każdą próbkę z osobna. Szybko odzyskuje też synchronizację po dwóch zdarzeniach typowych dla maszyn wirtualnych, a nieobecnych w fizycznych serwerach: wstrzymaniu przez hosta oraz migracji na inny host w trakcie pracy. Jeśli host udostępnia urządzenie PTP, chrony potrafi z niego korzystać.

sudo apt update && sudo apt install -y chrony
systemctl status chrony --no-pager
chronyc sources -v
chronyc tracking

Podczas instalacji obserwuj dane wyjściowe apt. W systemach Debian i Ubuntu pakiety chrony oraz systemd-timesyncd dostarczają time-daemon, dlatego apt usuwa timesyncd podczas instalacji chrony. Jest to zachowanie poprawne i pożądane. Nigdy nie uruchamiaj obu usług jednocześnie, ponieważ dwa demony ustawiające ten sam zegar będą ze sobą konkurować, a raportowane przez nie przesunięcie czasu stanie się niewiarygodne. W systemach Rocky i AlmaLinux instalację przeprowadź za pomocą sudo dnf install -y chrony, gdzie jednostka nosi nazwę chronyd, a nie chrony.

Plik konfiguracyjny to /etc/chrony/chrony.conf w systemach Debian i Ubuntu oraz /etc/chrony.conf w systemach Rocky i Alma. Domyślna konfiguracja dystrybucji jest odpowiednia dla VPS, więc zmieniaj ją tylko w uzasadnionych przypadkach. Warto zrozumieć działanie dwóch dyrektyw:

• Linie pool oraz server określają źródła czasu. Dodanie iburst nakazuje chrony wysłanie szybkiej serii zapytań przy starcie, dzięki czemu pierwsza synchronizacja następuje w ciągu sekund, a nie minut.
• makestep decyduje, kiedy chrony skokowo przestawi zegar, zamiast płynnie go korygować. Sprawdź bieżące ustawienie za pomocą grep -n makestep /etc/chrony/chrony.conf. Domyślna wartość dla systemów Debian i Ubuntu, makestep 1 3, oznacza: podczas trzech pierwszych aktualizacji po starcie chronyd, przestaw zegar skokowo, jeśli błąd przekracza jedną sekundę, a następnie koryguj czas wyłącznie poprzez płynne dostrajanie (slewing).

Jeśli chcesz, aby ruch sieciowy związany z czasem był uwierzytelniony w celu ochrony przed manipulacją na trasie, chrony w wersji 4 i nowszych obsługuje NTS (network time security). Najpierw potwierdź swoją wersję za pomocą chronyd -v i pamiętaj, że NTS wymaga otwarcia wychodzącego portu TCP 4460, oprócz standardowego UDP 123:

server time.cloudflare.com iburst nts

Przed rozpoczęciem pracy zrestartuj usługę i zweryfikuj jej działanie. Konfiguracja, której nie uda się przetworzyć, pozostawi system bez działającego demona czasu, o czym zegar systemowy nie poinformuje.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

Dlaczego zegar z kilkuminutowym opóźnieniem pozostaje niedokładny

Demon czasu posiada dwie metody korekty przesunięcia. Slewing (płynne dostrajanie) przyspiesza lub spowalnia zegar do momentu wyeliminowania błędu, co zapewnia ciągłość czasu bez powtarzania lub pomijania znaczników czasu. Stepping (skokowa korekta) natychmiast ustawia poprawną wartość; jest to metoda szybka, ale może cofnąć zegar. Cofanie czasu jest ryzykowne dla procesów mierzących czas na podstawie zegara systemowego, dlatego oba demony preferują metodę slewing.

Ta preferencja sprawia, że znacznie rozregulowany zegar może pozostawać niedokładny przez długi czas. chrony wykonuje korektę skokową tylko w oknie czasowym określonym przez makestep, które domyślnie obejmuje kilka pierwszych aktualizacji po uruchomieniu demona. Jeśli chronyd działa od tygodnia i wykryje czterdziestosekundowe przesunięcie, spróbuje je skorygować metodą slewing, co zajmie znacznie więcej czasu, niż jest to pożądane. Wymuś korektę jednorazowo, w kontrolowany sposób, podczas niskiego obciążenia systemu:

sudo chronyc makestep
chronyc tracking

chronyc tracking powinien teraz raportować przesunięcie System time bliskie zeru, a Last offset powinien wskazywać wielkość właśnie skorygowanego błędu. Przed wykonaniem tej operacji na serwerze bazy danych należy zachować ostrożność, ponieważ skok zegara wstecz może zakłócić działanie oprogramowania zakładającego liniowy upływ czasu. Restart demona jest łagodniejszą wersją tej samej naprawy, ponieważ okno makestep otwiera się ponownie w momencie startu.

Kontenery współdzielą zegar hosta

Kontener nie posiada własnego zegara czasu rzeczywistego, więc wewnątrz nie ma czego synchronizować. Przestrzenie nazw czasu w systemie Linux wirtualizują jedynie zegary monotoniczne oraz zegary czasu od uruchomienia systemu. CLOCK_REALTIME nie podlega wirtualizacji, co oznacza, że kontener odczytuje ten sam zegar systemowy, co host, na którym działa. Naprawa zegara na hoście automatycznie naprawia czas we wszystkich kontenerach na tym hoście.

Wynika z tego kilka konsekwencji. Nie należy instalować chrony ani ntpd w obrazie, ponieważ w najlepszym przypadku nie przyniesie to żadnego efektu. Ustawienie daty wewnątrz kontenera bez uprzywilejowania kończy się niepowodzeniem z błędem date: cannot set date: Operation not permitted, ponieważ jądro wymaga uprawnienia CAP_SYS_TIME do wykonania tego wywołania. Przyznanie CAP_SYS_TIME nie zapewnia kontenerowi prywatnego zegara, lecz daje mu możliwość zmiany zegara hosta, a tym samym zegara wszystkich pozostałych kontenerów.

Inna strefa czasowa wewnątrz kontenera nie jest problemem z zegarem. Obraz zawierający własny plik /etc/localtime wyświetla ten sam moment w czasie sformatowany dla innej strefy, więc wynik date wydaje się błędny, mimo że zegar wskazuje poprawny czas. Należy ustawić TZ=UTC w środowisku kontenera, aby wyeliminować nieścisłości. Wybrane środowisko uruchomieniowe nie zmienia nic w tej kwestii, a porównanie bezrootowego Podmana i Dockera omawia aspekty, które faktycznie ulegają zmianie.

Strefy czasowe: UTC na serwerze, czas lokalny dla użytkowników

Ustaw maszynę na czas UTC i pozostaw to ustawienie bez zmian.

timedatectl list-timezones | grep -i utc
sudo timedatectl set-timezone UTC
timedatectl

Czas UTC nie podlega zmianom czasu na letni i zimowy, co stanowi główny argument za jego stosowaniem. Zadanie uruchamiane codziennie o 02:30 w strefie, w której obowiązuje zmiana czasu, wykona się dwukrotnie w dniu cofania zegarów i ani razu w dniu ich przestawiania do przodu. man 8 cron dokumentuje specjalną obsługę przesunięć mniejszych niż trzy godziny: zadania pominięte przy przeskoku do przodu są uruchamiane krótko po zmianie, a zadania przypadające na powtórzoną godzinę przy cofaniu zegarów nie są uruchamiane po raz drugi. Takie zachowanie jest poprawne, jednak nie powinno wymagać analizy o godzinie 03:00. W przypadku UTC zadanie uruchamia się raz dziennie, każdego dnia w roku. Jeśli zadanie w ogóle nie wystartowało, zamiast uruchomić się o nietypowej godzinie, bardziej prawdopodobną przyczyną są przyczyny, dla których zadanie cron nie uruchamia się w trybie cichym.

Ten sam argument dotyczy analizy logów. journalctl formatuje znaczniki czasu w strefie czasowej systemu, a journalctl --utc wymusza użycie UTC. Dwa serwery w dwóch różnych strefach zamieniają każdy incydent w ćwiczenie z przeliczania czasu, a przeliczenia wykonywane pod presją prowadzą do błędnej interpretacji osi czasu. Utrzymuj systemy w czasie UTC, przechowuj znaczniki czasu w UTC i dokonuj konwersji tylko w momencie odczytu przez człowieka. Każdy, kto potrzebuje odczytu lokalnego dla pojedynczego polecenia, może o niego poprosić bez zmiany ustawień maszyny:

TZ=Europe/Berlin date

Jeszcze jedna linia w danych wyjściowych timedatectl odnosi się do tej sekcji. RTC in local TZ powinno mieć wartość no. Ustawienie tej opcji na yes jest obejściem dla systemów dual-boot z Windows na laptopie, natomiast na serwerze dodaje jedynie przesunięcie, które może stać się źródłem problemów w przyszłości. Gdy opcja ta jest aktywna, timedatectl wyświetla ostrzeżenie, że system jest skonfigurowany do odczytu czasu RTC w lokalnej strefie czasowej.

Rozwiązywanie problemów według objawów

Kod dwuskładnikowy jest odrzucany na serwerze. Przed podjęciem innych działań należy sprawdzić zegar. Kod generowany jest na podstawie licznika, który zmienia się co 30 sekund, więc serwer z opóźnieniem 90 sekund oblicza kod dla kroku, który na telefonie już wygasł. timedatectl wyświetli System clock synchronized: no, lub chronyc tracking zgłosi duże przesunięcie System time. Jest to błąd inny niż odrzucenie klucza, które generuje własny komunikat i zostało opisane w przewodniku dotyczącym błędów uwierzytelniania kluczem publicznym.

apt update informuje, że plik Release nie jest jeszcze ważny. Pełny komunikat zawiera nazwę repozytorium oraz czas, przez jaki będzie ono uznawane za nieważne, na przykład is not valid yet (invalid for another 1d 2h 3min 4s). Zegar systemowy jest opóźniony względem daty w pliku Release repozytorium, a podany czas bezpośrednio wskazuje wielkość tego opóźnienia. Należy skorygować zegar. Nie należy wyłączać sprawdzania daty w apt, ponieważ mechanizm ten chroni przed serwowaniem nieaktualnych indeksów pakietów.

Każda linia źródła wskazuje stan nieosiągalny, a Reach wynosi 0. Brak odpowiedzi oznacza problem z ruchem wychodzącym, a nie z konfiguracją. NTP korzysta z portu UDP 123, który w niektórych sieciach jest filtrowany lub przekierowywany. sudo chronyc ntpdata wyświetla liczniki dla każdego źródła, w tym Total TX oraz Total RX. Wzrost liczby wysłanych pakietów (TX) przy zerowej liczbie odebranych (RX) oznacza, że pakiety opuszczają system, ale nie wracają, co wskazuje na firewall między serwerem a źródłem.

Zegar był poprawny, ale nagle przeskoczył. Jest to typowe dla zdarzeń na hoście. Przywrócenie migawki, wstrzymanie maszyny wirtualnej lub migracja na żywo na inny host może spowodować rozbieżność czasu wewnątrz gościa. chrony wykrywa to przy następnym odpytaniu i koryguje czas; systemd-timesyncd może najpierw odczekać długi interwał odpytywania. Należy potwierdzić, że demon uruchamia się przy starcie systemu za pomocą systemctl is-enabled chrony, ponieważ demon uruchomiony ręcznie przestanie działać po restarcie.

Przesunięcie jest niewielkie, ale nie stabilizuje się. Należy sprawdzić parametr CPU steal. Gość, który nie otrzymuje czasu procesora w momencie przerwania zegarowego, doświadcza opóźnień w próbkowaniu, przez co przesunięcie zamiast maleć, waha się. top pokazuje to jako wartość st w linii CPU. Odczytywanie czasu CPU steal na współdzielonym hoście wyjaśnia znaczenie tej wartości oraz możliwe działania naprawcze.

Wydany certyfikat jest odrzucany jako jeszcze nieważny. curl wyświetla SSL certificate problem: certificate is not yet valid, a przeglądarki zgłaszają podobny błąd. Certyfikat jest poprawny, ale zegar sprawdzający go jest opóźniony. Przyczyną może być dowolna z maszyn, dlatego należy sprawdzić zarówno klienta, jak i serwer. Jeśli to serwer wydający certyfikat ma błędny czas, przewodnik po certyfikatach certbot i nginx opisuje proces odnawiania w takiej konfiguracji.

Dodaj to do wykonywanych już kontroli

Synchronizacja czasu jest ustawieniem startowym, którego awaria pozostaje niezauważona przez miesiące. Jest to dokładnie ten rodzaj problemu, który wykrywa rutynowa kontrola, a nie pamięć. Polecenia timedatectl oraz chronyc tracking wymagają łącznie dwóch sekund na odczyt. Należy je uruchamiać w ramach pierwszych dziesięciu minut na nowym VPS, a następnie ponownie podczas pracy z regularną listą kontrolną konserwacji serwera Linux. Jeśli wolisz, aby kontrola wykonywała się automatycznie i zgłaszała błąd w przypadku wzrostu przesunięcia, artykuł tworzenie usługi i timera systemd opisuje wzorzec dla małej jednostki raportującej zgodnie z harmonogramem. Taka kontrola jest krótkim skryptem, a nie daemonem, więc wymaga ustawienia Type=oneshot zamiast domyślnego, a omówienie typów usług systemd wyjaśnia, dlaczego wybór niewłaściwego typu skutkuje jednostką, która raportuje sukces, mimo że go nie osiągnęła.

FAQ

Jak sprawdzić, czy zegar VPS jest zsynchronizowany?

Uruchom timedatectl i odczytaj linię System clock synchronized. Jest to flaga jądra ustawiana przez demona zarządzającego czasem, dlatego yes wraz z NTP service: n/a jest stanem prawidłowym dla systemu korzystającego z chrony. Aby sprawdzić wielkość błędu, uruchom chronyc tracking i odczytaj System time, lub uruchom timedatectl timesync-status i odczytaj Offset, jeśli za czas odpowiada systemd-timesyncd. Aby zweryfikować czas względem zewnętrznego źródła, porównaj date -u z nagłówkiem Date zwracanym przez dowolną witrynę HTTPS.

Czy na VPS używać chrony czy systemd-timesyncd?

Używaj chrony w każdym istotnym zastosowaniu. systemd-timesyncd to klient SNTP, który synchronizuje się z jednym serwerem; sprawdza się na maszynach, które są stale włączone i których czas początkowy jest zbliżony do poprawnego. chrony odpytuje wiele źródeł, odrzuca rozbieżne dane, uczy się błędu tempa zegara i szybko odzyskuje synchronizację po wstrzymaniu hosta lub migracji na żywo. Instalacja chrony w systemach Debian lub Ubuntu automatycznie usuwa systemd-timesyncd, ponieważ oba pakiety dostarczają time-daemon. Nigdy nie uruchamiaj dwóch demonów czasu jednocześnie.

Dlaczego kody TOTP nie działają na jednym serwerze, a działają wszędzie indziej?

Ponieważ kod TOTP jest funkcją bieżącego czasu. Kod pochodzi z licznika, który zmienia się co 30 sekund, więc serwer i telefon muszą być zgodne co do aktualnego kroku. Większość weryfikatorów akceptuje jeden krok różnicy w każdą stronę, co daje około pół minuty tolerancji. Sprawdź timedatectl na danym serwerze. Jeśli System clock synchronized wskazuje no, napraw synchronizację, a kody zaczną działać bez konieczności zmiany współdzielonego sekretu.

Czy można ustawić czas wewnątrz kontenera Docker?

Nie, i nie jest to potrzebne. Kontener współdzieli CLOCK_REALTIME hosta, ponieważ przestrzenie nazw czasu w systemie Linux wirtualizują jedynie zegary monotoniczne i zegar czasu rozruchu. Kontener bez uprzywilejowania otrzymuje date: cannot set date: Operation not permitted, a dodanie CAP_SYS_TIME pozwala mu zmienić zegar hosta, zamiast nadawać mu własny. Synchronizuj czas na hoście. Inny czas lokalny wewnątrz kontenera to kwestia ustawienia strefy czasowej, więc skonfiguruj TZ w środowisku kontenera.

Czy serwer powinien używać czasu UTC czy lokalnego?

UTC, z czasem lokalnym stosowanym w momencie odczytu przez użytkownika. UTC nie zmienia się przy przejściu na czas letni, dzięki czemu zadania cykliczne uruchamiają się raz dziennie przez cały rok, a znaczniki czasu z różnych serwerów są spójne bez konieczności konwersji. Ustaw czas za pomocą sudo timedatectl set-timezone UTC. Każdy, kto potrzebuje odczytu lokalnego, może poprzedzić polecenie prefiksem, na przykład TZ=America/New_York date, co nie zmienia ustawień zegara systemowego.