kerio_tui.py fuehrt durch Umbenennung und Uebernahme, ohne dass man
Parameter kennen muss: Benutzer und Domains kommen zur Auswahl, verwaiste
Mailbox-Verzeichnisse findet der Assistent selbst, und vor dem Ausfuehren
zeigt er den gleichwertigen Kommandozeilenaufruf. Nur curses aus der
Standardbibliothek, keine neue Abhaengigkeit.
Beim Durchfahren ueber ein PTY kamen zwei Dinge heraus:
keypad(True) loest die Pfeiltasten auf diesem Server nicht auf - getch()
liefert 27, 91, 66 statt KEY_DOWN, wofuer ein unpassendes terminfo
genuegt. Das fuehrende ESC haette als "zurueck" gegolten und den
Assistenten bei jedem Pfeildruck verlassen. Er loest die Sequenzen jetzt
selbst auf; ein einzelnes ESC wirkt weiterhin als Abbruch.
Und: Bricht die Verbindung weg, waehrend Kerio gestoppt ist, stirbt das
Script an SIGHUP und laesst den Dienst unten - genau so passiert, als der
Testtreiber die Verbindung schloss. ServiceController.abgesichert() faengt
SIGHUP, SIGTERM und SIGINT ab und startet den Dienst wieder, bevor der
Abbruch durchgereicht wird. Gegen den Testserver geprueft: Signal mitten
im Stopp-Fenster, Dienst kommt hoch, Daten unberuehrt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die alte Formulierung sprach vom Zusammenfuehren, das gar nicht zur
Debatte steht, und liess offen, was mit dem bestehenden Postfach
passiert. Sie sagt jetzt direkt, wohin es umbenannt wird und dass nichts
geloescht wird.
In der README steht dazu, warum nicht zusammengefuehrt wird: Kerio fuehrt
eigene Indexdateien, die beim Hineinkopieren fremder Mails nicht mehr
passen wuerden, waehrend das Verschieben eines vollstaendigen
Verzeichnisses sie mitnimmt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
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