Bug 495502 - 0.95.1 is busted
Summary: 0.95.1 is busted
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: clamav
Version: el5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Robert Scheck
QA Contact: Fedora Extras Quality Assurance
Whiteboard: ActualBug
Depends On:
TreeView+ depends on / blocked
Reported: 2009-04-13 14:50 UTC by Orion Poplawski
Modified: 2011-04-06 22:53 UTC (History)
17 users (show)

Clone Of:
: 514968 (view as bug list)
Last Closed: 2011-03-26 18:58:51 UTC

Attachments (Terms of Use)
A fix for actual initcript for clamd (2.08 KB, patch)
2009-04-14 21:34 UTC, Milan Kerslager
no flags Details | Diff

Description Orion Poplawski 2009-04-13 14:50:31 UTC
Description of problem:

After upgrade to 0.95.1:

# service clamav-milter start
clamav-milter: unrecognized option `--pidfile=/var/run/clamav-milter/clamav-milter.pid'
ERROR: Unknown option passed
ERROR: Can't parse command line options

Had to edit /etc/rc.d/init.d/clamav-milter and comment out CLAMAV_PID.

Next I get:

WARNING: Ignoring option local:/var/run/clamav-milter/clamav.sock
WARNING: Ignoring deprecated option LocalSocket at line 72
ERROR: LogFile requires full path.

milter.conf does not appear to be based on clamav-0.95.1/etc/clamav-milter.conf but instead on etc/clamd.conf.

Did this get any testing?

Version-Release number of selected component (if applicable):

Comment 1 Orion Poplawski 2009-04-13 14:56:37 UTC
Also looks like in 0.95, clamav-milter requires a separate clamd server running.

Comment 2 Robert Scheck 2009-04-13 14:59:11 UTC
Looks like this is my mistake.

Comment 3 Robert Scheck 2009-04-13 15:03:43 UTC
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?

Comment 4 Orion Poplawski 2009-04-13 15:05:35 UTC
Yes.  i386.

Comment 5 Robert Scheck 2009-04-13 16:11:24 UTC
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/

Comment 6 Orion Poplawski 2009-04-13 16:41:42 UTC
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.

Comment 7 Robert Scheck 2009-04-13 16:54:24 UTC
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.

Comment 8 Orion Poplawski 2009-04-13 17:01:23 UTC
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".

Comment 9 Robert Scheck 2009-04-13 17:13:47 UTC
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?

Comment 10 Orion Poplawski 2009-04-13 17:51:40 UTC
I really want to test a proper upgrade, no rpm shenanigans.

Comment 11 Robert Scheck 2009-04-13 18:27:11 UTC
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.

Comment 12 Orion Poplawski 2009-04-13 19:29:56 UTC
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


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


LogFacility LOG_MAIL

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


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".


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

Comment 13 Orion Poplawski 2009-04-13 19:47:59 UTC
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


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


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.

Comment 14 Robert Scheck 2009-04-13 19:51:01 UTC
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?

Comment 15 Orion Poplawski 2009-04-13 19:58:08 UTC
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.

Comment 16 Orion Poplawski 2009-04-13 20:06:46 UTC
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.

Comment 17 Robert Scheck 2009-04-13 20:13:21 UTC
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.

Comment 18 Orion Poplawski 2009-04-13 20:32:45 UTC
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.

Comment 19 Robert Scheck 2009-04-13 22:01:11 UTC
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?

Comment 20 Milan Kerslager 2009-04-14 06:40:58 UTC
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).

Comment 21 Simone Marchioni 2009-04-14 08:33:16 UTC
Same problem here. If you need help in testing the new packages I'm here.

Comment 22 Eddie Lania 2009-04-14 11:43:42 UTC
I never got clamav working out-of-the-rpm on any redhat/fedora distro.

Comment 23 Robert Scheck 2009-04-14 13:01:19 UTC
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.

Comment 24 Thomas J. Baker 2009-04-14 13:51:34 UTC
I could test some x86_64 packages. Do you have them built somewhere?

Comment 25 Robert Scheck 2009-04-14 14:40:17 UTC
clamav-0.95.1-1.1 packages for i386 and x86_64 are in the URL of comment #23,

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.

Comment 26 Eddie Lania 2009-04-14 15:04:19 UTC
(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.  


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



Comment 27 Robert Scheck 2009-04-14 15:10:13 UTC
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.

Comment 28 Thomas J. Baker 2009-04-14 15:26:29 UTC
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 as options. Not sure why that
is happening.

Comment 29 Robert Scheck 2009-04-14 15:49:12 UTC
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?

Comment 30 Thomas J. Baker 2009-04-14 17:35:52 UTC
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.

Comment 31 Thomas J. Baker 2009-04-14 18:09:54 UTC
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.

Comment 32 Thomas J. Baker 2009-04-14 18:25:17 UTC
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.

Comment 33 Robert Scheck 2009-04-14 18:34:38 UTC
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?

Comment 34 Milan Kerslager 2009-04-14 19:09:00 UTC
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.

Comment 35 Thomas J. Baker 2009-04-14 19:16:48 UTC
I believe I added clamilt to to the clamscan group and uncommented 'AddHeader Yes' in the /etc/mail/clamav-milter.conf file.

Comment 36 Milan Kerslager 2009-04-14 20:06:47 UTC
/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.

Comment 37 Robert Scheck 2009-04-14 20:20:09 UTC
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?

Comment 38 Milan Kerslager 2009-04-14 20:21:07 UTC
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.

Comment 39 Milan Kerslager 2009-04-14 20:35:52 UTC
For testing (see comment #33) use file /etc/yum.repos.d/test-clamav.repo with this content:

name=Test - Clamav

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).

Comment 40 Robert Scheck 2009-04-14 20:36:32 UTC
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...

Comment 41 Thomas J. Baker 2009-04-14 20:39:16 UTC
[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.

Comment 42 Milan Kerslager 2009-04-14 20:40:31 UTC
Do not use name "/etc/init.d/clamd-wrapper" but "/etc/init.d/clamd" to be consistent with other packages.

Comment 43 Robert Scheck 2009-04-14 20:47:25 UTC
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.

Comment 44 Milan Kerslager 2009-04-14 20:57:24 UTC
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.

Comment 45 Milan Kerslager 2009-04-14 21:07:01 UTC
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.

Comment 46 Milan Kerslager 2009-04-14 21:34:04 UTC
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).

Comment 47 Milan Kerslager 2009-04-14 21:38:22 UTC
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.

Comment 48 Robert Scheck 2009-04-14 22:53:53 UTC
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?

Comment 49 Robert Scheck 2009-04-15 13:05:41 UTC
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?

Comment 50 Robert Scheck 2009-04-15 13:09:38 UTC
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?

Comment 51 Robert Scheck 2009-04-15 14:57:50 UTC
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.

Comment 52 Thomas J. Baker 2009-04-15 19:32:50 UTC
Could you provide updated builds for el4? We just had several systems get bitten by the broken upgrade that's out there.

Comment 53 Simone Marchioni 2009-04-16 16:36:47 UTC
+1 to comment #52 (my systems with clamav are all el4)

Comment 54 Milan Kerslager 2009-04-17 08:13:02 UTC
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.

Comment 55 Thomas J. Baker 2009-04-17 12:12:15 UTC
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...

Comment 56 Milan Kerslager 2009-04-17 21:26:41 UTC
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).

Comment 57 Milan Kerslager 2009-04-18 14:53:21 UTC
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).

Comment 58 Milan Kerslager 2009-04-20 20:38:46 UTC
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/

Comment 59 Daniel Qarras 2009-04-22 19:43:38 UTC
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?

Comment 60 Milan Kerslager 2009-04-22 20:06:35 UTC
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.

Comment 61 Daniel Qarras 2009-04-22 20:22:28 UTC
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.

Comment 62 Simone Marchioni 2009-04-27 13:11:38 UTC
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.

Comment 63 Gilbert E. Detillieux 2009-05-05 20:15:55 UTC
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!

Comment 64 Daniel Qarras 2009-05-31 12:58:49 UTC
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.


Comment 65 Daniel Qarras 2009-06-09 18:33:59 UTC

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


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.


Comment 66 Michael Breuer 2009-07-31 16:38:10 UTC
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.

Comment 67 Robert Scheck 2009-07-31 17:00:22 UTC
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.

Comment 68 Jack Deslippe 2009-08-19 23:47:35 UTC
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.

Comment 69 Renato Covarrubias 2009-11-06 14:38:38 UTC
(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 ...

Comment 70 Michael Breuer 2009-11-06 15:10:49 UTC
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

Comment 71 Milan Kerslager 2009-11-11 16:30:35 UTC
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.

Comment 72 Milan Kerslager 2009-11-11 18:34:26 UTC
It seems that latest version fixes the problem. So please update.

Comment 73 Milan Kerslager 2009-12-09 19:33:55 UTC
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).

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)

Comment 74 alien_life_form 2010-01-08 17:06:21 UTC
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.

Comment 75 Milan Kerslager 2010-02-08 11:00:03 UTC
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.

Comment 76 Edward Rudd 2010-05-07 18:07:47 UTC
I just rebuild the 0.96 SRPM from Fedora 13/rawhide w/o an issue on a CentOS 5.4 system (via mock)..

1. download clamav-0.96-1402 from the F13/Rawhide FTP
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.

Comment 77 James Ralston 2010-05-07 19:00:10 UTC
Also see bug 579370 comment 1 for why it is critically important to upgrade to 0.96.

Comment 78 Glen Turner 2010-08-13 01:51:46 UTC
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?

Comment 79 Matt Dainty 2010-09-22 09:45:52 UTC
+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.

Comment 80 Fedora Update System 2011-03-04 01:09:52 UTC
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:
then log in and leave karma (feedback).

Comment 81 Fedora Update System 2011-03-04 01:53:05 UTC
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:
then log in and leave karma (feedback).

Comment 82 Fedora Update System 2011-03-04 05:54:23 UTC
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

Comment 83 Orion Poplawski 2011-03-09 21:23:06 UTC
Why el4 and el6 but no el5 updates?

Comment 84 Edward Rudd 2011-03-09 23:24:05 UTC
It looks like the EL5 package is in koji, but not tagged to be in bodhi yet?


Comment 85 Fedora Update System 2011-03-10 16:30:48 UTC
clamav-0.97-3.el6 has been submitted as an update for Fedora EPEL 6.

Comment 86 Fedora Update System 2011-03-13 21:27:08 UTC
clamav-0.97-4.el4 has been submitted as an update for Fedora EPEL 4.

Comment 87 Fedora Update System 2011-03-15 14:36:58 UTC
clamav-0.97-9.el6 has been submitted as an update for Fedora EPEL 6.

Comment 88 Fedora Update System 2011-03-15 14:37:46 UTC
clamav-0.97-9.el4 has been submitted as an update for Fedora EPEL 4.

Comment 89 Fedora Update System 2011-03-15 14:38:33 UTC
clamav-0.97-9.el5 has been submitted as an update for Fedora EPEL 5.

Comment 90 Fedora Update System 2011-03-18 09:11:52 UTC
clamav-0.97-11.el6 has been submitted as an update for Fedora EPEL 6.

Comment 91 Fedora Update System 2011-03-18 09:12:39 UTC
clamav-0.97-11.el5 has been submitted as an update for Fedora EPEL 5.

Comment 92 Fedora Update System 2011-03-18 09:13:24 UTC
clamav-0.97-11.el4 has been submitted as an update for Fedora EPEL 4.

Comment 93 Fedora Update System 2011-03-26 18:57:45 UTC
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.

Comment 94 Fedora Update System 2011-03-26 19:00:21 UTC
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.

Comment 95 Fedora Update System 2011-03-30 10:47:21 UTC
clamav-0.97-12.el6 has been submitted as an update for Fedora EPEL 6.

Comment 96 Fedora Update System 2011-03-30 10:48:12 UTC
clamav-0.97-12.el4 has been submitted as an update for Fedora EPEL 4.

Comment 97 Fedora Update System 2011-03-30 10:49:00 UTC
clamav-0.97-12.el5 has been submitted as an update for Fedora EPEL 5.

Comment 98 Fedora Update System 2011-04-06 22:52:37 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.