[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

F8 (and FX?]: Sendmail, Spamassassin, and Spamass-Milter issues.




Folks,

I have updated my F8 system and my spamassassin/spamass-milter
have crapped out.  Here is what I found, with no resolution:

1) Entries in: /etc/mail/sendmail.mc
=============================================================
INPUT_MAIL_FILTER(`clamav-milter', `S=local:/var/run/clamav-milter/clamav.sock, F=,T=S:4m;R:4m')dnl INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass-milter/spamass-milter.sock, F=,T=C:15m;S:4m;R:4m;E:10m')dnl
define(`confINPUT_MAIL_FILTERS', `spamassassin,clamav-milter')dnl
=============================================================

2) Entries in: /etc/sysconfig/spamass-milter
=============================================================
No changes needed because the default spamass-milter socket is:
   /var/run/spamass-milter/spamass-milter.sock
and no options needed either.
=============================================================

3) With sendmail stopped, maillog cleared, and when spamass-milter starts:
[root linux mail]# service spamass-milter start
Starting SpamAssassin milter (spamass-milter):             [  OK  ]
[root linux mail]#  tail -f /var/log/maillog:
=============================================================
Dec 2 12:10:24 linux sendmail[10575]: mB2KAOt9010575: from=sa-milt, size=195, class=0, nrcpts=1, msgid=<200812022010 mB2KAOt9010575 linux cdkkt com>, relay=sa-milt localhost Dec 2 12:10:24 linux sendmail[10575]: mB2KAOt9010575: to=root, ctladdr=sa-milt (487/478), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30195, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1] Dec 2 12:10:34 linux sendmail[10583]: mB2KAYI8010583: from=sa-milt, size=195, class=0, nrcpts=1, msgid=<200812022010 mB2KAYI8010583 linux cdkkt com>, relay=sa-milt localhost
=============================================================
So, everything appears to be normal, right?  Oh wait!
=========
Notice this:
=========
# ls -l /var/run/spamass-milter/spamass-milter.sock
ls: cannot access /var/run/spamass-milter/spamass-milter.sock: No such file or directory

YOU CANNOT START SPAMASS_MILTER IF THERE IS NO PREVIOUS
SOCKET INSTALLED NOR WILL IT INSTALL ONE!  DANG!! THE SERVICE
DOES NOT CHECK TO MAKE SURE A SOCKET EXISTS AND SPEW NO
ERROR IF THERE IS NO SOCKET?

If you attempt to start sendmail, IT WILL FAIL. IT WILL REFUSE TO START.

Seems I might have a way out, let's see.  Lets see if we can MANUALLY
start it:
# /usr/sbin/spamass-milter -p '/var/run/spamass-milter/spamass-milter.sock' -f
<no error is reported on the command line> and of course the log information
in maillog simply says 'connection refused' since sendmail is not running.
But wait: is spamass-milter running?  really??
# pgrep spamass-milter
14339
14814
Oh gawd - two of 'em running!?!?  Nope, won't do.  Kill them with:
# service spamass-milter stop
[Displays stop results]
# pgrep spamass-milter
[nothing displayed, great]
# /usr/sbin/spamass-milter -p '/var/run/spamass-milter/spamass-milter.sock' -f
[nothing displayed, great]
# pgrep spamass-milter
14973
Geez.  Finally - I have ONE spamass-milter running.

4) Starting sendmail:
=============================================================
[root linux spamass-milter]# service sendmail start
Starting sendmail: 451 4.0.0 /etc/mail/sendmail.cf: line 1714: Xspamassassin: local socket name /var/run/spamass-milter/spamass-milter.sock unsafe: Permission denied [FAILED]
Starting sm-client:                                        [  OK  ]
[root linux spamass-milter]#
=======================

Say what?  Permissions problem!?  Let's see:

[root linux spamass-milter]# ls -lZ /var/run/spamass-milter/spamass-milter.sock srwxr-xr-x root root unconfined_u:object_r:var_run_t:s0 /var/run/spamass-milter/spamass-milter.sock

