Dies ist das Archiv zu der Kategorie 'Debian'.

froxlor und opendkim unter Debian

Abgelegt unter Debian, IT, Postfix, Sicherheit am 14.03.2021

Nur damit ich das nächste Mal nicht wieder suchen muß woran es liegt…

/etc/default/opendkim

RUNDIR=/var/run/opendkim
SOCKET=inet:8891@localhost
USER=opendkim
GROUP=opendkim
PIDFILE=$RUNDIR/$NAME.pid
EXTRAAFTER=

/etc/opendkim.conf

Syslog yes
UMask 007
Socket inet:8891@localhost
PidFile /var/run/opendkim/opendkim.pid
OversignHeaders From
TrustAnchorFile /usr/share/dns/root.key
UserID opendkim
# Hier der Zusatz für froxlor
SigningTable dsn:mysql://froxlor:{hierdaspwddesfroxlorusersohneklammern}@localhost/froxlor/table=panel_dkim_domains?keycol=domain?datacol=id

KeyTable dsn:mysql://froxlor:{hierdaspwddesfroxlorusersohneklammern}@localhost/froxlor/table=panel_domains?keycol=id?datacol=domain,concat('dkim_',dkim_id),dkim_privkey

Dann nicht vergessen, die View für die Abfrage anzulegen:

mysql -u froxlor -p froxlor -e 'create view panel_dkim_domains as select id,domain from panel_domains where dkim=1;'

Kennwort des froxlor-Benutzers eingeben, done.

Und weil dann der Service ja noch immer nicht hochkommt, denn da fehlen ja noch paar Pakete:

apt-get install opendkim
apt-cache search libmemcached
apt-cache search libopendbx
apt-cache search libvbr2
apt-cache search librbl
apt-cache search libopendkim

Alle entsprechenden Pakete installieren (opendkim sollte ja schon als Erstes installiert gewesen sein), bei libopendbx auch das mit MySQL nicht vergessen.


Exchange 2010 zu Kerio Connect

Abgelegt unter Debian, Nightshift, SSL am 28.10.2019

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.


Bei apt-get upgrade unterbrochen, .dat is locked by another process

Abgelegt unter Allgemein, Debian am 29.11.2017

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 😉



blog powered by wordpress
Design by Office and IT - Business Solutions
Optimiert durch suchmaschinen-freundlich