Dlaczego zegar na VPS się spóźnia i jak go naprawić

Dlaczego zegar na VPS wykazuje odchyłki

Zegar na VPS wykazuje odchyłki, ponieważ nie jest korygowany. Jądro systemu odlicza czas na podstawie licznika sprzętowego, który działa nieco za szybko lub za wolno. W przypadku braku działającego klienta synchronizacji czasu, 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 chwile, w których nie jest on przydzielony do procesora, są chwilami, w których nie może odliczać 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, więc poprawnie działający gość ściśle śledzi czas hosta. Zegary, które wskazują wyraźnie błędny czas, zazwyczaj wynikają z bardziej prozaicznych przyczyn. Nie działa żaden demon synchronizacji, działają dwa demony 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 protokołu NTP (network time protocol), a nie z własnego oscylatora.

Skutki nieprawidłowego czasu systemowego

• Kody dwuetapowej weryfikacji TOTP (time-based one-time password) przestają być zgodne, co uniemożliwia zalogowanie się do serwera, mimo posiadania poprawnego hasła i klucza.
• Certyfikat wystawiony przed chwilą jest odrzucany, a curl wyświetla 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.
• Logi z dwóch serwerów nie mogą zostać zestawione, 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ść mechanizmów weryfikacji akceptuje jeden krok w obie strony. Pół minuty odchylenia w dowolnym kierunku wyczerpuje cały dostępny margines. Protokół Kerberos jest znacznie bardziej wyrozumiały, z domyślną tolerancją wynoszącą 300 sekund. Certyfikaty nie wykazują żadnej tolerancji: są sprawdzane względem sztywnych punktów czasowych z okresem karencji wynoszącym 0 sekund, więc zegar spóźniony o jedną sekundę spowoduje odrzucenie w pełni poprawnego certyfikatu.

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 dziennika, weryfikacja certyfikatów, kody TOTP oraz czasy modyfikacji plików pochodzą z tego źródła. Gdy pojawia się informacja, że czas serwera jest nieprawidłowy, odnosi się to 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 emulowany przez hypervisor, więc stanowi głównie artefakt hosta. Linux odczytuje go raz podczas rozruchu w celu uzyskania 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. Należy sprawdzić, który z nich został wybrany przez jądro:

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 maszyna wirtualna KVM bez klienta NTP przez pewien czas zachowuje w miarę poprawny czas. tsc to własny licznik procesora. Maszyny wirtualne Xen zgłaszają xen, a maszyny wirtualne 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ą maszynie wirtualnej urządzenie PTP (precision time protocol), które pozwala chrony na bezpośredni odczyt zegara hosta zamiast korzystania z sieci. 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 żadne 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ą wiersza refclock PHC /dev/ptp0 poll 2 w swojej konfiguracji.

Odczyt stanu czasu na własnej maszynie

Należy rozpocząć od jednego polecenia. Odpowiada ono na pytanie „czy cokolwiek dba o poprawność tego zegara” na jednym ekranie.

timedatectl

Należy przeczytać te linie, zamiast polegać na zapamiętanej wartości:

• Local time oraz Universal time to ten sam moment wyświetlony w strefie czasowej użytkownika oraz w czasie UTC. Jeśli są identyczne, maszyna pracuje już w czasie UTC.
• RTC time to zegar sprzętowy opisany powyżej. W przypadku VPS należy go zignorować.
• Time zone to format czasu lokalnego używany przez system.
• System clock synchronized to flaga samego jądra systemu. Demon czasu ustawia ją, gdy zaufa swoim źródłom, więc no oznacza, że od momentu uruchomienia systemu zegar nie był korygowany.
• NTP service informuje o stanie systemd-timesyncd. n/a jest stanem normalnym 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 potwierdza synchronizację.

Następnie należy sprawdzić wielkość odchylenia. Nie należy oceniać go „na oko” względem telefonu. Jeśli chrony jest uruchomiony:

chronyc tracking
chronyc sources -v

chronyc tracking wyświetla liczby odpowiadające na to pytanie. System time to bieżące odchylenie od 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 zmierzony przez chrony w zegarze, 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 wyświetla 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, gdzie * oznacza źródło aktualnie używane, a ? w każdej linii oznacza brak odpowiedzi. Reach to historia odpowiedzi z ostatnich ośmiu odpytań zapisana w systemie ósemkowym: 377 oznacza, że uzyskano osiem odpowiedzi, a 0 oznacza, że nie uzyskano żadnej.

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 usługi zamiast wyświetlać status, oznacza to, że timesyncd nie jest demonem zarządzającym czasem na tej maszynie, co samo w sobie stanowi odpowiedź na pytanie.

W celu szybkiego sprawdzenia czasu względem świata zewnętrznego bez dodatkowych narzędzi, należy porównać zegar z nagłówkiem HTTP Date, który jest wysyłany w formacie 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 błędu. Różnica rzędu minuty wskazuje na problem 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 w danym momencie i koryguje zegar w jego stronę. 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 samego narzędzia. Odpytuje ono kilka źródeł jednocześnie i odrzuca te, które są rozbieżne. Mierzy błąd tempa zegara i zapisuje go w pliku drift, dzięki czemu koryguje tendencję zegara, zamiast gonić za każdą pojedynczą próbką. Szybko odzyskuje też sprawność po dwóch zdarzeniach typowych dla maszyn wirtualnych, a nieobecnych w fizycznych serwerach: wstrzymaniu przez hosta oraz migracji na inny host w trakcie pracy. Gdy dostępne jest urządzenie PTP hosta, to właśnie chrony potrafi je odczytać.

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

Obserwuj dane wyjściowe apt podczas instalacji. W systemach Debian i Ubuntu pakiety chrony oraz systemd-timesyncd dostarczają time-daemon, więc apt usuwa timesyncd podczas instalacji chrony. Jest to poprawne i pożądane zachowanie. Nigdy nie uruchamiaj obu jednocześnie, ponieważ dwa demony ustawiające ten sam zegar będą ze sobą rywalizować, 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 nazywa się 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ć dwie dyrektywy:

• Linie pool oraz server określają źródła czasu. Dodanie iburst instruuje chrony, aby wysłało szybką serię 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łynnego korygowania. Sprawdź bieżące ustawienie za pomocą grep -n makestep /etc/chrony/chrony.conf. Domyślna wartość dla Debian i Ubuntu, makestep 1 3, oznacza: podczas trzech pierwszych aktualizacji po starcie chronyd, przestaw zegar skokowo, jeśli różnica przekracza jedną sekundę, a następnie koryguj wyłącznie poprzez płynne dostrajanie (slewing).

Jeśli chcesz, aby ruch związany z czasem był uwierzytelniony w celu ochrony przed manipulacją na trasie, chrony w wersji 4 i nowszych wspiera 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 UDP 123:

server time.cloudflare.com iburst nts

Zrestartuj i zweryfikuj usługę, zanim zaczniesz na niej polegać. Konfiguracja, której nie udało się przetworzyć, pozostawi system bez działającego demona czasu, a zegar nie wyświetli ostrzeżenia o tym stanie.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

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

Demon czasu posiada dwa sposoby na skorygowanie przesunięcia. Metoda slewing przyspiesza lub spowalnia zegar do momentu wyeliminowania błędu, co zapewnia ciągłość czasu bez powtarzania lub pomijania znaczników czasu. Metoda stepping wykonuje skok bezpośrednio do poprawnej wartości, co jest szybkie, ale może cofnąć zegar. Cofanie czasu jest niebezpieczne 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 stepping tylko w oknie czasowym dozwolonym 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ż można zaakceptować. Wymuś korektę jednorazowo, w sposób kontrolowany, w momencie niskiego obciążenia:

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. Zastanów się przed wykonaniem tego polecenia na aktywnym serwerze bazy danych, ponieważ zegar skaczący wstecz może wprowadzić w błąd oprogramowanie zakładające, że czas płynie wyłącznie do przodu. Restart demona jest łagodniejszą wersją tej samej poprawki, ponieważ okno makestep otwiera się ponownie w momencie startu.

Kontenery współdzielą zegar hosta

Kontener nie posiada własnego zegara czasu rzeczywistego, więc nie ma w nim 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 go 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 powodu date: cannot set date: Operation not permitted, ponieważ jądro wymaga do tego wywołania uprawnienia CAP_SYS_TIME. Przyznanie CAP_SYS_TIME nie zapewnia kontenerowi prywatnego zegara, lecz daje mu możliwość zmiany zegara hosta, a tym samym zegara każdego innego kontenera.

Inna strefa czasowa wewnątrz kontenera nie jest problemem z zegarem. Obraz zawierający własny /etc/localtime wyświetla ten sam moment w czasie sformatowany dla innej strefy, więc date wygląda na 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 tym zakresie, a porównanie bezrootowego Podman i Docker omawia kwestie, które faktycznie ulegają zmianie.

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

Ustaw czas systemowy na UTC i nie zmieniaj go.

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

