Bug 495502

Also looks like in 0.95, clamav-milter requires a separate clamd server running.

Looks like this is my mistake.

Are you able to test some things on your system? And can you tell me your 
architecture, so that I could provide some packages which should fix that?

Yes.  i386.

Can you please test, whether the following packages are solving your issues?
That clamav package is rebased from Rawhide and also ships the separate clamd
server etc. and should work: http://robert.fedorapeople.org/pub/clamav/

They don't provide a clean upgrade path:

--> Running transaction check
---> Package clamav-filesystem.i386 0:0.95.1-1.1.el5 set to be updated
---> Package clamav-update.i386 0:0.95.1-1.1.el5 set to be updated
---> Package clamav-data.i386 0:0.95.1-1.1.el5 set to be updated
--> Processing Dependency: clamav-milter = 0.94.2-1.el5 for package: clamav-milter-sysv
---> Package clamav-milter.i386 0:0.95.1-1.1.el5 set to be updated
---> Package clamav-lib.i386 0:0.95.1-1.1.el5 set to be updated
--> Finished Dependency Resolution
clamav-milter-sysv-0.94.2-1.el5.i386 from installed has depsolving problems
  --> Missing Dependency: clamav-milter = 0.94.2-1.el5 is needed by package clamav-milter-sysv-0.94.2-1.el5.i386 (installed)
Error: Missing Dependency: clamav-milter = 0.94.2-1.el5 is needed by package clamav-milter-sysv-0.94.2-1.el5.i386 (installed)


I think the problem is the rename from clamav-milter-sysv -> clamav-milter-sysvinit.  If you want to do this you will need the proper Obsoletes/Provides pairs.

If you run createrepo on your pub/clamav directory this will be easier to test.

Now hopefully the createrepo works, because of remote run as fedorapeople.org
hasn't createrepo installed. The Obsoletes/Provides pairs for upgrading should
work as they're the same as on Rawhide.

Provides are not correct:

# rpm -q --provides -p clamav-milter-sysvinit-0.95.1-1.1.el5.i386.rpm
config(clamav-milter-sysvinit) = 0.95.1-1.1.el5
init(clamav-milter) = sysvinit
milter-sysv = 0.95.1-1.1.el5
clamav-milter-sysvinit = 0.95.1-1.1.el5

# rpm -q --obsoletes -p clamav-milter-sysvinit-0.95.1-1.1.el5.i386.rpm
milter-sysv < 0.95.1-1.1.el5

Should be "clamav-milter-sysv".

You're right, following from Rawhide and rebased spec file is wrong:

Provides: milter-sysv = %version-%release
Obsoletes: milter-sysv < %version-%release

But can you please use --force/--nodeps to RPM for now to test, whether
the real issue with clamav is solved?

I really want to test a proper upgrade, no rpm shenanigans.

Okay, updated packages of clamav are there but have the same ENVRA, means you
maybe need to run a "yum clean all" or similar. I'm also around in IRC, if you
would like to speed up things.

Where in IRC? (Sorry, not much of an IRC user)

It is not killing my previous clamav-milter process:

clamilt  17186     1  0 09:04 ?        00:01:21 clamav-milter -ql --max-children=10 -c /etc/clamd.d/milter.conf local:/var/run/clamav-milter/clamav.sock

Killed that by hand.  Then:

Starting clamav-milter: ERROR: Please configure the MilterSocket directive
                                                           [FAILED]

Uncommented:

MilterSocket /var/run/clamav-milter/clamav-milter.socket

and:

LogFacility LOG_MAIL

so I could get log messages to /var/log/maillog, which is expected I believe.

Then:

Apr 13 13:23:14 earth clamav-milter[4491]: No ClamdSocket specified
Apr 13 13:23:14 earth clamav-milter[4491]: Failed to init the socket pool

It is also not pulling in clamav-server.  I suppose this is reasonable, but this is probably going to break some EL setups like mine that didn't have a clamd server before.  Anyway, not at all what I expect in a EPEL "upgrade".

Other:

Looks likes the new clamav-milter script defaults to on:

< # chkconfig:   345 99 1

