KeyHelp: Updates, Patch-Manager und automatische Aktualisierungen planen

KeyHelp hält sich und die Serverdienste selbst aktuell. Wann das passiert und was genau dabei installiert wird, steuern Sie an zwei Stellen: unter „Wartungsintervalle“ für Panel-Updates und Systempakete, im „Patch-Manager“ für kleine Korrekturen zwischen zwei KeyHelp-Versionen. Diese Anleitung zeigt, welche Aufgaben ab Werk laufen, wie Sie Zeitfenster sinnvoll legen, wie Sie einen Patch einspielen und wie Sie in den Logdateien auf dem Server nachsehen, was tatsächlich installiert wurde. Alles haben wir in einer Test-VM real ausgeführt, inklusive eines echten Paket-Updates. Grundlage ist ein Server wie in KeyHelp installieren und absichern.

Voraussetzungen

• KeyHelp-Server mit Admin-Zugang, getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.15.
• Root-Zugang per SSH oder Konsole, um die Logdateien zu lesen.
• Aktuelles Backup vor jedem Eingriff, zum Beispiel wie in KeyHelp-Backup extern mit Restic. Paket-Updates lassen sich nicht per Klick zurücknehmen.

Schritt 1: Die Update-Aufgaben unter „Wartungsintervalle“ kennen

Öffnen Sie im Menü unter „Einstellungen“ den Punkt „Wartungsintervalle“. Die Tabelle zeigt für jede Aufgabe „Ist aktiviert“, „Letzter Lauf“, „Intervall“, „Zeitfenster“ und „Aktionen“. Für Updates zuständig sind drei Zeilen:

• „Control Panel aktualisieren“: „Hält das Control Panel auf dem neuesten Stand und installiert neuere Versionen, sobald sie veröffentlicht werden.“ Ab Werk: 1 Tag, von 03 bis 04 Uhr. Die KeyHelp-Knowledge-Base (Stand 2018) nennt hier noch „Alle 30 Minuten, 02 - 04 Uhr“, das traf auf unsere Version 26.1.1 nicht mehr zu.
• „Server-Dienste aktualisieren“: laut Beschreibung „apt update & apt upgrade“. Ab Werk: 2 Tage, von 03 bis 04 Uhr.
• „PHP-Interpreter aktualisieren“: hält die zusätzlichen PHP-Interpreter aktuell. Ab Werk: 1 Tag, von 05 bis 06 Uhr.

Die Uhrzeiten beziehen sich auf die Serverzeit. Das Dashboard zeigte in unserer VM „(Etc/UTC)“, 03 Uhr Serverzeit ist dann in Deutschland 05 Uhr im Sommer. Prüfen Sie die dort angezeigte Zeitzone, bevor Sie Zeitfenster planen.

KeyHelp steuert alle Aufgaben über einen einzigen Cronjob, der jede Minute läuft und dann entscheidet, welche Aufgabe fällig ist. Die Einstellungen aus der Oberfläche stehen in der Datenbank:

mysql keyhelp -e "select id,name,is_active,\`interval\`,interval_unit,timeframe_start,timeframe_end from maintenance_intervals"

id	name	is_active	interval	interval_unit	timeframe_start	timeframe_end
1	update	1	1	minute	0	0
2	diskspace	1	1	hour	0	0
3	panel-update	1	1	day	3	4
4	statistic	1	1	hour	0	1
5	package-update	1	1	day	2	3
9	php-update	1	1	day	5	6

Die Ausgabe zeigt den Stand nach Schritt 3 (Paket-Update auf 1 Tag, 02 bis 03 Uhr). Die Datenbank enthielt zusätzlich die Zeile ssh-chroot-update, die in der Oberfläche nicht erscheint. Verifizieren: In der Crontab steht nur der Master-Cronjob */1 * * * * root nice -n 5 php /home/keyhelp/www/keyhelp/cronjob/mastercronjob.php, die einzelnen Aufgaben finden Sie dort nicht. Alle übrigen Wartungsaufgaben und das manuelle Starten per keyhelp run beschreibt KeyHelp-Wartungsintervalle: keyhelp run manuell auslösen.

Schritt 2: Den Hinweis auf dem Dashboard richtig lesen

