“sa-update” aus der “/” ROOT funktioniert nicht:
-bash: sa-update: command not found
Wie gesagt, ich gehe davon aus, dass dies ein Script ist. Ich finde auf meinem System aber auch keine Datei mit einem solchen Namen.
Das sollte im Paket spamassassin sein. Was ist die Ausgabe von
apt-cache policy spamassassin
?
Du könntest es auch mal mit dem vollen Pfad probieren, falls das Paket überhaupt noch installiert ist:
/usr/bin/sa-update
ucs3:/# apt-cache policy spamassassin
spamassassin:
Installed: (none)
Candidate: 3.4.2-1~deb9u2
Version table:
3.4.2-1~deb9u2 500
500 https://updates.software-univention.de/4.4/maintained/component 4.4-2-errata/all/ Packages
3.4.2-1~deb9u1 500
500 https://updates.software-univention.de/4.3/maintained 4.3-3/all/ Packages
100 /var/lib/dpkg/status
3.4.1-6+deb9u1 500
500 https://updates.software-univention.de/4.3/maintained 4.3-0/all/ Packages
3.4.0-6 500
500 https://updates.software-univention.de/4.2/maintained 4.2-0/all/ Packages
3.3.2-5.51.201502251241 500
500 https://updates.software-univention.de/4.0/maintained 4.0-2/all/ Packages
3.3.2-5.49.201502031427 500
500 https://updates.software-univention.de/4.0/maintained 4.0-1/all/ Packages
3.3.2-5.48.201409261724 500
500 https://updates.software-univention.de/4.0/maintained 4.0-0/all/ Packages
Bdeutet das " Installed: (none)", dass es nicht installiert ist?
Das Ergebnis bleibt gleich
-bash: /usr/bin/sa-update: No such file or directory
Das Paket is ja auch nicht installiert. Das Integrationspaket wird dann wohl auch nicht installiert sein?
apt-cache policy univention-spamassassin
Was passiert, wenn du versuchst es zu installieren?
univention-install univention-spamassassin
The following packages were automatically installed and are no longer required:
altermime clamav clamav-base clamav-daemon clamav-freshclam clamdscan
libarchive-zip-perl libberkeleydb-perl libclamav9 libconvert-binhex-perl
libconvert-tnef-perl libconvert-uulib-perl libio-multiplex-perl
libio-stringy-perl libjson-c3 libllvm3.8 libmime-tools-perl libmspack0
libnet-cidr-perl libnet-server-perl libtfm1 libunix-syslog-perl pax ripole
Use ‘apt autoremove’ to remove them.
The following additional packages will be installed:
libmail-dkim-perl libmail-spf-perl libnet-dns-perl sa-compile spamassassin
Suggested packages:
razor pyzor libencode-detect-perl libgeo-ip-perl libnet-patricia-perl
libbsd-resource-perl
The following NEW packages will be installed:
libmail-dkim-perl libmail-spf-perl libnet-dns-perl sa-compile spamassassin
univention-spamassassin
0 upgraded, 6 newly installed, 0 to remove and 14 not upgraded.
Need to get 1,797 kB of archives.
After this operation, 5,806 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Soll ich mit “Y” die Installation starten? Machen wir damit etwas kaputt oder nähern wir uns der Lösung der Probleme. Sorry kenne mich mit den Einzelnen Zusammenhängen überhaupt nicht aus - habe aber Vertrauen, dass Du dich damit auskennst ;-)))
Da es keine Konflikte gibt, kannst du das gefahrlos installieren.
Mich wundert nur, daß dein System das ClamAV-Schlangenöl als nicht mehr benötigt ansieht. Aber das ist ja unabhängig von deiner Installation von univention-spamassassin.
Die Installation ist ohne Fehler durchgelaufen.
Fragt man nun den Status des “spamassassin.service” ab:
ucs3:/# systemctl status spamassassin.service
● spamassassin.service - Perl-based spam filter using text analysis
Loaded: loaded (/lib/systemd/system/spamassassin.service; disabled; vendor pr
Active: active (running) since Wed 2020-01-01 15:13:04 CET; 1min 45s ago
Main PID: 9444 (spamd)
Tasks: 3 (limit: 4915)
Memory: 85.9M
CPU: 1.900s
CGroup: /system.slice/spamassassin.service
├─9444 /usr/bin/perl -T -w /usr/sbin/spamd -d --pidfile=/var/run/spam
├─9473 spamd child
└─9474 spamd child
Da dort nun “running” steht - denke ich wir sind einen Schritt weiter.
Was den Status des “amavis.service” angeht - steht dieser immer noch auf “exited” - dies auch nach einem Service STOP und START. Veränder hat sich meines erachtes jedoch, dass dorct nun “CPU: 9ms” steht - vorher war dies immer “0”.
ucs3:/# systemctl status amavis.service
● amavis.service - LSB: Starts amavisd-new mailfilter
Loaded: loaded (/etc/init.d/amavis; generated; vendor preset: enabled)
Active: active (exited) since Wed 2020-01-01 15:19:38 CET; 6s ago
Docs: man:systemd-sysv-generator(8)
Process: 9655 ExecStop=/etc/init.d/amavis stop (code=exited, status=0/SUCCESS)
Process: 9664 ExecStart=/etc/init.d/amavis start (code=exited, status=0/SUCCES
CPU: 9ms
Auch das DB-Verzeichnis ist leer - jedoch liefert der Update Befehl (sa-update) jetzte keine Fehlermeldung mehr.
Dann habe ich “Postfix” auch noch einmal durchgestartet. Die Anzahl an “gefangenen” Nachrichten ist jedoch nicht kleiner geworden.
Zusammengefasst würde ich sagen - sieht besser aus als vorher - wir sind jedoch noch nicht am Ziel.
Bis hier hin erst einmal Danke.
Findet sich noch etwas in den Logs. Eventuell solltest du das Schlangenöl auch mal wieder aktivieren:
ucr set mail/antivir=‘yes’
systemctl restart postfix
Neh das hat noch nicht funktioniert - zwei weitere Gefangene ;-(
Habe es wieder auf “NO” gestellt - dann kommen die Nachrichten wieder an.
PS: Postfix Restarts wurden jedesmal durchgeführt.
Wenn ich den einen Beitrag dazu richtig gelesen habe, dann ist es ein muss, dass in dem Verzeichnis “/var/lib/amavis/db” etwas drin steht - und das “exited” beim Service Status von “amavis.service” verschwindet.
Dann gehen wir mal weiter. Ist univention-antivir-mail installiert?
apt-cache policy univention-antivir-mail
EDIT: Vermutlich nicht, da es Spamassassin benötigt, welches wiederum nicht installiert war. Bitte dann mal installieren:
univention-install univention-antivir-mail
Gut kombiniert --> “Installed: (none)”
ucs3:/# apt-cache policy univention-antivir-mail
univention-antivir-mail:
Installed: (none)
Candidate: 9.0.0-5A~4.3.0.201811271114
Version table:
9.0.0-5A~4.3.0.201811271114 500
500 https://updates.software-univention.de/4.3/maintained 4.3-3/all/ Packages
100 /var/lib/dpkg/status
9.0.0-4A~4.3.0.201801081055 500
500 https://updates.software-univention.de/4.3/maintained 4.3-0/all/ Packages
8.0.0-2A~4.2.0.201703151919 500
500 https://updates.software-univention.de/4.2/maintained 4.2-0/all/ Packages
7.0.0-0.126.201509041259 500
500 https://updates.software-univention.de/4.1/maintained 4.1-0/all/ Packages
6.0.0-8.125.201509011531 500
500 https://updates.software-univention.de/4.0/maintained 4.0-4/all/ Packages
6.0.0-7.123.201507171159 500
500 https://updates.software-univention.de/4.0/maintained 4.0-3/all/ Packages
6.0.0-6.122.201501161909 500
500 https://updates.software-univention.de/4.0/maintained 4.0-1/all/ Packages
6.0.0-3.119.201410211750 500
500 https://updates.software-univention.de/4.0/maintained 4.0-0/all/ Packages
Folgende Zusammenfassung vor der Installation:
The following additional packages will be installed:
amavisd-new
Suggested packages:
apt-listchanges arj cabextract dspam lhasa libnet-ldap-perl libsnmp-perl
libzeromq-perl lzop nomarch p7zip rpm unrar
Recommended packages:
libnet-patricia-perl
The following NEW packages will be installed:
amavisd-new univention-antivir-mail
0 upgraded, 2 newly installed, 0 to remove and 14 not upgraded.
Need to get 37.2 MB of archives.
After this operation, 39.1 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Installation wurde mit “Y” bestätigt.
Ergebnis sieht wie folgt aus:
[ ok ] Restarting clamav-daemon (via systemctl): clamav-daemon.service.
[ ok ] Restarting spamassassin (via systemctl): spamassassin.service.
[ ok ] Restarting amavis (via systemctl): amavis.service.
[ ok ] Reloading postfix configuration (via systemctl): postfix.service.
Processing triggers for systemd (232-25+deb9u12A~4.4.0.201909191546) …
Processing triggers for man-db (2.7.6.1-2) …
Reading package lists… Done
Building dependency tree
Reading state information… Done
Die Abfrage des Service xx sieht wie folgt aus - und steht nun auf “running”:
ucs3:/# systemctl status amavis.service
● amavis.service - LSB: Starts amavisd-new mailfilter
Loaded: loaded (/etc/init.d/amavis; generated; vendor preset: enabled)
Active: active (running) since Wed 2020-01-01 17:04:03 CET; 1min 30s ago
Docs: man:systemd-sysv-generator(8)
CPU: 6ms
CGroup: /system.slice/amavis.service
├─20683 /usr/sbin/amavisd-new (master)
├─20959 /usr/sbin/amavisd-new (virgin child)
└─20960 /usr/sbin/amavisd-new (virgin child)
Im Verzeichnis “/var/lib/amavis/db” gibt es nun auch wieder Dateien:
Derzeit tauchen im “mail.log” noch bekannte Fehlermeldungen auf:
Jan 1 17:09:03 ucs3 postfix/qmgr[20731]: warning: connect to transport private/smtp-amavis: Connection refused
Jan 1 17:09:03 ucs3 postfix/error[21090]: 197A9500FC2: to=emailbackups@DOMAIN.local, relay=none, delay=4552, delays=4552/0.01/0/0.01, dsn=4.3.0, status=deferred (mail transport unavailable)
Jan 1 17:09:03 ucs3 postfix/error[21090]: 197A9500FC2: to=ANWENDER@DOMAIN.de, relay=none, delay=4552, delays=4552/0.01/0/0.02, dsn=4.3.0, status=deferred (mail transport unavailable)
In der Registry taucht nun auch wieder “mail/antivir/spam” auf
Dann setzen wir den Schalter mal wieder auf YES und starten Postfix durch:
ucr set mail/antivir=‘yes’
systemctl restart postfix
Das senden nach Extern hat funktioniert - der Empfang von Extern -sowie Fetchmail ebenfalls. KEINE weiteren Gefangenen ! ! !
Was im Moment noch nicht funktioniert, ist das die bisher gefangenen 263 eMail wieder frei kommen.
Warten - anschupsen ???
Ich würde es mal anstupsen:
postfix -f
Falls es nicht klappt: Was sagen die Logs?
Ich habe mal geschupst --> “postqueue -f”
Und ALLE 263 Nachrichten sind verschwunden. Genauer gesagt - auch die Testnachrichten die nach Extern sollten und gefangen waren - sind angekommen. Ebenso wie die eMail auf die ich seit gestern gewartet habe.
KLASSE - VIELEN DANK AN SirTux für die Geduld und fachliche Unterstützung.
Werde wohl jetzt erst einmal ein paar eMails lesen und senden ;-))
PS: Gibt es noch etwas was man prüfen sollte - oder es noch zu erledigen gibt???
1 Like
Freut mich, daß ich helfen konnte 
Ich würde mal in der nächsten Zeit verstärkt ein Auge auf die Mail-Logs werfen. Was sagen eigentlich die Univention-Checks? Wollen die wieder das Schlangenöl von der Platte werfen?
1 Like
Ja auch die Logs werde ich schauen - habe da auch noch etwas gesehen - da werde ich aber ein eigenes “Ticket” für aufmachen.
Was meinst Du mit den Univention-Checks? Univention Diagnose über die Web-App?
Genau die. Die waren ja nach deiner Aussage der Ausgangspunkt für das ganze Schlamassel. Die kannst du übrigens auch über die Shell ausführen:
univention-run-diagnostic-checks -t all
Da steht nun nichts mehr drin - auch nach einem Reboot des Servers/Systems.
eMail Test nach reboot war auch OK
Hallo - gibt wohl doch noch eine “Restarbeit” zu erledigen.
Seitem nun zwei Tagen erhalte ich jeden Morgen gegen 7:00 eine eMail mit folgenden Informationen (Fehlern) von dem betroffenen Server/System. Da die eMail echt lang ist, hier (ersteinmal) nur ein Auszug:
Einer eine Idee was man dagegen tun kann?
Vielen Dank vorab.
Bisher habe ich hierzu leider keine Rückmeldung mehr erhalten. Werden diesen Task nun schließen und einen neuen aufmachen - zur Reduzierung von unnötigen eMails 