Sometimes i'm asking myself who the fuck is releasing some totally bugged packages… After several trials here what you need to do to get the EPEL clamav to run on CentOS 7:

yum install clamav-milter-systemd clamav-scanner-systemd clamav-update
cp /etc/clam.d/scan.conf /etc/clamd.d/clamd.conf

edit /etc/clamd.d/clamd.conf

LogSyslog yes
DatabaseDirectory /var/lib/clamav
TCPSocket 3310
TCPAddr 127.0.0.1
User clamscan
AllowSupplementaryGroups yes

Start it and enable for reboot

systemctl restart clamd@clamd.service
systemctl enable clamd@clamd.service

edit then /etc/mail/clamav-milter.conf

MilterSocket inet:7357
User clamilt
AllowSupplementaryGroups yes
ClamdSocket tcp:127.0.0.1:3310
LogSyslog yes
OnClean Accept
OnInfected Reject
OnFail Defer

start the milter now and on reboot

systemctl restart clamav-milter
systemctl enable clamav-milter

Sometimes saslauthd crashes randomly without leaving a trace in the logs. The downside of this is that users can't send emails then and any other service using the daemon for authentication will not authenticate. This was on our CentOS 5 x64 box.

saslauthd uses 5 threads as a default option and gives you the ability to start it with a different number of threads. We changed that number some time ago and until now there haven't been any crashes. Here what the manpage says:

-n threads
Use threads processes for responding to authentication queries. (default: 5) A value of zero will indicate that saslauthd should fork an individual process for each connection. This can solve leaks that occur in some deployments.

Now, how do we change that number? Here on a CentOS box:

* open /etc/sysconfig/saslauthd with your editor (e.g. vim, nano etc)
* change the line FLAGS="" to FLAGS="-n 0" and save the file
* now restart the saslauthd service

That resolved our crashes.

Hello, if you use a site with high security settings, the site's services are chrooted to the virtual file system. Usually the mysql socket file is hardlinked inside the virtual site but in my case this stopped working once and the socket is not linked correctly, resulting in the website not finding the database server.

Now there are several workarounds for that:

1. Do NOT use localhost to connect but use localhost.localdomain or 127.0.0.1
2. edit your /etc/init.d/mysqld script and add following line(s) just before the "return $ret" line in the start() section:

   for dir in `ls -d /home/virtual/site*`;
       do rm -f $dir/fst/var/lib/mysql/mysql.sock;
       ln $socketfile $dir/fst/var/lib/mysql/mysql.sock 2> /dev/null;
   done