I thought the packaging standard was for the service to default to off:

> # chkconfig: - 79 40

Tried to setup clamd server (first time), but still getting:

Apr 13 13:45:57 earth clamav-milter[6256]: Failed to initiate streaming/fdpassing
Apr 13 13:45:57 earth clamav-milter[6256]: No clamd server appears to be available

changed 

MilterSocket /var/run/clamav-milter/clamav-milter.socket

to

MilterSocket /var/run/clamav-milter/clamav.sock

to match previous config.

clamd seems okay:

Apr 13 13:42:22 earth clamd[5844]: Loaded 1039466 signatures.
Apr 13 13:42:22 earth clamd[5844]: LOCAL: Unix socket file /var/run/clamd.clamd/clamd.sock
Apr 13 13:42:22 earth clamd[5844]: LOCAL: Setting connection queue length to 15
Apr 13 13:42:22 earth clamd[5845]: Limits: Global size limit set to 104857600 bytes.
Apr 13 13:42:22 earth clamd[5845]: Limits: File size limit set to 26214400 bytes.
Apr 13 13:42:22 earth clamd[5845]: Limits: Recursion level limit set to 16.
Apr 13 13:42:22 earth clamd[5845]: Limits: Files limit set to 10000.
Apr 13 13:42:22 earth clamd[5845]: Archive support enabled.
Apr 13 13:42:22 earth clamd[5845]: Algorithmic detection enabled.
Apr 13 13:42:22 earth clamd[5845]: Portable Executable support enabled.
Apr 13 13:42:22 earth clamd[5845]: ELF support enabled.
Apr 13 13:42:22 earth clamd[5845]: Mail files support enabled.
Apr 13 13:42:22 earth clamd[5845]: OLE2 support enabled.
Apr 13 13:42:22 earth clamd[5845]: PDF support enabled.
Apr 13 13:42:22 earth clamd[5845]: HTML support enabled.
Apr 13 13:42:22 earth clamd[5845]: Self checking every 600 seconds.

ClamAV is unluckily broken by design and development in many ways, thus the 
Fedora maintainer isn't interested in having such stress and problems at EPEL - 
at least from what I know. Maybe you can show up at Freenode #fedora-devel, 
then we can look to that.

ClamAV updates are unluckily not always working smoothly as expected for EPEL,
but that's the risk, if you use ClamAV, not all things can be solved downstream.

So what are the necessary changes to make the update more well for you?

I understand some of the clamav issues.  However, I've upgraded from clamav 0.92-4 through to 0.94.2-1 without trouble before.  I understand that 0.95 looks to have some major changes.  All the more reason to tread carefully.

At the moment I'd be happy with just getting the damn thing to work at all.

Okay, looks like in the config files the default clamd socket file names are different (.sock vs .socket):

./clamav-0.95.1/etc/clamd.conf:LocalSocket /var/run/clamd.<SERVICE>/clamd.sock       

./clamav-0.95.1/etc/clamav-milter.conf:#     ClamdSocket unix:/var/run/clamd/clamd.socket                                                                                 


So that was my problem.

Thank you in advance for digging that much into. Now let's try to get this
into a clamav package, yes?

I'm assuming, that .sock is correct, while the .socket is a mistake (I just
can see .sock everywhere, let me know, if I am maybe wrong here).

What changes are now exactly neccessary for you to get the -1.1 working? I
guess, I should be able to apply all of these things to the clamav package.

Well, not matter what, changes will have to be made because of the new separate clamd architecture.  I'm also not sure at this point how much my config has different from the default.  Big confusion though was that the milter config file location has changed from /etc/clam.d/milter.conf to /etc/mail/clamav-milter.conf, but my /etc/sysconfig/clamav-milter file still named the old location.

Orion, I would put the following tasks on my list for clamav:

1. Rebase the current 0.95.1-1 from Rawhide to EPEL as -2
2. Disable clamav-milter initscript by default again as before
3. Correct milter-sysv provides/obsoletes pair as mentioned
4. Writing a few words of milter changes in README.fedora file

