GFI gibt pro E-Mail-Adresse immer denselben Schluessel zurueck. Wer sich mit einer Adresse schon einmal registriert hat, bekommt beim Neuanfordern seinen alten - und ist dessen Testzeitraum abgelaufen, laesst er sich nicht aktivieren. Der Server meldet dann "License is expired", was nach einem Server- oder Netzwerkproblem aussieht, aber keines ist. Genau darauf ist die Testinstallation gelaufen: der Fehler kam schon beim ersten Aktivierungsversuch, bevor irgendetwas an der Konfiguration geaendert war. Netzwerk, DNS zum Registrierungsserver, Systemzeit und Konfiguration waren jeweils in Ordnung. Fuer einen neuen Testzeitraum braucht es also eine Adresse, mit der noch nie registriert wurde. Wegwerfadressen taugen dafuer, werden von der Anmeldeseite aber teilweise blockiert. Der Abschnitt zur Fehlersuche verweist jetzt zuerst auf die Adresse und danach erst auf die Netzwerkseite, mit pruefbaren Kommandos. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
9.5 KiB
kerio-connect-rename-user
Werkzeuge für Kerio Connect auf der Kommandozeile.
| Datei | Zweck |
|---|---|
kerio_rename_user.py |
Benutzer umbenennen — Login-Name und Mailbox-Verzeichnis im Store |
kerio_users_config.py |
Lesen und Ändern von users.cfg |
kerio_common.py |
Gemeinsame Bausteine: Admin-API-Client, Dienststeuerung |
Das Script läuft lokal auf dem Kerio-Server als root, braucht nur die
Python-Standardbibliothek und bietet --dry-run.
Getestet gegen Kerio Connect 10.0.9 patch 2 auf Debian 12.
Benutzer umbenennen
Warum das nicht trivial ist
Kerio hält den Benutzernamen an zwei Stellen, die nichts voneinander wissen:
| Wo | Was |
|---|---|
users.cfg |
Der Login-Name, in zwei Listen: User und UserAdditionalData |
| Dateisystem | <store>/mail/<domain>/<loginname>/ — die eigentliche Mailbox |
Ändert man nur den Login-Namen, sucht Kerio ab sofort im Verzeichnis mit dem neuen Namen, findet keins, legt ein leeres an — und die alten Mails liegen weiter unter dem alten Verzeichnisnamen. Typischer Anlass für eine Umbenennung: Heirat oder ein anderer Namenswechsel.
Warum nicht über die Administration API
Die API kann das nicht. Users.set nimmt ein Feld loginName entgegen und
ignoriert es stillschweigend — kein Fehler, keine Wirkung. Nachgeprüft gegen
Kerio Connect 10.0.9 mit vier Varianten (nur loginName, mit domainId, mit
leeren emailAddresses, vollständiges User-Objekt): alle wirkungslos, während
fullName im selben Aufruf sauber übernommen wird.
Deshalb arbeitet das Script direkt auf users.cfg — und braucht dadurch
keine Admin-Zugangsdaten.
Ablauf
- Vorprüfungen, bevor irgendetwas geschrieben wird:
- Domain und Benutzer in
users.cfgvorhanden? - Benutzer aus einem Verzeichnisdienst (
InternalDb=0)? → Abbruch, denn dann gehört der Name dem Verzeichnisdienst - neuer Login-Name frei und zeichenmäßig zulässig?
- Zielverzeichnis unbelegt, Quelle und Ziel auf demselben Dateisystem?
- Dienst steuerbar?
- Domain und Benutzer in
- Plan ausgeben.
--dry-runendet hier, sonst Rückfrage (--yesüberspringt). - Dienst stoppen.
users.cfgneu einlesen, Name inUserundUserAdditionalDatasetzen, atomar über eine temporäre Datei speichern.- Verzeichnisse verschieben (
mail/, undarchive/falls vorhanden). - Dienst starten und gegenlesen.
Schritte 4 und 5 liegen bewusst in einem einzigen Stopp-Fenster. Das ist keine Bequemlichkeit: Läuft Kerio zwischendurch mit nur einer der beiden Hälften, legt es die vermeintlich fehlende Mailbox sofort neu an, und man hat ein verwaistes Verzeichnis mehr. Genau das ist beim Entwickeln passiert.
Schlägt etwas fehl, werden verschobene Verzeichnisse zurückgenommen und
users.cfg aus dem Backup wiederhergestellt.
Benutzung
# Wer ist da? (kein root nötig)
./kerio_rename_user.py --list
# Erst ansehen:
./kerio_rename_user.py \
--domain firma.de \
--old-login anna.mueller \
--new-login anna.schmidt \
--full-name "Anna Schmidt" \
--dry-run
# Dann wirklich:
sudo ./kerio_rename_user.py \
--domain firma.de \
--old-login anna.mueller \
--new-login anna.schmidt \
--full-name "Anna Schmidt"
Nur den angezeigten Namen ändern, ohne Login und Verzeichnis anzufassen:
sudo ./kerio_rename_user.py --domain firma.de \
--old-login anna.mueller --full-name "Anna Schmidt"
Optionen
| Option | Bedeutung |
|---|---|
--list |
Benutzer aus users.cfg auflisten |
--domain |
Mail-Domain, z. B. firma.de |
--old-login, --new-login |
Login-Namen ohne @domain |
--full-name |
Neuer angezeigter Name |
--install-dir |
Standard /opt/kerio/mailserver |
--store-dir |
Standard /opt/kerio/mailserver/store |
--service-name |
Dienstname, Standard kerio-connect |
--service-manager |
auto, systemd, initd oder none |
--service-wait |
Sekunden Wartezeit aufs Stoppen, Standard 90 |
--dry-run |
Nur anzeigen |
--yes |
Rückfrage überspringen |
--force |
Auch bei Benutzern aus einem Verzeichnisdienst |
--service-manager none fasst den Dienst nicht an — dafür muss Kerio dann
selbst gestoppt sein, bevor das Script läuft.
Was das Script bewusst nicht anfasst
Nach der Umbenennung steht der alte Name noch an ein paar Stellen, die reine Anzeige betreffen und den Mailbetrieb nicht stören:
.personal— die vCard des Benutzers, enthält noch die alte Adresse#public/Contacts/— der Eintrag in der globalen Adressliste.caldav.db/.carddav.db— die DAV-Datenbanken
Kerio schreibt .personal beim Start teilweise selbst neu. Wer die Adresse dort
sofort korrekt haben will, korrigiert den Kontakt in der Administrationskonsole.
Kommt der alte Name in users.cfg außerhalb der Benutzerlisten vor (etwa in
einem Alias), meldet das Script das im Plan und ändert es nicht automatisch —
lieber ein Hinweis als eine kaputte Konfiguration.
Die alte Adresse nimmt nach der Umbenennung keine Mail mehr an. Wer das braucht, legt anschließend in der Administrationskonsole einen Alias an.
Hinweise
- Vorher ein Backup des Stores anlegen. Das Script verschiebt Verzeichnisse.
- Erst an einem Testbenutzer ausprobieren.
- Der Benutzer sollte während des Laufs nicht angemeldet sein.
- Nach der Umbenennung müssen sich alle Mail-Clients mit dem neuen Login neu anmelden.
- Gruppenmitgliedschaften bleiben erhalten: Kerio referenziert Gruppen über GUIDs, nicht über Namen.
Testlizenz besorgen
Der Erstkonfigurationsassistent verlangt im Schritt „Registrierte Testaktivierung"
eine Testlizenznummer samt CAPTCHA. Der Link „Lizenznummer für Testversion
erhalten" im Assistenten zeigt noch auf die alte kerio.com-Adresse und läuft
ins Leere: GFI hat die Domain auf gfi.ai umgestellt.
Die funktionierende Adresse — dort die E-Mail-Adresse eintragen, die Nummer kommt per Mail:
https://gfi.ai/products-and-solutions/email-and-messaging-solutions/kerioconnect/free-trial
Die alten Adressen www.gfi.com/.../kerio-connect/download und
gfi.ai/.../kerio-connect/download leiten inzwischen alle dorthin um.
Die Nummer lässt sich entweder im Assistenten eintragen oder später aus der laufenden Instanz heraus: Dashboard → „Become a registered trial user". Beides braucht ausgehendes HTTPS auf Port 443.
Für jeden Testlauf eine frische E-Mail-Adresse
GFI gibt pro E-Mail-Adresse dauerhaft dieselbe Trial-Nummer zurück. Wer sich mit einer Adresse schon einmal registriert hat, bekommt bei jeder weiteren Anfrage seinen alten Schlüssel — und wenn dessen 30 Tage abgelaufen sind, ist er es auch beim Neuanfordern. Der Server quittiert das mit:
registration.cpp: License error: Unable to set license (License is expired).
Das sieht nach einem Server- oder Netzwerkproblem aus, ist aber keines: Der Schlüssel ist schlicht der alte. Für einen neuen Testzeitraum braucht es eine Adresse, mit der noch nie registriert wurde.
Wegwerfadressen (trashmail.com und ähnliche) funktionieren dafür, werden von der Anmeldeseite aber teilweise blockiert — dann hilft nur ein anderer Anbieter.
Ohne Lizenz geht kein Mailbetrieb
Der Schalter ConfigWizardDone in mailserver.cfg überspringt zwar den
Assistenten und gibt Administrationskonsole und Admin-API frei — er aktiviert
aber keinen Testzeitraum. Ohne Lizenzschlüssel weisen IMAP, POP3 und Webmail
jede Verbindung ab (Server license expired beim Client, Product name does not match im Log), und error.log meldet beim Start No license key found. Eine
API zum Aktivieren gibt es nicht.
Wer den Assistenten neu durchlaufen will, setzt ConfigWizardDone zurück auf 0
oder löscht mailserver.cfg ganz — Kerio legt beim nächsten Start eine frische
an. Achtung: die Domänendefinition steht in dieser Datei, die Benutzer in
users.cfg sind danach verwaist.
mailserver.cfg und users.cfg dürfen nur bei gestopptem Dienst bearbeitet
werden. Kerio schreibt seine Konfiguration beim Beenden aus dem Speicher
zurück und überschreibt sonst jede Änderung am laufenden Dienst.
Wenn der Schlüssel abgelehnt wird
store/logs/error.log unterscheidet die Fälle — die Meldung sagt, ob der
Schlüssel ungültig oder abgelaufen ist. Bei License is expired zuerst die
E-Mail-Adresse prüfen (siehe oben), das ist die häufigste Ursache.
Erst danach lohnt die Netzwerkseite:
# Registrierungsserver erreichbar?
getent hosts secure.kerio.com # muss auflösen
getent hosts registration.kerio.com # löst NICHT mehr auf (normal)
# Uhr korrekt? Eine falsche Systemzeit lässt gültige Lizenzen ablaufen.
timedatectl
Der alte Host registration.kerio.com existiert nicht mehr; secure.kerio.com
ist der aktive Registrierungsserver.