Betreibe einen UCS-Mail Server mit Kopano (4.4-2 errata385 - und den dazu angebotenen Kopano Patchlevel).
Gestern hatte ich gesehen, dass beim UCS System-Test via Web-Management eine meldung angezeigt wurde. Lösung sollte sein, das man dieses Paket neu installiert. zu meiner Schande muss ich sagen - ich habe vergessen um welches Paket es sich gehandelt hat. Ich meine es hatte etwas mit IP und Perl zu tun.
Nach der Installation habe ich den Server neu gestartet und via MX-Tools den Mail-Empfang getestet. Leider habe ich nicht wirklich eine eMail versendet (rein/raus), da ich ansonsten gesehen hätte, dass alle Nachrichten von Postfix “festgehalten” werden.
Nachdem dann immer noch keine Nachrichten angekommen sind, habe ich mir das mail.log einmal angesehen. Hier findet man viele Nachrichten wie:
connect to 127.0.0.1[127.0.0.1]:10024: Connection refused
In der Datei mail.err findet man die folgende Meldung (passend zu dem Zeitpunkt wo ich das Paket “repariert” habe):
Dec 30 16:09:38 ucs3 spamd[7075]: Can’t locate Mail/SpamAssassin/CompiledRegexps/body_0.pm in @INC (you may need to install the Mail::SpamAssassin::CompiledRegexps::body_0 module) (@INC contains: /var/lib/spamassassin/compiled/5.024/3.004002 /var/lib/spamassassin/compiled/5.024/3.004002/auto /usr/share/perl5 /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at (eval 1609) line 1.
Habe mir nun einige Einträge im Forum angesehen - die aber leider bisher noch keine Lösung gebracht haben (u.A. Problem: Postfix Error 4.4.1 - message deferred - wo nach dem Neustart des Services sich leider die *.db Dateien dann auch nicht mehr selber neu erzeugt haben - sieht für mich erst mal so aus, als wenn das eine Verschlechterung ist).
Was kann ich tun damit die derzeit rund 200 eMails in die entsprechenden Postfächer geleitet werden?
Habe noch eine “Fehlermeldung” in mail.warn gefunden. Die ist scheinbar auch erst seit gestern da.
Dec 31 17:17:50 ucs3 kopano-spooler[517]: HrLogon server “default:” user “SYSTEM”: network error
Dec 31 17:17:50 ucs3 kopano-spooler[517]: Unable to open admin session: network error (80040115)
Dec 31 17:17:50 ucs3 kopano-spooler[517]: Server connection lost. Reconnecting in 3 seconds…
Dec 31 17:17:51 ucs3 kopano-spooler[517]: gsoap connect: ()
Dec 31 17:17:51 ucs3 kopano-spooler[517]: HrLogon server “default:” user “SYSTEM”: network error
Dec 31 17:17:51 ucs3 kopano-spooler[517]: Unable to open admin session: network error (80040115)
Dec 31 17:17:54 ucs3 kopano-spooler[517]: gsoap connect: ()
Ich gehe im Moment davon aus, dass das Problem etwas mit den benötigten *.db Dateien zu tun hat - die sich bei mir leider nicht durch einen Neustart des Services erzeugen lassen.
Solution (die bei mir nicht funktioniert hat)
The Amavis database seems to be corrupted. Fortunately this is easy to repair. Backup the old database - just in case - and delete it.
root@ucs-mail:~# systemctl stop amavis.service
root@ucs-mail:~# cd /var/lib/amavis/db/
root@ucs-mail:/var/lib/amavis/db/# tar -cjvf ~/amavis_db_backup.tar.bz2 * --remove-files
root@ucs-mail:~# systemctl start amavis.service
When you look into the /var/log/mail.log you will (hopefully) recognize how the new Amavis database is created and postfix starts to roll the e-mails.
Problem mit der Amavis Database unter “/var/lib/amavis/db”. Gehe hier davon aus, dass wenn sich der Service wieder starten lässt, auch die “*.db” Dateien wieder erzeugt werden.
Auch der “spamassassin.service” startet nicht richtig → “exited”
Fehlermeldung in der “mail.err” Datei zum Zeitpunkt seit dem es Probleme gibt
Dec 30 16:09:38 ucs3 spamd[7075]: Can’t locate Mail/SpamAssassin/CompiledRegexps/body_0.pm in @INC (you may need to install the Mail::SpamAssassin::CompiledRegexps::body_0 module) (@INC contains: /var/lib/spamassassin/compiled/5.024/3.004002 /var/lib/spamassassin/compiled/5.024/3.004002/auto /usr/share/perl5 /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at (eval 1609) line 1.
“SirTux” hatte noch einen Workaround vorgeschlagen wie erst einmal die eMail ohne den SPAM Part wieder zugestellt werden → “ucr set mail/antivir/spam=‘no’”. Ich finde jedoch in der UCS Registry hierzu keinen Eintrag:
Ja kann man. Schlimmstenfalls bewirkt er nichts. Aber probier es besser mal mit
ucr set mail/antivir=no
Die Variable ist mir gestern leider nicht aufgefallen. Sie wird vermutlich eher dazu geeignet sein das ganze Schlagenöl zu deaktivieren. mail/antivir/spam ist vermutlich nur für Spamassassin zuständig.
Eine neue eMail aus Kopano wurde nach Extern ausgeliefert. Eine externe eMail konnte in Kopano empfangen werden. Fatchmail Nachrichten funktionieren ebenfalls wieder.
Die bisher “gefangenen” (rund 250) bewegen sich jedoch nicht.
Halber Workaround - klasse und Danke schon mal dafür
Hast du mal versucht, via update_sa die Regeln vom Spamassassin neu runterzuladen?
Das klingt ein wenig danach, dass die Regeln kaputt sind. Amavis lädt diese Regeln (die Perlmodule vom Spamassassin) direkt in seinem Prozess. Sind die Regeln kaputt, kann der Amavis auch nicht starten.