What is still open to me is, whether the requirement you mentioned
in comment #12 from clamav-milter to clamav-server is really needed?
From what I can see, I would say, this is not required, you "just"
had that milter configuration file relocation/change issue, right?

And changing configuration file from /etc/clam.d/milter.conf ->
/etc/mail/clamav-milter.conf including the modifications is up to
the user/administrator, I would say.

Even -2 will fix some of the issues, it's not what others and I are
expecting for an EPEL upgrade, yes. Unlucky thing is, that many of
the EPEL users are expecting to keep clamav up-to-date and not only
to backport security fixes, but getting the new features as well.

Further objections from your side before/when working at -2 soon?

init script for clamav-milter is broken too:

- points to /usr/share/clamav/clamd-wrapper which is not runnable
- expects CLAMD_SERVICE to be set but is set nowhere
- CLAMD_SERVICE is broken in init script logic (ie when trying to run with this option unset, namin schema and parametrs does not work, if is set to something, the naming logic is broken outside of the script / config file etc).

Same problem here. If you need help in testing the new packages I'm here.

I never got clamav working out-of-the-rpm on any redhat/fedora distro.

Milan and Simone, have you been able to try clamav-0.95.1-1.1 (if you're on
i386)? See: http://robert.fedorapeople.org/pub/clamav/ and please let me know;
also if you need x86_64 to test. I would say, -1.1 should solve comment #20/21.

Eddie, do you have a general problem or a specific one? Looks like a general
one for me so far except you're more precise.

I could test some x86_64 packages. Do you have them built somewhere?

clamav-0.95.1-1.1 packages for i386 and x86_64 are in the URL of comment #23,
now.

Milan, Simone, Thomas - can you test them regarding the issues you're seeing?
Note, that if you already use clamav-milter, the configuration file has moved 
and changed because of upstream changes. The README.fedora of clamav-milter is
providing some more details.

(In reply to comment #23)

> Eddie, do you have a general problem or a specific one? Looks like a general
> one for me so far except you're more precise.  

General.

The path's and file names for clamd en clamav-milter in their corresponding config files never have been suitable for out-of-the-rpm usage.

See comment #16

Regards,

Edddie.

Eddie, comment #16 is caused by 0.94->0.95 and changed milter stuff. The 
configuration files, clamav itself ships with the RPM packages should have 
working paths. If not, please show me an applying example - thank you.

Still quite a mess. The update doesn't install cleanly because of a circular
dependency between clamav-milter and clamav-milter-sysv. I had to remove both
to install the new version. Then after getting clam.scan running, clamav-milter
keeps logging "No clamd server appears to be available" even though I specified
both the socket and a tcp connection to 127.0.0.1 as options. Not sure why that
is happening.

Thomas, "yum install clamav-scanner" edit /etc/clamd.d/scan.conf, remove 
"Example" and start the service. Then edit /etc/mail/clamav-milter.conf and
set "ClamdSocket unix:/var/run/clamd.scan/clamd.sock" there and restart the
milter service. Whatever you're using for MilterSocket is up to you and what
your mail setup wants to see (e.g. when communicating with sendmail).

Do you have the yum output of the circular dependency somewhere so that you
could paste it?

Unfortunately, my scrollback buffer is filled with various logs so I can't look back at the rpm dependency problems. I have "ClamdSocket unix:/var/run/clamd.scan/clamd.sock" and still clamav-milter can't seem to connect to it. I'll try a complete reinstall of clamav to see if that helps.

I completely removed and reinstalled clamav and still have the same problem:

Apr 14 13:43:03 blackstar clamav-milter[20878]: No clamd server appears to be available 

Turns out it's a permissions problem. /var/run/clamd.scan is created 711 and owned by clamscan.clamscan so clamav-milter, running as clamilt, can't read the socket because of the directory permissions. I added clamilt to the clamscan group to fix it. 

Now that I have it supposedly running, it still doesn't seem to be scanning the mail.

I guess the default for adding scanned headers has changed. Enabling it makes things seem to work as they did before. So I appear to have it all working. The biggest problem was the permissions on the /var/run/clamd.scan directory.

Okay, Thomas. So what did you change (ScanMail option?) to enable e-mail
scanning? How did you change the permissions on /var/run/clamd.scan? Just
added clamilt to the clamscan group and /var/run/clamd.scan is still 711?

The package is overengineered, broken, unusable after install. I already tryed to point this out, see bug #426997, bug #322381 (and possibly others) with strong opossition from the maintainer. So please consider now to fix it (really) up as all people I know are on comment #22 position.

Fedora, RHEL and EPEL are not Mandriva, SUSE or Debian. So do not create packages for EPEL like for them please (as first step). The second - please test package first before pushing it out.

I believe I added clamilt to to the clamscan group and uncommented 'AddHeader Yes' in the /etc/mail/clamav-milter.conf file.

/etc/init.d/clamd-wrapper is symlink to /usr/share/clamav/clamd-wrapper, but:
1) the second has not "x" permission, so init script cannot be run by hand and cannot be run by startup script too
2) files under /usr/share are not intended to be runable

