Fuer den Fall, dass der alte Benutzer schon geloescht und der neue von
Hand angelegt wurde - dann liegt nur noch das Verzeichnis herum. users.cfg
bleibt unangetastet, es wandert allein das Verzeichnis.
Geprueft wird vorher, dass der Zielbenutzer existiert und der alte nicht
mehr; gibt es ihn noch, verweist das Script auf die normale Umbenennung.
Hat das Ziel schon ein Verzeichnis mit Mails, bricht es ab - mit --force
wird das bestehende als <name>.abgeloest-<zeitstempel> beiseitegeschoben
statt geloescht.
Die Zielpruefung arbeitet jetzt als Folge statt paarweise: bei der
Uebernahme raeumt der erste Schritt das Ziel, das der zweite belegt. Eine
isolierte Pruefung haette das als Konflikt gemeldet.
Dazu die Kontaktkarte: .personal traegt Namen und Adresse des vorherigen
Eigentuemers. Sie wird jetzt umgeschrieben statt entfernt - Kerio legt sie
naemlich nicht neu an, wenn sie fehlt, weder beim Neustart noch bei einer
Aenderung ueber die Admin-API. Das gilt auch fuer die normale Umbenennung,
wo bisher die alte Adresse stehenblieb.
Beides gegen den Testserver verifiziert: nach der Uebernahme sieht der
Zielbenutzer alle Mails samt Unterordnern und Flags, die Kontaktkarte
stimmt, users.cfg ist unveraendert und neue Mail wird zugestellt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Mit aktiver Lizenz und laufendem IMAP laesst sich jetzt pruefen, was
vorher offen bleiben musste: ob Kerio die verschobene Mailbox auch
ausliefert.
Ein Benutzer mit gefuellter Mailbox (5 Mails in der INBOX, eine davon
gelesen, eine markiert, dazu eine Mail in einem Unterordner) wurde
umbenannt. Danach: Login mit dem neuen Namen funktioniert, mit dem alten
wird er abgewiesen, alle Mails und Flags sind da, die .eml-Dateien sind
bitgleich, und eine frisch gesendete Mail an die neue Adresse wird
zugestellt, waehrend die alte Adresse mit 550 Mailbox does not exist
antwortet. Kein verwaistes Verzeichnis, GUID und Passwort-Hash
unveraendert.
Geaendert haben sich nur Kerios Index- und Statusdateien, die der Server
ohnehin bei jedem Zugriff neu schreibt.
Der Testnachweis steht als Tabelle in der README.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
Das Script hat den Erstkonfigurationsassistenten zwar zuverlaessig
uebersprungen, aber nicht das eigentliche Ziel erreicht: der Schalter
ConfigWizardDone gibt nur Administrationskonsole und Admin-API frei und
aktiviert keinen Testzeitraum. Ohne Lizenzschluessel bleiben IMAP, POP3
und Webmail gesperrt, damit taugt der Weg nicht fuer echten Mailbetrieb.
An seiner Stelle steht jetzt ein README-Abschnitt mit der Adresse, die
tatsaechlich funktioniert. Der Link im Assistenten zeigt noch auf
kerio.com; GFI hat auf gfi.ai umgestellt, und alle alten Download- und
Trial-Adressen leiten auf
https://gfi.ai/products-and-solutions/email-and-messaging-solutions/kerioconnect/free-trial
Dazu zwei Punkte zur Fehlersuche, falls ein Schluessel abgelehnt wird:
error.log unterscheidet zwischen ungueltig und abgelaufen ("License is
expired"), und registration.kerio.com ist nicht mehr aufloesbar, waehrend
secure.kerio.com es noch ist.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Test gegen einen echten Server (Kerio Connect 10.0.9 patch 2) hat
gezeigt, dass Users.set das Feld loginName stillschweigend ignoriert -
kein Fehler, keine Wirkung, waehrend fullName im selben Aufruf sauber
uebernommen wird. Vier Varianten geprueft (nur loginName, mit domainId,
mit leeren emailAddresses, vollstaendiges User-Objekt): alle wirkungslos.
Der bisherige Ansatz konnte also gar nicht funktionieren.
Der Login-Name steht in users.cfg, und zwar in zwei Listen: User und
UserAdditionalData. Beide verweisen ueber Name+Domain statt ueber die
Guid, beide muessen mit, sonst verliert der Benutzer seine
Passworthistorie. Geaendert wird der Rohtext, damit Formatierung und
unbekannte Felder unangetastet bleiben.
users.cfg und Store-Verzeichnis wandern jetzt in EINEM Stopp-Fenster.
Laeuft Kerio zwischendurch mit nur einer Haelfte, legt es die
vermeintlich fehlende Mailbox sofort neu an - beim Entwickeln genau so
passiert. Damit entfaellt auch der Admin-Zugang: das Script braucht
keine Zugangsdaten mehr, --list zeigt die Benutzer aus der Datei.
Ausserdem gefunden: itemSource heisst 'DSInternalSource', nicht
'Internal' wie angenommen - die alte Pruefung haette bei jedem lokalen
Benutzer faelschlich abgebrochen. Die Erkennung laeuft jetzt ueber
InternalDb in users.cfg.
Tests fuer beide Haelften unter tests/.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
kerio_trial_setup.py bringt eine frische Installation am Assistenten
vorbei, wenn dessen Lizenzschritt nicht durchlaufbar ist: der Link
"Im unregistrierten Modus aktivieren" fehlt je nach Version und die
verlinkte Registrierungsseite ist seit der GFI-Uebernahme teils tot.
Gesetzt wird ConfigWizardDone in mailserver.cfg; Kerio laeuft danach
30 Tage unregistriert, ohne Einschraenkung bei Benutzerverwaltung und
Admin-API.
Die Datei darf nur bei gestopptem Dienst bearbeitet werden, weil Kerio
seine Konfiguration beim Beenden aus dem Speicher zurueckschreibt. Das
Script stoppt den Dienst, liest danach neu ein, schreibt atomar ueber
eine temporaere Datei und liest den Wert nach dem Start zur Kontrolle
erneut. Backup vor jeder Aenderung, --restore spielt es zurueck.
API-Client und Dienststeuerung wandern nach kerio_common.py, damit
beide Scripts sie teilen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Benennt einen Benutzer vollstaendig um: Login-Name und voller Name ueber
die Administration API, dazu das Mailbox-Verzeichnis im Store auf der
Platte. Kerio zieht das Verzeichnis beim Aendern des Login-Namens nicht
mit, sodass der Benutzer sonst eine leere Mailbox vorfindet.
Ablauf: Vorpruefungen (Benutzer vorhanden, neuer Name frei, kein
LDAP-Benutzer, Verzeichnis vorhanden und Ziel frei, gleiches Dateisystem,
Dienst steuerbar), dann Users.set, Dienst stoppen, Verzeichnisse
verschieben, Dienst starten. Verschoben werden mail/ und archive/.
Scheitert das Verschieben, werden bereits verschobene Verzeichnisse
zurueckgenommen und der Login-Name zurueckgesetzt, damit Konfiguration
und Platte konsistent bleiben.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
duffyduckandClaude Opus 5