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>
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>
duffyduckandClaude Opus 5