So please, move initscript to default location and do not make symbolic link (like other packages do too).

Then move init scripts to the packages with daemons and make "sysv" (and new subpackage "sysinit") obsolete. There are no packages in RHEL with separate init scripts and it confuse users only.

Thomas, can you please run the following commands and show me the ouput?

  ls -ld /var/run/clamav-milter
  ls -ld /var/run/clamav-milter/clamav-milter.socket
  ls -ld /var/run/clamd.scan
  ls -ld /var/run/clamd.scan/clamd.sock

From the current default permissions, it shouldn't make any difference,
whether clamilt user is added to the clamscan group or not. Unfortunately,
beliefs are not helping me that much here.

Does everthing work still fine for you, if you remove clamilt user from the
clamscan group again and restart clamav-milter as well as clamav-scanner?

Why the config files are moving again? This breaks every update! Don't do it!

Remove "Example" from config files (and do it in SPEC file the way you do not change the modify time of the config files between releases preferrably). All config files should be "ready to run" without user intervention after install because every user edit mean possibly broken update (because clamav config files are changed too often, untouched "ready-to-run" config file will be simply replaced without *.{rpmsave,rpmnew} stuff, if you do it this way). Other RHEL (Fedora) normal packages do it the same way. There is no need to break daemon run by "Example" option because default init script should be off at startup.

Please provide SRC package. One may post diff for you.

For testing (see comment #33) use file /etc/yum.repos.d/test-clamav.repo with this content:

[test-clamav]
name=Test - Clamav
baseurl=http://robert.fedorapeople.org/pub/clamav/
gpgcheck=0
enabled=1

Then do: yum update

Or install all currently needed packages: clamav-data clamav-update clamav-server clamav-lib clamav-server-sysvinit clamav clamav-filesystem clamav-milter-sysvinit clamav-milter)

Bug: clamav-milter should "Requires: clamav-server" (since 0.95 release).

Milan, we can drive bigger changes, but that NEVER will prevent, that things
are going to break like in cases 0.94 -> 0.95 where upstream reworks milter!
Did you clearly understand that?

I'm willing to apply changes to EPEL branches - but only, if you are willing
to help maintaining clamav in EPEL from now and in the future. Means, this is
not a one time change, but you need to get co-maintainer for clamav in EPEL.
Original EPEL maintainer didn't touch clamav for a long time now. If you want
to touch Fedora clamav, please get in touch with Fedora clamav maintainer...

[root@blackstar tjb]#   ls -ld /var/run/clamav-milter
drwx--x--- 2 clamilt clamilt 4096 Apr 14 14:22 /var/run/clamav-milter
[root@blackstar tjb]#   ls -ld /var/run/clamav-milter/clamav-milter.socket
srwxr-xr-x 1 clamilt clamilt 0 Apr 14 14:22 /var/run/clamav-milter/clamav-milter.socket
[root@blackstar tjb]#   ls -ld /var/run/clamd.scan
drwx--x--- 2 clamscan clamscan 4096 Apr 14 13:41 /var/run/clamd.scan
[root@blackstar tjb]#   ls -ld /var/run/clamd.scan/clamd.sock
srwxrwxrwx 1 clamscan clamscan 0 Apr 14 13:41 /var/run/clamd.scan/clamd.sock
[root@blackstar tjb]# 

Sorry, it wasn't 711, it was 710 on /var/run/clamd.scan which makes clamilt not able to get to /var/run/clamd.scan/clamd.sock without being in the clamscan group.

Do not use name "/etc/init.d/clamd-wrapper" but "/etc/init.d/clamd" to be consistent with other packages.

Milan! Can you please stop flooding with ideas/suggestions? Please read
comment #40 and let us talk, whether you want to support clamav as EPEL
maintainer or not.

Thomas, thank you for the input. Note to myself: Need 711 rather 710.

Maintainer should follow upstream, communicate with upstream but do not break things unless really necessary... I'm doing own packages since Red Hat Linux 4.0 and for RHEL too - see ftp://ftp.pslib.cz/pub/users/Milan.Kerslager/RHEL-3/stable/ so I underestand (probably mostly).

I'm not a EPEL or Fedora maintainer but may to do so (if you wish, more in private email please) as I'm running few servers and would like to use EPEL packages instead of my own packages.

I'm not flooding (it was edit conflict), I try to help fix it now when broken. Better fix it hardly now because all around see it broken already.

As postgresql package do, I think that there should be working initscript for one daemon (with simple name "clamd"). This script (as postgresql do) may allow another instance to be running by adding a copy of initscript and config files.

Actual initscipt is broken and will try to provide a patch.

Created attachment 339585 [details]
A fix for actual initcript for clamd

This patch is against 0.95.1-1.1.el5 version from comment #22.
The script works for main instance od clamav daemon (clamd) and will probably work for another instances (if edited, not null CLAMD_SERVICE was not tested).

The clamav-server package should own and create directory /var/run/clamd.
This "flooding" is hard work. Please provide SRC package to be able to post diffs.

I'm currently thinking, whether we shouldn't rework the whole clamav package.
The over-engineering and splitting in too much tiny packages which provide 
really too much flexibility is our main problem here, I would say. Maybe we
first can discuss a bit via private e-mail before further acting, Milan?

Milan, I've spent time this night to try to get the whole picture and as you
did not answer to my e-mail, here some details how I think, we should go on:
http://robert.fedorapeople.org/pub/clamav-rework/ contains a source RPM, that
is based on -1.1, but broken down to 4 binary clamav RPM packages. I'm pretty
sure, that package is currently only busted, but it's a first try.

I think, our goal should be to make EPEL clamav very closed to RPMForge/DAG
one, but still to provide the flexibility using clamd.<SERVICE> optional for
users wanting or needing it (e.g. clamd.amavisd or individual stuff).

I would like to provide a usable clamd package with a usable clamd server, as
RPMForge/DAG currently does. That one can per default be used by clamav-milter
package (dependency set already should fit). Next I want to see freshclam as
a part of the main clamav package and easy to enable (means: one single point
to enable, the /etc/cron.d/freshclam file or similar). What we need to keep is
the clamd-wrapper for e.g. clamd.<SERVICE>. Next we have to provide usable
default configuration files, the RPMForge/DAG ones seem to be nice, but needs
to be checked as well.

The fedora-usermgmt stuff is nice, but I want to conditionalize as I already
did in mimedefang package in Fedora. This is what a couple of users expects,
when they're writing me e-mails.

Important for freshclam is, that I don't want to ship 20 MB of outdated data
for clamav! I often had the case, that a clamav-update with clamav-data even
broke my clamav daemons, because my database files have been already newer, so
the downgrade broke it. The end user anyway initially (!) has to load the 20
MB databases for clamav - it doesn't matter whether he fetches via freshclam 
and is already up-to-date or whether the 20 MB are downloaded all the time. 
And switching over from -data to -data-empty breaks also stuff which caused me
to re-download the 20 MB afterwards again on all my managed mail servers. So
I don't want to ship the database, just empty files that can be filled by the
freshclam we ship but make easily to enable at a single place.

Nevertheless I want to keep the upgrade path of EPEL as far as possible (the
upstream milter rework will cause pain anyway). Of course it will cause some
pain, but lets try to minimize it.

