Posted on the Centos list originally. I believe this is a bug in the amavis package and maybe the clamav package.
On 01/31/2013 07:05 AM, Ned Slider wrote:
On 31/01/13 11:17, Robert Moskowitz wrote:
On 01/31/2013 02:30 AM, John Hinton wrote:
On 1/30/2013 5:05 PM, Robert Moskowitz wrote:
On 01/30/2013 04:31 PM, Nicolas Thierry-Mieg wrote:
Robert Moskowitz wrote:
I should probably find either the amavis or clam list(s) and take this there?
<snip> > Oh, I have not applied the updated policy rpms that Dan Walsh pointed me > to. This is all 'out of the box' rpms, following the amavis/clamav > recommendations from: http://wiki.centos.org/HowTos/Amavisd is it? so your rpms come from rpmforge? I thought you mentioned epel at some point. Hopefully you're not mixing them?
Sorry, I followed the HowTo, but got all the rpms from epel.
If you are, then that might be your problem. If you really followed the wiki instructions you must be using RF packages, so you could take it to the RF list. And if you're using epel, then you didn't follow the wiki instructions but nevertheless you should take it to the epel list...
epel list. Hmm. Now to find that.
Thanks for the direction.
Read near the top of the amavis config file. It will reference the directories you are having trouble with. It tells you to create them and that they need to be owned by whatever you set the amavis user to be. It is all right there in the conf file.
Yes, I read that.
amavis from the epel repo defaults to /var/spool/amavisd which is owned by amavis:amavis with permissions 700.
The rpm created the subdirs under this of quarantine, tmp, and db also owned by amavis:amavis with permissions 700. I had to create var myself for spamassassin to use.
The permissions problem is under /var/spool/amavis/tmp if you look at the maillog entry. I have altered all permissions to 750 and still have the problem; the directory created is with 700, and perhaps that is why the problem?
Permissions should be 750 as the clamav user is a member of the amavis group and needs group access.
So this is one bug for epel, as the rpm creates the directories with the wrong permissions. Either do it right, or leave to the installer. So I just changed all the amavis directories to 750 and restarted both amavisd and clamd and it worked this time! I thought I did the restart back before the rebuild, but maybe I didn't or I had other things configured wrong. So this IS a bug in the packaging for me to submit to epel.
I am thinking to change the clamd conf files to run with user amavis instead of clam and see if that gets around the problem...
That will likely cause other problems. The clamav user just needs to be a member of the amavis group.
That was my initial read, but as my frustration was rising, it looked like a way to troubleshoot the problem. So now I don't have to try this.
I have joined the epel-devel list (I did not find an epel-users list) and posted this there yesterday. I see that epel repo is the same version currently available from rpmforge that the howto uses. Interestingly, rpmforge uses userid clamav and epel uses userid clam. Don't know what other differences there are. So far no replies on the epel list.
As you have seen there are differences between the packages. This makes the CentOS documentation worthless to you as you are not using the same versions used in the documentation.
I had hopes that the 'official' packaging would work well, particularly now that both are on the same release. I really wanted to do this all 'official' packages. I know there is nothing wrong with rpmforge, I use it for a number of things, just this time around for mail, I was shooting for 'fully supported cruft'. Shows how good that approach takes!
You should take this thread, and your issue, to the EPEL list as it really has nothing to do with CentOS.
Well I have and will post this there as well and submit the bug report. I have two on these packages so far. I started here as I did not know where best to take it (for example an amavis or clamav list?) but more becuase I was hoping that there would be Centos users that have worked with these packages and might be kind enough to share their insights.
And thank you for your help.
epel-devel@lists.fedoraproject.org