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

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

 




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
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux