Auf meinem selbstgebastelten Nitropad (Thinkpad X230, initial selbst geflasht, gestern auf v2.1-legacy firmware aktualisiert) läuft ein Devuan Linux, das ich gerade von Chimaera auf Daedalus aktualisiert habe. Die Systemuhr ist auf UTC, die lokale Zeit ist Europe/Berlin.
Jetzt habe ich das Problem, daß die Prüfsumme beim Booten nicht stimmt, denn mein Smartphone hat Netzbetreiberzeit, die FreeOTP±App hat keine (leicht zu findende) Option, um die Zeitzone einzustellen und der Kernel des Systems (6.1.x) stellt anscheinend die RTC regelmäßig, da ich ntp verwende.
Ich habe schon versucht, mit hwclock --systohc -l zu stellen, aber das ist nicht persistent.
Gibt es eine Lösung dafür, ohne den Kernel selber zu bauen?
Grundsätzlich würde ich ja gerne das Laptop auf UTC lassen und lieber der Smartphone-App sagen, daß sie doch bitte UTC nimmt, um die Prüfziffer zu berechnen. Geht das, bzw. gibt es eine alternative App, bei der das geht? Benutzt das irgendwer, bei dem es persistent korrekt ist (und auch nach Kernelupdate bleibt)?
Gruß
–Jan
[EDIT] Never mind, anscheinend sind nur meine Smartphone-Uhr und Systemzeit zu weit auseinander, daher das Timing sehr knapp. Sorry for the noise.
Wenn Du - unabhängig von NTP Verkettungen - in Kontrolle der Zeit bleiben möchstest, schaue Dir die Wirkungsweise des “Cristian Algorithmus” an.
Anregungen / Überlegungen dazu:
Wegen der Service Management Aspekte im Kontekt “roaming” führen Provider der Telekommunikation untereinander ein eher striktes und präzises “network time management”.
Die “system clock” Deines Notebooks kann weniger präzise justiert sein, als die Zeit ab NTP Server Deines aktuell verbundenen GSM/LTE Providers …
“trusted time” als Thema unserer Zeit: Welcher Kirchturmuhr in Sichtweite traust Du und warum?
Um die obigen Anmerkungen für den Linux kernel zu beschreiben: Wenn du die RTC mit hwclock -systohc aktualisierst, ist sie aktuell. ok. Die generelle Ungenauigkeit der RTC bleibt aber bestehen. Die meisten Distributionen lassen die Abweichung der RTC im sogenannten hwclock drift-file protokollieren. Beim systemstart kann einfach auf diesen drift-file zurückgegriffen werden und mit der Laufzeit wird dieser über ntp immer genauer. Was oft aber nicht mehr passiert ist, dass die RTC um die Abweichung korrigiert wird. (Es gab mal heftige Probleme mit services die mit den Zeitänderungen nicht klar kamen) Was devuan macht, weiss ich nicht.
Die zunehmende RTC Ungenauigkeit fällt beim Vergleich der TOTP token natürlich zunehmend auf. Das ist komplett unabhängig von UTC/localtime. Du könntest die RTC manuell unter Einbeziehung des drift-file aktualisieren. Das sollte aber am besten passieren bevor das System rw gemountet ist. Nachlesen kann man die Zusammenhänge im manual von hwclock.
Ich habe übrigens das gleiche Phänomen mit heads. Bei mir reicht es den heads TOTP erst zu aktualisieren, wenn die App schon 10 Sekunden in den Zähler gelaufen ist.
Ein weiterer Punkt der reinspielt: wenn man TOTP anderweitig nutzt, halten viele services das letzte TOTP noch im Puffer sobald der neue erscheint. Ganz einfach, da das TOTP vom Nutzer mit Zeitverzögerung eingegeben wird. Dieser Puffer entfällt beim manuellen Vergleich in heads auch.