Oh man. Seems that starting the spamass-milter improperly creates the sockets with the wrong security context and assigns root ownership? Perhaps things are different
were it started as a service? Dunno, but moving on...

Ok, well, let's see if we can fix the security context:

[root linux spamass-milter]# restorecon -v '/var/run/spamass-milter/spamass-milter.sock' restorecon reset /var/run/spamass-milter/spamass-milter.sock context unconfined_u:object_r:var_run_t:s0->system_u:object_r:spamd_var_run_t:s0

Interesting.  Why did running spamass-milter create and unconfined_u and
var_run_t security context for it's socket?

Let's check the directory holding this socket:
[root linux dant]# ls -lZd /var/run/spamass-milter/
drwxr-xr-x sa-milt sa-milt system_u:object_r:var_run_t:s0 /var/run/spamass-milter/

Looks good to me. I did this so that I'd have a reference for later on
when the sendmail and it's milters start running...

Ok, let see if we can get sendmail started once again:
[root linux spamass-milter]# service sendmail start
Starting sendmail:                                         [  OK  ]

Yeah. that seemed to work... so let see what the maillogs
and message logs says"

[root linux mail]#  tail -f /var/log/maillog:
=============================================================
Dec 2 12:15:51 linux sendmail[10873]: alias database /etc/aliases rebuilt by dant Dec 2 12:15:51 linux sendmail[10873]: /etc/aliases: 91 aliases, longest 25 bytes, 1101 bytes total Dec 2 12:15:51 linux sendmail[10878]: starting daemon (8.14.2): SMTP+queueing 01:00:00 Dec 2 12:15:52 linux sm-msp-queue[10887]: starting daemon (8.14.2): queueing 01:00:00
============================================================vvvvvvvvvvvvvvv
Dec 2 12:15:53 linux sendmail[10889]: mB2KFqPe010889: Milter (spamassassin): error connecting to filter: Connection refused by /var/run/spamass-milter/spamass-milter.sock Dec 2 12:15:53 linux sendmail[10889]: mB2KFqPe010889: Milter (spamassassin): to error state
===============================================================^^^^^^^^

But notice this, from /var/log/messages:
=============================================================
Dec 2 13:38:44 linux setroubleshoot: SELinux is preventing sendmail (sendmail_t) "connectto" to /var/run/spamass-milter/spamass-milter.sock (unconfined_t). For complete SELinux messages. run sealert -l 83175cb8-f9dd-4451-af8a-122502520e54
=============================================================

Huh? I just fixed the security context earlier when I manually started spamass-milter, so why does SELinux *think* that the socket still has the "unconfined_t" security
context?

Let's see: Let's restart the setroubleshoot service, perhaps it is `out of sync'?

[root linux dant]# service setroubleshoot restart
Stopping setroubleshootd:                                [  OK  ]
Starting setroubleshootd:                                  [  OK  ]

Looking at the logs again, the darn thing (setroubleshoot) SHUT UP!
No more alerts to spamass-milter socket!

But DANG!!  There is another problem.... in /var/log/maillog:
=============================================================
Dec 2 13:51:03 linux sendmail[15554]: mB2Lp2UC015554: Milter (spamassassin): error connecting to filter: Permission denied
=============================================================
What filter are they talking about? Is it a sendmail or spamassasin (or spamass-milter)
issue?

I am not at this point even sure what is going on nor what the consequences of ignoring this error message would mean. Perhaps someone could care to comment? Seems to me that there are no other error messages reported except for repeated and interspersed "Permission denied" errors similar to the above log message and it appears every time
a new message comes in.

Alas - after coming this far, if the system reboots - all bets are off and I'd
have to go though this whole scenario again.  Perhaps someone could take
a look at it and get it fixed (assuming it is not some stupid configuration issue
on my part)?

Thanks,
Dan


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]