ubuntuusers.de

Spamassassin Probleme

Status: Ungelöst | Ubuntu-Version: Server
Antworten |

CyrrelSneer

Anmeldungsdatum:
22. Dezember 2007

Beiträge: Zähle...

Wohnort: Kiel / Flensburg

Hallo,

ich hoffe ich kann hier Hilfe zu einem Debia 4 System erlangen... und zwar habe ich eine Virtuelle Maschine bei einem Hoster gemietet, der auch seit Monaten super läuft inkl. clamav und eben spamassassin. Seit dem letzten Update (habe es vorher entweder übersehen - was ich nicht glaube - oder es ist wirklich neu) finde ich jedoch folgende Fehlermeldungen in /var/log/mail.log:

spamd[9565]: bayes: expire_old_tokens: locker: safe_lock: cannot create tmp lockfile /root/.spamassassin/bayes.lock.XXXX.9565 for /root/.spamassassin/bayes.lock: Permission denied
spamd[9565]: bayes: cannot write to /root/.spamassassin/bayes_journal, bayes db update ignored: Permission denied
spamd[9565]: mkdir /root/.spamassassin: Permission denied at /usr/share/perl5/Mail/SpamAssassin.pm line 1530
spamd[9565]: locker: safe_lock: cannot create tmp lockfile /root/.spamassassin/auto-whitelist.lock.XXXX.9565 for /root/.spamassassin/auto-whitelist.lock: Permission denied
spamd[9565]: auto-whitelist: open of auto-whitelist file failed: locker: safe_lock: cannot create tmp lockfile /root/.spamassassin/auto-whitelist.lock.XXXX.9565 for /root/.spamassassin/auto-whitelist.lock: Permission denied
spamd[9565]: bayes: locker: safe_lock: cannot create tmp lockfile /root/.spamassassin/bayes.lock.XXXX.9565 for /root/.spamassassin/bayes.lock: Permission denied

Nun habe ich versucht über Google etwas schlauer zu werden und rausgefunden, dass der SpamAssassin scheinbar unter root läuft und das nicht okay ist.

Also habe ich folgende Schritte unternommen:

1. neuen Benutzer anlegen (hier: spamd) 2. Ordner /home/spamd/bayes erstellt via mkdir bayes 3. Dateien aus /root/.spamassassin in /home/spamd/bayes kopiert 4. Rechte der Dateien in /home/spamd/bayes angepasst (chown nobody und files mit chmod 666) 5. in /root/confixx/safe/spamassassin.inc folgende zeilen eingefügt:

bayes_path /home/spamd/bayes/bayes auto_whitelist_path /home/spamd/bayes/auto-whitelist bayes_file_mode 777 auto_whitelist_file_mode 777

6. Spamassassin neugestartet mit /etc/init.d/spamassassin stop

Was jedoch glaube ich fehlt ist die Angabe, dass der Dienst immer als Benutzer "nobody" startet... In einer Anleitung habe ich für ein Suse-System folgendes gefunden:

The command rcspamd start -u nobody does NOT work to pass -u nobody !!! rcspamd gets the additional arguments from the file /etc/sysconfig/spamd. To permanently start spamd each time as user nobody, we ADD the argument -u nobody in file: /etc/sysconfig/spamd - change / ADD argument to run spamd as user "nobody":

# Default is "-d -c -L"
SPAMD_ARGS="-d -x -u nobody"

jedoch weiß ich nicht, wo diese Einstellung bei meinem Debian vorzunehmen ist.

Kann mir jemand evtl. sagen ob ich so auch richtig vorgegangen bin und wie ich den Dienst nun unter nobody starte?

Vielen Dank für die Hilfe

otzenpunk Team-Icon

Avatar von otzenpunk

Anmeldungsdatum:
17. Oktober 2005

Beiträge: 8691

Wohnort: Hamburg-Altona

CyrrelSneer schrieb:

bayes_file_mode 777
auto_whitelist_file_mode 777

Mal generell: Dateirechte 777 sind eigentlich immer viel zu viel. Im besten Fall unnötig, im schlimmsten Fall gefährlich.

Was jedoch glaube ich fehlt ist die Angabe, dass der Dienst immer als Benutzer "nobody" startet...

Ich dachte, du wolltest ihn als Benutzer "spamd" laufen lassen?

In einer Anleitung habe ich für ein Suse-System folgendes gefunden...

Die Startskripte und Konfiguration von Suse unterscheidet sich zum Teil fundamental von der auf debian-basierten Systemen. Das Verzeichnis /etc/sysconfig, unter Suse-Systemen zentral, existiert unter debian-basierten Systemen z.B. gar nicht. Ein beliebter Ort unter Debian (und Ubuntu), um Kommandozeilenargumente für Daemons zu setzen, ist eher /etc/default. Ich würde mich aber vorher lieber informieren, warum der spamd unter Debian standardmäßig überhaupt als Root läuft. Das hat bestimmt einen Grund. Ist ja nicht so, dass das Konzept der Rechtetrennung unter Debian-Maintainern völlig unbekannt ist.

Antworten |