Note, that I'm neither the Fedora clamav maintainer nor EPEL clamav maintainer
nor any co-maintainer of clamav in Fedora. I'm just the guy using clamav from
EPEL at my employer (without clamav-milter) and driving the version bumps at
EPEL and Fedora (Steve didn't touch the package for a very long time, I'm the
only guy touching clamav package since > 1 year in EPEL and I'm touching it in
Fedora Rawhide or other Fedora branches sometimes, if Enrico seems to be AWOL
once more). I'm willing to spend time to clamav, if you are going to help me
to get clamav on EPEL really usable (and maybe better than RPMForge/DAG)... ;)

I did not yet (!) include your work from comment #42/#45/#46/#47 at all, I was
just focussed to get packages down and the dependency set working. I had some
looks to your patch, the idea looks well, but it maybe still needs some love.
Willing to walk and drive the same road as suggested above?

Felix, you've talked to me in the past a couple of time regarding clamav and
updates, issues etc. Willing or interested to help here as well?

http://packages.sw.be/clamav/ and http://crash.fce.vutbr.cz/crash-hat/centos/5/
are the most common used clamav packages, as far as I got.

Could you provide updated builds for el4? We just had several systems get bitten by the broken upgrade that's out there.

+1 to comment #52 (my systems with clamav are all el4)

We are working on fixing up the package. My own progress may be seen at ftp://ftp.pslib.cz/pub/local/rpm/. The package is purely testing so don't expect it works. It only incorporates ideas from comments above and will be changed in non-compatible way so you have been warned.

Can't someone just give us an el4 build of the #23 rpms so we can fix our broken systems now? Both x86_64 and i386? TIA...

You may use older working packages, see ftp://ftp.pslib.cz/pub/users/Milan.Kerslager/ or another place. I'll post more info about latest package tomorow. You may also try to use my half-baked package at http://ftp.pslib.cz/pub/local/rpm/ (still fully untested, with bugs, but mostly cleaned up).

My latest version 0.95.1-1.6.ker.rhel5 at ftp://ftp.pslib.cz/pub/local/rpm/ almost works. The clamav-milter should get better initscript and there is a SELinux issue. Unfortunately I'm able to send mails through milter just after clean install (clamd and clamav-milter daemons started).

The package is broken into main part "clamav" (clamd daemon + freshclam updater), "clamav-milter", "clamav-devel" (for development work) and "clamav-data" (virus database, not needed if you have online Internet access and freshclam is used).

I posted builds for RHEL4 and RHEL5 (both 32 and 64 bit), please test and report bugs here or to my private email: http://ftp.pslib.cz/pub/local/rpm/

Well, since this bug is about everything and then some more regarding clamav-0.95.1 I'll list my own observation with 2009-04-22 version from Rawhide:

- clamd.scan log is not created during installation (as are other logs) so when starting the scanner daemon it fails since it can't create the log file under /var/log

- clamd-wrapper sym link under /etc/init.d seems to be pointless as one cannot execute it and a working init script is /etc/init.d/clam.scan

- there is not /etc/clamd.conf but /etc/clamd.d/scan.conf which will work with the init script but when starting clamdscan from command line it cannot find its own configuration file - why not just use the usual /etc/clamd.conf?

All that bugs are fixed in my package I wrote about in comment #58 and above. I'll post new builds with fixed documentation and Fedora 10 build too tomorow and then I'll test update process again. Then I would like to ask for inclusion in Rawhide (or F11 updates IIRC) and in EPEL too.

Milan, thanks a lot for your efforts, I'm very interested also in EPEL 4/5 packaging and your spec file seem much more sane than the current Fedora version! +1 from me to use your version.

One issue I don't find fixed in your spec file, however, is the clamd.scan log thing, care to check?

One thing to improve in future when the dust has settled with packaging would be LSB header in the init script but that is very low prio IMHO.

Hi Milan,

thanks for your efforts and forgive the delay.
Tried the packages for EL4. Before installing your packages from http://ftp.pslib.cz/pub/local/rpm/RHEL-4/ I removed the old clamav / clamav-milter installation, so I was able to start from scratch.