Im Kasten „Anwendungen“ auf dem Dashboard zeigte unsere frische VM: „Aktualisierungen für 1 Software-Pakete sind verfügbar.“ Der Link „(Warum sehe ich diesen Hinweis?)“ erklärt, dass KeyHelp bestimmte Aktualisierungen zurückhält, weil sie „möglicherweise die Funktionalität der installierten Dienste“ beeinträchtigen, und dass Sie diese „mit dem Konsolenbefehl apt dist-upgrade selbst installieren“ können.

Der Hinweis bedeutet aber nicht automatisch, dass etwas zurückgehalten wurde. In unserer VM war das Paket einfach noch nicht dran, weil „Server-Dienste aktualisieren“ noch nie gelaufen war (die Spalte „Letzter Lauf“ war leer). Prüfen Sie das auf der Konsole:

apt list --upgradable 2>/dev/null

Listing...
libexpat1/oldstable-security 2.5.0-1+deb12u4 amd64 [upgradable from: 2.5.0-1+deb12u3]

Verifizieren: Nach dem Lauf aus Schritt 3 stand im selben Kasten „Die Software auf Ihrem Server ist auf dem neuesten Stand.“ und apt list --upgradable lieferte nur noch „Listing...“.

Unter dem Hinweis zeigte das Dashboard in unserer VM außerdem, dass Debian 12 den regulären Support verlassen hat („Ende des Supportzeitraums: Juni 2026“, „Ende des erweiterten Supportzeitraums: Juni 2028“). Wie Sie auf Debian 13 wechseln, beschreibt KeyHelp: Debian 12 auf 13 upgraden.

Schritt 3: Zeitfenster und Intervall anpassen

Klicken Sie in der Zeile „Server-Dienste aktualisieren“ auf den Stift („Bearbeiten“). Der Dialog „Einstellungen bearbeiten“ enthält „Ist aktiviert“, „Intervall“ (Zahl plus „Minuten“, „Stunden“ oder „Tage“) und unter „Zeitfenster“ die Felder „Beginn des Ausführungszeitraums“ und „Ende des Ausführungszeitraums“ (volle Stunden). Wir haben das Intervall auf 1 Tag und das Fenster auf 02 bis 03 Uhr gesetzt und mit „Speichern“ übernommen.

Legen Sie Panel- und Paket-Update nicht in dieselbe Stunde, wenn Sie bei Problemen nachvollziehen wollen, welcher Lauf was verursacht hat. Ein Fenster „von 00 bis 00 Uhr“ verwenden die Aufgaben, die rund um die Uhr laufen, etwa „Aufgaben abarbeiten“. Laut KeyHelp-Dokumentation bezieht sich die Ausführung bei gleicher Start- und Endstunde „auf den ganzen Tag“.

Verifizieren: Die Tabelle zeigt danach „1 Tag“ und „von 02 bis 03 Uhr“, in der Datenbank steht die Zeile package-update mit 1 day 2 3 (Ausgabe in Schritt 1).

Schritt 4: Ein Update sofort auslösen und das Ergebnis prüfen

Statt auf das Zeitfenster zu warten, klicken Sie in der Zeile auf das Play-Symbol „Jetzt starten“. Die Zeile zeigt dann „Startet in Kürze“. In unserem Test startete der Lauf mit dem minütlichen Master-Cronjob um 21:19:01 Uhr und dauerte zehn Sekunden. Was KeyHelp tut, steht im Log der Aufgabe:

grep -E "INFO \| (update|upgrade|remove|update composer)" /var/log/keyhelp/cronjob/package-update.log

[2026-10-01 21:19:02] INFO | update package list...
[2026-10-01 21:19:04] INFO | upgrade installed packages...
[2026-10-01 21:19:10] INFO | remove unused packages...
[2026-10-01 21:19:10] INFO | update composer...

Im vollständigen Log steht die apt-Ausgabe. In unserem Lauf wurden zwei Pakete aktualisiert, nicht nur das eine aus dem Dashboard-Hinweis:

The following packages will be upgraded:
  libexpat1 rspamd
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Rspamd kommt bei KeyHelp aus dem Paketquellen-Eintrag /etc/apt/sources.list.d/rspamd.list des Rspamd-Projekts. Der Paketlauf hat Rspamd also ohne Rückfrage von 4.2.0 auf 4.2.1 gehoben. Den genauen Verlauf zeigt das dpkg-Log:

grep -E " upgrade " /var/log/dpkg.log

2026-10-01 21:19:05 upgrade libexpat1:amd64 2.5.0-1+deb12u3 2.5.0-1+deb12u4
2026-10-01 21:19:06 upgrade rspamd:amd64 4.2.0-1~6268f47~bookworm 4.2.1-1~b7a16ae~bookworm

