Lonesome Walker

Da ich gerade an einer Migration von Exchange 2010 (von einem SBS2011, wird ja ab 2020 nicht mehr supported…) auf Kerio Connect sitze, und aber auch wirklich GAR NICHTS klappt, hier für Alle ein Lösung, die das auch mal machen müssen.

Möglichkeit 1 (die Leichteste):
Einfach das KEMT (Kerio Exchange Migration Tool) verwenden.
Schritt 1: alten Exchange angeben, Admin-Konto vom Exchange, bestätigen.
Nochmal den FQDN des Exchange angeben, prüfen klicken. Klappt die Namensauflösung, dann passen die Zugangsdaten für die Migration.
Schritt 2: IP oder Hostname des neuen Kerio Mailservers eingeben.
Wenn hier keine Fehlermeldung kommt, alles paletti.
Dann die Postfächer auswählen, die migriert werden sollen, und schon saugt er aus dem Exchange die Adressen in den Kerio.
Gematcht wird anhand der Emailadresse.

Da Möglichkeit 1 wie so oft ja zu einfach ist, und bei einer Migration von lediglich 10 Postfächern zu mehr als 3.000 Fehlern führte, und er bei 6 gleichzeitig laufenden Threads sich festgefressen hat, bin ich also Möglichkeit 2 angegangen:
Alles wie vorher, aber diesmal nur ein Konto.

Selbes Resultat, an irgendwelchen Emails verschluckt er sich ja immer…
Okay, dann gehen wir mal die Möglichkeit 3 an:
KEMT soll nur die „Groupware“ Daten synchronisieren.
(wenn das Tool das nicht mal schafft, dann kann man es eh wegkloppen…)
Zuerst also mit einem Postfach getestet, klappt.
Dann mit 3 gleichzeitig, auch noch okay.
Bei den restlichen 6 hat er dann ca. 330 Errors geworfen, aber irgendwo ist ja leider immer Schwund, denn auch einzeln hat er nach und nach die Fehler gebracht.

So, jetzt sind ja schon mal die Kontakte, Kalender und auch sonst alles drüben.
Fehlen nur noch die Emails.

Ich habe ja ganz am Anfang auch schon das stumpfe Importieren von PST-Dateien probiert, welche ich zuvor aus dem Exchange exportiert habe.
(wie das geht -> Google)
Schadet zwar als Backup nicht, hat sich aber für Kerio anders als bei Exchange als Zeitverschwendung herausgestellt.
Outlook stürzt bei PST-Dateien größer als 1GB mit dieser Import-Methode (Kerio Connector) permanent ab.

Na dann, für die Emails haben wir doch das gute alte imapsync.
Mittlerweile auf github verfügbar, also schnell gezogen, alle Abhängigkeiten (eine Latte an Perl-Modulen) installiert, und schon klappt es auch mit der Synchronisation von Exchange nach Kerio.
Beim Exchange erst IMAP4 aktivieren (Dienste), gucken das die User auch IMAP als Postfachfunktion haben, und dann in der Organisationsgeschichte zu IMAP auch Plaintext zulassen.
Zugegeben: sollte man nur hausintern machen, aber da kann ja jeder dann entsprechend auch die SSL/TLS Parameter für den Sync angeben.

So, und dann läuft das tatsächlich durch.

Leider ist man als Telekom-Kunde ja viel Schmerzen gewohnt, und so kommt es auch öfters vor, daß einem die SSH-Sitzung wegstirbt.

Wenn dann nach einem erneuten Login mit apt-get upgrade nochmal versucht wird, den Aktualisierungsprozeß abzuschließen, erhält man oft:
debconf: DbDriver "passwords" warning: /var/cache/debconf/passwords.dat is locked by another process: Die Ressource ist zur Zeit nicht verfügbar
debconf: DbDriver "templatedb": /var/cache/debconf/templates.dat is locked by another process: Die Ressource ist zur Zeit nicht verfügbar

Ja, viele schreiben dann, man soll einfach dpkg –configure -a machen, und gut ist.
Oder erneut apt-get update && apt-get upgrade.

Ja, was aber tun, wenn das nichts wird?

Die Fehlermeldung ist ja eigentlich auch eindeutig: es gibt noch einen Prozeß, der die Datei gelockt hat.
Daher getrost die ganzen Pseudo-Profis ignorieren, und mit:
ps faxuww
erhält man schön strukturiert aufgelistet, was so alles an Prozessen läuft.
Da sucht man sich dann die letzte SSH-Sitzung, die zwar weg ist aber leider noch immer läuft.
Vorne dran steht die Prozess-ID, welche wir dann mit kill xxxx abschiessen.
Das {xxxx} bitte durch die eigene ID ersetzen.
Wichtig ist auch, den richtigen Prozess zu killen, d.h. nicht die einzelnen Prozesse des Updates, sondern den Mutterprozess.

Und schon klappts auch mit apt-get upgrade wieder 😉

Gerade auf einem frischen Debian:


root@debian:~# df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sdb1 176G 1,1G 166G 1% /
udev 10M 0 10M 0% /dev
tmpfs 13G 9,0M 13G 1% /run
tmpfs 32G 0 32G 0% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 32G 0 32G 0% /sys/fs/cgroup
/dev/sda1 33T 20K 31T 1% /raid


Wie kann das sein, daß bei 33TB Disksize und 20k Belegung bereits 1% verwendet ist, und nur noch 31TB zur Verfügung stehen?