I installed clamav-milter, and the relative dependencies (clamav-data and clamav).
No more fedora-usrmgmt* dependendecies, and this is a good thing! ;-)
I looked at the config files and they looked already tuned for my needs (in the past I *ALWAYS* had to adjust a couple of parameters per config file), and this is also a good thing.

Then I started the clamav-milter service with the usual:

/etc/init.d/clamav-milter start

and it gave me the error:

Starting clamav-milter: : Usage: daemon [+/-nicelevel]{program}

Someone have an idea about what's causing this issue?

Thanks to all.
Simo

Can we get these new packages pushed to epel sometime soon?  The ones there now are still the broken ones from April 10.  I figure even if we don't have all the bugs out of the new configuration yet, this is still better than what's there!

Anything that I could do to help get these changes moving? I would really like to see this getting solved and avoid creating local fork of spec files.

Thanks!

Well,

I took RPMs from Dag's repo, tested them on RHEL/CentOS 4 and 5, seemed to work perfectly and put them into action.

http://dag.wieers.com/rpm/packages/clamav/

Very good thing about Dag's spec file is that it is easy to understand and the number of subpackages is small, any possible local tweak will be much easier than with the overengineered Fedora RPMs.

Cheers!

Ok - you can add me to the chorus... same issue(s)... moved from Fedora 10 to 11 (different hw). I can't get clamav to work correctly.

Having poked around some, it would seem that in addition to the issues discussed above, there are also permission issues involved. Between the various ID's used for clam and sendmail, plus selinux targeted enforcement, it's rather difficult to get this working.

While using the local socket is efficient, I'm thinking that absent working this all out it might be reasonable to move to a TCP socket for now.

I was able to get past the clamav-milter talking to clamd, but then sendmail wouldn't talk to clamav-milter. Fixed all the permissions on the socket, but hit SELinux denials.

Fwiw, I downloaded the latest source from clamav.net and hit the same issues on Fedora 11. I was not enforcing selinux on 10... might drop that on 11 for now.

Michael, this bug report is EPEL 4/5 only, not Fedora releases or similar.
So you never will find a solution for your Fedora problem in this bug report,
the Fedora branch is handled by another Fedora contributor.

Is it safe to upgrade yet?  I upgraded back in april and the new clamav brought my server to a halt.  I.e. broke mail - so I rolled back to the .94 packages and have been excluding clamav ever since in yum.  I am now wondering if it is safe to move on.

