KeyHelp Community

Hallo,
ich habe einen VServer mit openVZ aufgesetzt, Keyhelp installiert und auf Debian 11 geupdatet.
Leider kann ich die Zeitsychronisation nicht einschalten. Weder über Keyhelp noch über die Konsole.

systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Condition: start condition failed at Fri 2022-11-04 18:13:51 CET; 36s ago
└─ ConditionVirtualization=!container was not met
Docs: man:systemd-timesyncd.service(8)

Nov 04 16:58:30 hostname systemd[1]: Condition check resulted in Network Time Synchronization being skipped.

Ich denke, das wirst Du auf dem Host machen müssen.

Die Fehlermeldung ist ja auch recht eindeutig:

ConditionVirtualization=!container was not met.

OpenVZ ist halt keine vollwertige Virtualisierung, Du nutzt immer den Kernel des Hosts.
Und die Zeit sollte er auch daher holen.

Die Serverzeit wird im Keyhelp richtig angezeigt.
Ich habe nur Zugriff auf den VServer. Das ist ein großer deutscher Anbieter.
Das heißt also, wenn der Anbieter das nicht auf seiner Host Maschine einstellt, kann ich Keyhelp auf diesem VServer nicht nutzen? Ich habe einen anderen VServer bei demselben Anbieter mit Plesk. Da gibt es keine Probleme.

Du kannst KeyHelp natürlich auf dem Server nutzen. Allerdings gibt es unabhängig von KeyHelp Einschränkungen, wenn du nicht mit einer Vollvirtualisierung unterwegs bist - dazu gehören u.a. kein eigener Kernel und keine Zeitsynchronisierung. Beides liegt beim Server, auf dem die Container laufen.

You can not set time inside a container as the time is then set for all others too.
It should be set bij the Host-system, not in a container.

You can run NTPD inside a container, but only as time-server not to set the system-time.

IchBins wrote: ↑Fri 4. Nov 2022, 20:22 Die Serverzeit wird im Keyhelp richtig angezeigt.

Wo ist dann das Problem?

IchBins wrote: ↑Fri 4. Nov 2022, 20:22 Ich habe nur Zugriff auf den VServer.

Ach so, ich hatte das so interpretiert, dass Du auch den Host unter Kontrolle hast.

IchBins wrote: ↑Fri 4. Nov 2022, 20:22 Das ist ein großer deutscher Anbieter.

Hatte ich auch mal mit OpenVZ, bin froh dass ich das Teil wieder los bin.
Und den Provider auch, der Support scheint antiproportional fähig zur größe des Ladens zu sein …

Hoffentlich hast Du nicht den selben

Also bis jetzt bin ich mit dem Anbieter zufrieden. Ausfallzeiten gab es noch nicht. Allerdings habe ich den Support noch nicht gebraucht.
Ich hatte ein Repository angelegt um an die Daten ran zu kommen die ich umziehen will.
Aktuell ist das Problem, dass ich die Repository jeden Tag neu speichern muss um das neueste Backup zu sehen. Kann das was mit der fehlenden Zeitsynchronisierung zu tun haben? Daten habe ich noch nicht umgezogen.

Da ich den VServer bereits von Debian 10 auf 11 geupdatet habe, weiß ich leider nicht, ob das bei Debian 10 auch das Problem wäre.

Kann mir jemand sagen warum ich immer die alten Backups in der Repository sehe? Das aktualisiert sich nicht. Nur wenn ich das Repository nochmal speichere.

Wenn der Job "Integritätsprüfung / Statistiken aktualisieren" läuft, sollte anschließend alles aktualisiert sein. Läuft der etwa nicht nach einem Backup?

Oder backupst du etwa von mehreren Backup-Vorgängen (oder zwei verschiedenen Servern) in ein und das selbe Repository?

Ja aber nur wenn ich das Repository nochmal speichere. Das muss sich doch aber täglich automatisch aktualisieren.
Ich will Daten vom VServer A nach B umziehen und habe auf B das Repository von A eingespielt, damit ich an das Backup vom VServer A komme.
Bei A wird mir immer das das aktuelle Backup mit angezeigt. Bei B max. von dem Tag wo ich die Repository neu gespeichert habe.
Muss da nicht auf B das aktuelle Backup von A angezeigt werden? Das ist doch ein und dasselbe Repository.

Nein, so funktioniert das nicht. Die Daten können nicht zur Laufzeit angezeigt werden, da das nicht ausreichend performant wäre.
Die Inhalte eines Repos werden immer dann, wenn der Job "Integritätsprüfung / Statistiken aktualisieren" läuft, ausgelesen und dann in der Datenbank der jeweiligen KeyHelp-Instanz gespeichert (sieh es als eine Art Cache). Auf diese Weise stehen die Informationen fortan sofort zur Verfügung.

Der "Cache" existiert aber nur dann in aktueller Form, wenn o.g. Job gelaufen ist. Er wird automatisch z.B. nach einem Backup-Lauf gestartet (z.B. auf Server A). Der "Cache" von Server B weiß aber in dem Fall nichts davon, das zwischenzeitlich ein Backup auf Server A lief. Aus diesem Grund bleibt der Cache dort unverändert. Dem musst du dann mit einmal "Speichern" wieder auf die Sprünge helfen.

Was theoretisch gehen müsste - ACHTUNG UNGETESTET - Einfach auf Server B ein regelmäßiges Backup einrichten: Umfang "Benutzerdefiniert" und wählst dort nur "Dateien & Verzeichnisse" und gibts in der Textarea einen Pfad an, der nicht existiert.
Das Ganze time-st du so, das es nach Abschluss des Backups auf Server A läuft.
Damit triggerst du das Backup auf Server B (was tatsächlich nichts sichert) und den Statistiklauf.
Achtung, das setzt deine Snapshot-Zahl natürlich nach oben, wenn 'Maximale Anzahl von Snapshots' für das Repo gesetzt ist, sollte dieser Wert dann erhöht werden.