Magam is nehezen hiszem, de úgy tűnik, hogy végre végleg, hákolás nélkül megoldódik a spamassassin para. Nem tudom, hogy kerülte el a figyelmemet a következő két kapcsoló:
-u username, –username=username
Run as the named user. If this option is not set, the default behaviour is to setuid() to the user running „spamc”, if „spamd” is running as root. Note: „–username=root” is not a valid option. If specified, „spamd” will exit with a fatal error on startup.
-g groupname, –groupname=groupname
Run as the named group if –username is being used. If this option is not set when –username is used then the primary group for the user given to –username is used.
Fellelési helye: „man spamd”. Néha nem árt doksit olvasgatni.
Update: Azért a dolog nem ilyen egyszerű, a –username=… beállítással nyakadba kapod azt a problémát, hogy a spamd által forkolt child process nem tud írni az adott user home-jába (hiszen nem setuid fut, hanem egy tökmás user nevében), ezért ha a spamd a –create-prefs kapcsolóval indul, akkor emailenként 3 hibát biztos dob. Megoldás: –create-prefs kiszedése a /etc/default/spamassassin-ból. (És persze pl. –username=amavis beleírása.)
Update 2: Még egy dolgot kell kiszedni, ez pedig az AutoWhitelist. Az ok ugyanaz: mivel amavis-ként fut a spamassassin, nem tudja írni/olvasni az user mail home-jában található személyes autowhitelisteket. A /etc/spamassassin/v310.pre file-ban ezt kommenteztem ki:
loadplugin Mail::SpamAssassin::Plugin::AWL
Nem vagy egyedül a dologgal. Eddig én is userként futtattam, másoltam, kavartam.
Nem hittem, hogy ennyire egyszerű a megoldás. :-) Köszönet.