(In reply to comment #68)
> Is it safe to upgrade yet?  I upgraded back in april and the new clamav brought
> my server to a halt.  I.e. broke mail - so I rolled back to the .94 packages
> and have been excluding clamav ever since in yum.  I am now wondering if it is
> safe to move on.  
	
Yesterday I installed clamav-milter 0.95.1-1.el5 on CentOS 5.4 and remains broken, the error was the same as reported here.

After edit /etc/init.d/clamav-milter, /etc/sysconfig/clamav-milter and /etc/clamd.d/milter.conf and I get:

# /etc/init.d/clamav-milter start
Starting clamav-milter: ERROR: LogFile requires full path.

# grep ^LogFile /etc/clamd.d/milter.conf 
LogFile /var/log/clamd.milter

I do not know that I do now ...

I reported this issue against F11 as discussed above - but against libmilter. 
We tracked the issue down to selinux. There's a workaround (selinux commands) and a fix pending in Fedora. You can probably use the workaround for this issue as well until the patch percolates down.

That bug report is here: https://bugzilla.redhat.com/show_bug.cgi?id=516322

I have SELinux in permissive mode, but clamav-milter does not start with the same error message. Seems like bug in clamav-milter-0.95.1-1.el5:

$ clamav-milter -lo -c /etc/clamd.d/milter.conf
WARNING: Ignoring deprecated option LocalSocket at line 72
ERROR: LogFile requires full path.

It seems that latest version fixes the problem. So please update.

It seems like EPEL version RPM package has not been updated so you have to use another (DAG). I have own simplified package but it requires to uninstall EPEL clamav* packages first (as they broke update process).

http://dag.wieers.com/rpm/packages/clamav/
ftp://ftp.pslib.cz/pub/local/rpm/ (my current packages with clamav-0.95.3)
ftp://ftp.linux.cz/pub/linux/people/milan_kerslager/RHEL-5/stable/ (will be here soon)

Is this package going to be updated any time soon? If not, please say so and I will roll my own - the DAG build is too different, and moving to it is a pain I am not willing to suffer in the short run.

I made new build with fixed update path. This have to be tested and then may be pushed into oficial updates and I may take a care of it.

I just rebuild the 0.96 SRPM from Fedora 13/rawhide w/o an issue on a CentOS 5.4 system (via mock)..

Steps.
1. download clamav-0.96-1402 from the F13/Rawhide FTP
   ftp://download.fedora.redhat.com/pub/fedora/linux/development/rawhide/source/SRPMS/clamav-0.96-1402.fc14.src.rpm 
2. Extract it out

mkdir clamav
cd clamav
rpm2cpio ../clamav-0.96-1402.fc14.src.rpm | cpio -i

3. download the clamav-0.96.tar.gz from the Clamav.sf.net website

4. build the "new SRPM"

rpmbuild -bs --nodeps clamav.spec --with-unrar

5. build the new SRPM via mock

mock --resultdir=$HOME/RPMS -r epel-5-i386 --with=unrar --without=upstart --without=fedora --wiuthout=noarch clamav-0.96-1302.src.rpm

Wait for the build to finish and then upgrade.

A few things I had to change after upgrading was to adjust my freshclam.conf for changes I had made and I had to make a /var/run/clamd.amavisd owned by amavis (for some reason the pid wasn't going there in the previous version).

But other than that it's working great now.. as opposed to before the 0.95.1 clamd process kept "quitting" the past few days.

Also see bug 579370 comment 1 for why it is critically important to upgrade to 0.96.

A year and a half later and I still can't scan e-mail for viruses on our corporate e-mail server. You lads planning to get your act together any day soon and issue the upstream-supported clamav with working RPMs and scripts?

+1 for some ClamAV packages that JFW OOTB. Ideally I'd just like to be able to do:

chkconfig clamd on
service clamd start

and have it run using sane defaults.

Package clamav-0.97-3.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing clamav-0.97-3.el6'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/clamav-0.97-3.el6
then log in and leave karma (feedback).

Package clamav-0.97-3.el4:
* should fix your issue,
* was pushed to the Fedora EPEL 4 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing clamav-0.97-3.el4'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/clamav-0.97-3.el4
then log in and leave karma (feedback).

clamav-0.97-3.el4 has been pushed to the Fedora EPEL 4 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update clamav'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/clamav-0.97-3.el4

Why el4 and el6 but no el5 updates?

It looks like the EL5 package is in koji, but not tagged to be in bodhi yet?

http://koji.fedoraproject.org/koji/buildinfo?buildID=230479

clamav-0.97-3.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/clamav-0.97-3.el6

clamav-0.97-4.el4 has been submitted as an update for Fedora EPEL 4.
https://admin.fedoraproject.org/updates/clamav-0.97-4.el4

clamav-0.97-9.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/clamav-0.97-9.el6

clamav-0.97-9.el4 has been submitted as an update for Fedora EPEL 4.
https://admin.fedoraproject.org/updates/clamav-0.97-9.el4

clamav-0.97-9.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/clamav-0.97-9.el5

clamav-0.97-11.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/clamav-0.97-11.el6

clamav-0.97-11.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/clamav-0.97-11.el5

clamav-0.97-11.el4 has been submitted as an update for Fedora EPEL 4.
https://admin.fedoraproject.org/updates/clamav-0.97-11.el4

clamav-0.97-11.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

clamav-0.97-11.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

clamav-0.97-12.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/clamav-0.97-12.el6

clamav-0.97-12.el4 has been submitted as an update for Fedora EPEL 4.
https://admin.fedoraproject.org/updates/clamav-0.97-12.el4

clamav-0.97-12.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/clamav-0.97-12.el5

clamav-0.97-12.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.