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@xxxxxxxxxxxxxxx>, 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@xxxxxxxxxxxxxxx>, 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
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