Für „Control Panel aktualisieren“ funktioniert „Jetzt starten“ genauso. In unserer VM gab es keine neuere KeyHelp-Version, das Log sagt das klar:

cat /var/log/keyhelp/cronjob/panel-update.log

[2026-10-01 21:21:01] INFO | maintenance connection okay
[2026-10-01 21:21:01] INFO | trying to connect to updateserver
[2026-10-01 21:21:01] INFO | current version is up to date, no update needed.

Verifizieren: „Letzter Lauf“ zeigt in beiden Zeilen die neue Uhrzeit, keyhelp version meldet weiterhin KeyHelp : 26.1.1 (Build 3698). Ein echtes Versions-Update von KeyHelp konnten wir mangels neuer Version nicht beobachten.

Schritt 5: Patches im Patch-Manager einspielen

Zwischen zwei KeyHelp-Versionen veröffentlicht Keyweb kleine Korrekturen. Sie finden sie unter „Konfiguration“, „Patch-Manager“ im Kasten „Verfügbare Patches“. Die Oberfläche erklärt: „Alle Patches sind optional und werden im nächsten großen KeyHelp-Update integriert.“ Jede Zeile nennt Datum, eine englische Beschreibung und die Zahl der geänderten Dateien. Unter „Details“ stehen die betroffenen Dateipfade.

Lesen Sie die Beschreibung vollständig. Einige Patches brauchen einen Nachschritt, der Patch vom 25. August 2026 etwa „run keyhelp-toolbox, then select Clear template cache“, der vom 14. September 2026 ein erneutes Speichern eines E-Mail-Kontos. Wir haben den Patch vom 14. September 2026 angehakt und „Speichern“ geklickt. Die Meldung lautete „Die Einstellungen wurden aktualisiert. Die Änderungen werden in wenigen Augenblicken wirksam.“ Eingespielt wird der Patch beim nächsten Lauf von „Aufgaben abarbeiten“:

grep -n "26-1-1" /var/log/keyhelp/cronjob/update.log

162:[2026-10-01 21:18:01] INFO | Installed patch "26-1-1-rspamd-account-settings"

Verifizieren: Die Datei aus „Details“ hat sich geändert, vorher 11819 Byte mit Datum 23. Juli, danach:

-rw-r--r-- 1 keyhelp keyhelp 12115 2026-09-14 13:17:18.000000000 +0000 /home/keyhelp/www/keyhelp/core/Email/Rspamd/Rspamd.php

Im Patch-Manager steht der Patch danach ohne „Installieren“-Haken, der Tooltip am Symbol lautet „Installiert“. Eine Schaltfläche zum Entfernen eines Patches haben wir nicht gefunden. Den in der Patch-Beschreibung verlangten Nachschritt (E-Mail-Konto speichern) haben wir nicht ausgeführt.

Schritt 6: Wissen, was KeyHelp nicht automatisch tut

Zwei Punkte sollten Sie im Betrieb kennen:

• Kein unattended-upgrades: KeyHelp nutzt für Systempakete seine eigene Aufgabe, nicht das Debian-Paket. dpkg -l unattended-upgrades lieferte „dpkg-query: no packages found matching unattended-upgrades“, und apt-config dump | grep -i periodic gab nichts aus. Deaktivieren Sie „Server-Dienste aktualisieren“, fehlt in einer solchen Installation nach unserem Befund jede automatische Paketaktualisierung. Das Deaktivieren selbst haben wir nicht getestet.
• Kein dist-upgrade: Laut Beschreibung der Aufgabe führt KeyHelp apt dist-upgrade nicht automatisch aus. Bleibt der Dashboard-Hinweis nach einem Lauf stehen, prüfen Sie mit apt list --upgradable, welche Pakete betroffen sind, und spielen Sie diese bewusst in einem Wartungsfenster ein.

Verifizieren: apt-config dump | grep -i periodic endet ohne Ausgabe mit Exitcode 1, es ist also keine APT::Periodic-Automatik konfiguriert. Die Debian-Timer apt-daily.timer und apt-daily-upgrade.timer liefen in unserer VM zuletzt um 09:19 Uhr Serverzeit. Laut /var/log/dpkg.log wurden an diesem Tag aber erst durch den KeyHelp-Lauf um 21:19 Uhr Pakete aktualisiert.

Typische Fehler

• Leeres Intervall gespeichert: Wir haben das Feld „Intervall“ geleert und gespeichert. Es kam keine Fehlermeldung, die Tabelle zeigte danach „0 Tage“, in der Datenbank stand interval 0. Prüfen Sie nach jedem Speichern die Spalte „Intervall“. Was Intervall 0 im Betrieb bewirkt, zeigt KeyHelp-Wartungsintervalle: keyhelp run manuell auslösen.
• Beginn nach Ende: „Beginn“ 05 und „Ende“ 02 nahm KeyHelp ohne Warnung an, die Tabelle zeigte „von 05 bis 02 Uhr“. Ob das als Fenster über Mitternacht gilt, haben wir nicht geprüft. Bleiben Sie bei Fenstern innerhalb eines Tages.
• Patch gespeichert, aber nicht sofort aktiv: Nach „Speichern“ ist der Patch erst nach dem nächsten Lauf von „Aufgaben abarbeiten“ installiert. Ist diese Aufgabe deaktiviert, passiert nichts.
• Zeitfenster in Ortszeit gedacht: Läuft der Server in UTC, starten Updates zwei Stunden später als erwartet (Sommerzeit). Die Serverzeit steht auf dem Dashboard unter „Serverzeit“.

Häufige Fragen

Kann ich automatische KeyHelp-Updates ganz abschalten?

Ja, über den Haken „Ist aktiviert“ im Dialog der Aufgabe „Control Panel aktualisieren“. Getestet haben wir das Abschalten nicht, weil keine neue Version vorlag. Lassen Sie die Aufgabe besser aktiv und legen Sie das Zeitfenster in eine ruhige Stunde.

Wo sehe ich, was sich in einer neuen KeyHelp-Version ändert?

Der Link „Änderungsprotokoll“ neben der Versionsnummer im Dashboard führt auf changelog.keyhelp.de.

Startet „Jetzt starten“ auch außerhalb des Zeitfensters?

Ja. Im Test lief „Server-Dienste aktualisieren“ um 21:19 Uhr Serverzeit, „Control Panel aktualisieren“ um 21:21 Uhr, obwohl beide Zeitfenster nachts lagen.

Werden Dienste nach dem Paket-Update neu gestartet?

Für Rspamd haben wir nach dem Update systemctl is-active rspamd geprüft, Ergebnis active. Ob und wann andere Dienste neu starten, hängt vom jeweiligen Debian-Paket ab, das haben wir nicht systematisch untersucht.

Wie informiere ich Kunden vor größeren Arbeiten?

Dafür bietet KeyHelp den „Wartungsmodus“ unter „Konfiguration“ und die Funktion „E-Mail an alle Benutzer“. Beides war nicht Teil dieses Tests.

Testumfang

Wir haben in KeyHelp 26.1.1 auf Debian 12.15 Zeitfenster und Intervall geändert, „Server-Dienste aktualisieren“ und „Control Panel aktualisieren“ per „Jetzt starten“ ausgelöst und einen Patch real eingespielt. Auffällig: Der Paketlauf hob auch Rspamd auf eine neue Version, leere Intervalle speichert KeyHelp ohne Warnung. Nicht geprüft: ein echtes KeyHelp-Versions-Update, Läufe im geplanten Zeitfenster und Fenster über Mitternacht. Kontrollieren Sie nach dem ersten geplanten Lauf die Logs.

Fazit

KeyHelp nimmt Ihnen Panel- und Paket-Updates ab, Sie bestimmen nur Intervall und Zeitfenster. Der Patch-Manager schließt einzelne Fehler, bevor die nächste Version kommt, verlangt aber manchmal einen Nachschritt. Verlassen Sie sich nicht auf die Oberfläche allein: Die Logs unter /var/log/keyhelp/cronjob/ und /var/log/dpkg.log zeigen, was wirklich installiert wurde, auch Pakete aus fremden Paketquellen wie Rspamd.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern
• KeyHelp-Wartungsintervalle: keyhelp run manuell auslösen
• KeyHelp: Debian 12 auf 13 upgraden
• KeyHelp-Backup extern mit Restic einrichten
• Automatische Sicherheitsupdates mit unattended-upgrades
• KeyHelp Knowledge Base: Panel-Aufgaben-Intervalle
• KeyHelp-Änderungsprotokoll
• Keyweb: KeyHelp, alle Funktionen im Überblick