Clamav

Home » CentOS » Clamav
CentOS 14 Comments

Every time I update my system with clamav, it doesn’t restart and freshclam no longer works, because of a permission issue on the log directory. Each time I update clamav I have to search the Internet to figure out what there is to do. That NEVER helps so I try different combinations on user and group in amavis-new and clamav configuratio files, until I eventually get them both to work.

I am getting clamav and amavisd update from the epel repo. What can I do to prevent this from happening?

Emmett

14 thoughts on - Clamav

  • I have same issue, and i have after each update change permissions of /var/log/clamav and /var/lib/clamav to amavis.amavis.

    Filip Bartmann

  • “It turns out that the EPEL version uses user ‘clam’ while the RPMforge version uses user “clamav”.”
    and
    “Now – i’ve removed all instances of Clam and any trace from /etc /var including users and groups and added the EPEL version afresh.”

    from:
    https://bugzilla.redhat.com/show_bug.cgi?idy4945

    Internet search engines ARE your friend!

  • I first tried removing all of clamav and amavisd and reinstalling again from EPEL. That turned out to be worse as I could never get the permissions right for the /var/share/amavis/tmp directory.

    So I removed it all again and reinstalled from RPMforge. Now it all works as expected. I never should have switch from RPMforge to EPEL for these programs.

    Thanks for the bug report.

    Emmett

  • I’ve been looking for that bug report for at least a couple of years. Thanks!

    I removed clamd, clamd and amavisd-new and all their parts, then re-installed from EPEL, then added some special rules from the old amavisd.conf file to the new. Now it all works as expected.

    And yes, clamd, clamav and amavisd-new were all originally installed from RPMforge.

    Emmett

  • That’s not a bug. Mysterious and broken behavior are expected when you mix components from uncoordinated repositories. And when you have multiple 3rd party repositories enabled for yum, packages with the same name will update from whichever has the newest version. Yum doesn’t care that updating from a different repo than the package was originally installed from is likely to actually get a somewhat different and incompatible package – it only cares about the name and version number.

  • I kinda feel like I’m either a big weenie or complete slacker;
    I just fought with the cron scripts, checking perms and which user owned what/should own what.. and then added chown -R
    to the top of them.

  • I did that, and still clam failed to filter mail. I do admin that I didn’t delete “all” related files before installing from EPEL, ANsd I do also feel that EPEL is the better choice, so I guess I’ll do it all over again.

    Emmett

  • I don’t think just installing the package makes it filter mail. If you want to really start from scratch you might try mimedefang to drive all your scanning/filtering, especially if you are running sendmail and can write some perl snippets to control it.

  • or `mailscanner`, which also requires significant setup, but offers a wide range of features, including running spamassassin, clamav, etc.

  • I haven’t used mailscanner, but mimedefang is particularly efficient because it hooks to all of the sendmail milter phases separately with a pool of connections so it doesn’t to keep a big extra process running for each delivery in progress and it unpacks the attachments once and runs all the scanners (if you haven’t rejected already on some other criteria).

  • Way up in this thread, you mentioned updating amavisd-new from epel plus clam\* from epel. In addition to the user clamav vs clam issue, epel amavisd uses service clamd.amavisd, whereas the rpmforge amavisd uses service clamd.

    # rpm -q amavisd-new clamd postgrey amavisd-new-2.8.0-8.el6.noarch clamd-0.98.3-1.el6.i686
    postgrey-1.34-1.el6.noarch

    # service clamd status clamd is stopped

    # service clamd.amavisd status clamd.amavisd (pid 2860) is running…

    The use of clamd.amavisd actually simplifies the setup since you don’t need to add group amavis to clam.

    # id clam uidI3(clam) gidI3(clam) groupsI3(clam)

    Looking through my rpmforge > epel conversion notes, the other significant issue was to find folders/files with owner:group clamav:clamav and chown to clam:clam. I think you already corrected that problem.

    There are also several differences in the default rpmforge vs epel amavisd.conf, but I don’t think any would stop it from working.

    I converted 3 mail servers to epel amavisd/clam\* about a year ago and I
    think all conversion issues have been resolved, but you never know. :-)

    Steve

  • Sorry, I quit trying to get sendmail to do what I needed many years ago. I’ve found postfix to be much easier to configure and extend.

    I’ve put my system back to using rpmforge repo for clamd and amavisd-new and my email system is back to running flawlessly, We’ll see what happens next time there is an update.

    Emmett

  • Hmm. Since EPEL provided and installed clamd and amavisd-new packages without error, I assumed they were the correct packages. I’ll leave my system to use RPMforge, at least until the next time I update those packages.

    Thanks for all the input.

    Emmett

  • But that is the beauty of mimedefang. You add most of the control in the milter, in the form of perl scripting. You can leave the stock sendmail.mc with only a few changes for your site and to hook the milter in.