UTC nie stosuje czasu letniego i to jest kluczowy argument. Zadanie uruchamiane codziennie o 02:30 w strefie z czasem letnim 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ęć krótszych 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 logiczne, jednak nie powinno być przedmiotem analizy o godzinie 03:00. W UTC zadanie uruchamia się raz dziennie, każdego dnia w roku. Jeśli zadanie w ogóle nie startuje, zamiast uruchamiać się o nietypowej porze, bardziej prawdopodobną przyczyną są powody, 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 UTC. Dwa serwery w dwóch strefach czasowych zamieniają każde zdarzenie w ćwiczenie z przeliczania, a przeliczenia wykonywane pod presją czasu prowadzą do błędnej interpretacji osi czasu. Utrzymuj systemy w UTC, przechowuj znaczniki czasu w UTC i dokonuj konwersji dopiero w momencie odczytu przez człowieka. Każdy, kto potrzebuje odczytu lokalnego dla pojedynczego polecenia, może o to 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 problemu w przypadku systemów dual-boot z Windows na laptopie, natomiast na serwerze dodaje jedynie przesunięcie, które może stać się przyczyną pomyłek 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 jakichkolwiek 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ż całkowite 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 wskazuje repozytorium oraz czas, przez jaki pozostanie ono 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 dla ruchu wychodzącego, a niektóre sieci filtrują lub przekierowują ten ruch. sudo chronyc ntpdata wyświetla liczniki dla każdego źródła, w tym Total TX oraz Total RX. Wzrost licznika TX przy zerowym 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ć, że czas wewnątrz gościa będzie opóźniony względem rzeczywistego. 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 nigdy się nie stabilizuje. Należy sprawdzić CPU steal. Gość, który nie jest planowany w momencie wystąpienia przerwania zegara, otrzymuje opóźnione próbki, przez co przesunięcie wędruje zamiast się stabilizować. 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. Błąd może leżeć po stronie klienta lub serwera, dlatego należy sprawdzić oba urządzenia. Jeśli serwer, który wydał certyfikat, ma nieprawidłowy czas, przewodnik po certyfikatach certbot i nginx opisuje proces odnawiania w takiej konfiguracji.

Dodaj to do wykonywanych kontroli

Synchronizacja czasu jest ustawieniem ładowanym podczas startu systemu, które w przypadku awarii nie generuje komunikatów przez kolejne miesiące. Jest to dokładnie ten typ problemu, który wykrywa rutynowa kontrola, a nie pamięć operacyjna. Polecenia timedatectl oraz chronyc tracking wymagają łącznie dwóch sekund na odczyt. Należy je uruchamiać w ramach pierwszych dziesięciu minut na nowym serwerze VPS, a także podczas realizacji regularnej listy kontrolnej konserwacji serwera Linux. Jeśli preferowane jest zautomatyzowanie tej kontroli i otrzymywanie powiadomień w przypadku wzrostu przesunięcia czasowego, artykuł tworzenie usługi i timera systemd opisuje wzorzec dla małej jednostki, która raportuje stan zgodnie z harmonogramem.

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, więc yes wraz z NTP service: n/a oznacza stan prawidłowy w przypadku korzystania z chrony. Aby sprawdzić wielkość błędu, uruchom chronyc tracking i odczytaj System time, lub uruchom timedatectl timesync-status i odczytaj Offset, jeśli używany jest 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?

W przypadku ważnych usług należy używać chrony. systemd-timesyncd to klient SNTP, który synchronizuje się z jednym serwerem; sprawdza się na maszynach, które są stale włączone i startują z czasem zbliżonym do poprawnego. chrony odpytuje wiele źródeł, odrzuca te niespójne, uczy się błędu częstotliwości 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ą aktualnego czasu. Kod pochodzi z licznika, który zmienia się co 30 sekund, więc serwer i telefon muszą być zgodne co do bieżącego kroku. Większość weryfikatorów akceptuje różnicę jednego kroku w każdą stronę, co daje około pół minuty marginesu błędu. 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 uprawnień otrzymuje date: cannot set date: Operation not permitted, a dodanie CAP_SYS_TIME pozwala mu zmieniać zegar hosta, zamiast nadawać mu własny. Należy synchronizować hosta. Inny czas lokalny wewnątrz kontenera wynika z ustawień strefy czasowej, więc ustaw TZ w środowisku kontenera.

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

UTC, z czasem lokalnym stosowanym w momencie odczytu danych przez użytkownika. Czas UTC nie zmienia się przy przejściu na czas letni, dzięki czemu zadania cykliczne wykonują 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.