I see you re-submitted the EPEL6 clamav update without any changes after bodhi unpushed it after me giving it negative karma. The change breaks amavisd-new on RHEL5 (so you´ve not provided an EPEL5 version), and it means the fedora-14 amavisd-new can´t be used as-is on EPEL6.
https://www.redhat.com/archives/epel-devel-list/2011-March/msg00047.html https://www.redhat.com/archives/epel-devel-list/2011-March/msg00048.html
It seems strange to me to suddenly change the packaging for EPEL compared to current EPEL4/5, and also compared to Fedora. Why this change for EPEL and not for the packages your´ve created for Fedora-14/15 ?
http://koji.fedoraproject.org/koji/buildinfo?buildID=232112 http://koji.fedoraproject.org/koji/buildinfo?buildID=232111
Shouldn´t they all change to the new format (and amavisd-new fixed to work with the new clamav-packaging), or none.. ?
-jf
On Thu, 10 Mar 2011 23:11:51 +0100 Jan-Frode Myklebust janfrode@tanso.net wrote:
I see you re-submitted the EPEL6 clamav update without any changes after bodhi unpushed it after me giving it negative karma. The change breaks amavisd-new on RHEL5 (so you´ve not provided an EPEL5 version), and it means the fedora-14 amavisd-new can´t be used as-is on EPEL6.
https://www.redhat.com/archives/epel-devel-list/2011-March/msg00047.html https://www.redhat.com/archives/epel-devel-list/2011-March/msg00048.html
It seems strange to me to suddenly change the packaging for EPEL compared to current EPEL4/5, and also compared to Fedora. Why this change for EPEL and not for the packages your´ve created for Fedora-14/15 ?
The Fedora maintainer has odd desires for the package. This is sad for Fedora, but we are not going to keep following the Fedora package in EPEL, so we are going with a new, easier to manage version.
The Fedora version is likely going to stay the same unless someone can convince the maintainer there to step down.
http://koji.fedoraproject.org/koji/buildinfo?buildID=232112 http://koji.fedoraproject.org/koji/buildinfo?buildID=232111
Shouldn´t they all change to the new format (and amavisd-new fixed to work with the new clamav-packaging), or none.. ?
Yeah, I would think so.
Do you have any thoughts/patches for getting amavisd-new working with the new clamav? Perhaps looking at some of the other 3rd party repos could help us here. I know one of the amavisd-new maintainers was going to look into it, but I don't think he's had time yet. ;(
Also, there is no amavisd-new pushed in epel6 yet, so we could push clamav now, and push the fixed amavisd-new as soon as it's ready, no?
kevin
On 2011-03-10, Kevin Fenzi kevin@scrye.com wrote:
Do you have any thoughts/patches for getting amavisd-new working with the new clamav?
Not sure, I quickly gave up when I hit an selinux denial and saw that this denial wasn´t happening with the old packaging. Was hoping we could run our new mailservers on default selinux policy if possible.
First step is probably to add back in the clamd-wrapper (which is part of the current EPEL6 clamav), so that amavisd-new can continue to use it´s own scanner instance trough /usr/share/clamav/clamd-wrapper, /etc/clamd.d/amavisd.conf and /etc/rc.d/init.d/clamd.amavisd.. Removing this clamd-wrapper is bound to break existing installations that has followed the recommendations from the old packaging about creating per-service clamd-instances (maybe not just for amavisd-new).
Also, security-wise the old packaging said to:
NEVER use 'clamav' as the user since he can modify the database.
while the new packaging runs as "clam" and has database-files owned by "clam":
[janfrode@asav.lab:~]$ ps -ef|grep clam clam 20082 1 0 00:00 ? 00:00:00 clamd [janfrode@asav.lab:~]$ ls -al /var/lib/clamav/ totalt 30560 drwxr-xr-x. 2 clam clam 4096 2011-03-10 04:29 . drwxr-xr-x. 28 root root 4096 2011-03-03 14:38 .. -rw-r--r--. 1 clam clam 460288 2011-03-09 03:07 bytecode.cld -rw-r--r--. 1 clam clam 4588544 2011-03-10 04:29 daily.cld -rw-r--r--. 1 clam clam 26224310 2011-02-24 00:39 main.cvd -rw-------. 1 498 397 416 2011-03-05 12:20 mirrors.dat [janfrode@asav.lab:~]$ rpm -q clamd clamd-0.97-3.el6.x86_64
Also, there is no amavisd-new pushed in epel6 yet, so we could push clamav now, and push the fixed amavisd-new as soon as it's ready, no?
There is a clamav with the previous packaging format in EPEL6. Are you sure changing it woun´t break existing installations ? Nobody expecting the existing clamscan, clamupdate, clamilt users/group to exist?
I´m mostly worried that we´ll end up with confusing/different clamav and amavisd-new installations on our RHEL5 and RHEL6 servers, plus pushing this big change now will probably delay amavisd-new in EPEL6.. (and I need it now! :-)
-jf
On Thu, Mar 10, 2011 at 16:28, Jan-Frode Myklebust janfrode@tanso.net wrote:
On 2011-03-10, Kevin Fenzi kevin@scrye.com wrote:
Do you have any thoughts/patches for getting amavisd-new working with the new clamav?
I´m mostly worried that we´ll end up with confusing/different clamav and amavisd-new installations on our RHEL5 and RHEL6 servers, plus pushing this big change now will probably delay amavisd-new in EPEL6.. (and I need it now! :-)
At the moment and before this change there was no move to do an amavisd for EPEL-6 so I don't think it will delay it anymore than before.
-jf
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Fri, 11 Mar 2011 00:28:18 +0100 Jan-Frode Myklebust janfrode@tanso.net wrote:
On 2011-03-10, Kevin Fenzi kevin@scrye.com wrote:
Do you have any thoughts/patches for getting amavisd-new working with the new clamav?
Not sure, I quickly gave up when I hit an selinux denial and saw that this denial wasn´t happening with the old packaging. Was hoping we could run our new mailservers on default selinux policy if possible.
Sure, that would be a bug worth fixing I agree.
First step is probably to add back in the clamd-wrapper (which is part of the current EPEL6 clamav), so that amavisd-new can continue to use it´s own scanner instance trough /usr/share/clamav/clamd-wrapper, /etc/clamd.d/amavisd.conf and /etc/rc.d/init.d/clamd.amavisd.. Removing this clamd-wrapper is bound to break existing installations that has followed the recommendations from the old packaging about creating per-service clamd-instances (maybe not just for amavisd-new).
Yes, thats something the old package said. In practice I don't know how much security it really provides. ;(
Anyhow, yeah, if we could add the wrapper thing that amavisd-new needs that might be a quick solution.
Also, security-wise the old packaging said to:
NEVER use 'clamav' as the user since he can modify the
database.
while the new packaging runs as "clam" and has database-files owned by "clam":
What runs as 'clam'? clamd?
yes, thats true. It does mean the clam user could modify the db files, but the additional security here I don't know is worth it.
If you wish to seperate things like that, I would suggest running clamscan instead as whatever user.
Also, there is no amavisd-new pushed in epel6 yet, so we could push clamav now, and push the fixed amavisd-new as soon as it's ready, no?
There is a clamav with the previous packaging format in EPEL6. Are you sure changing it woun´t break existing installations ? Nobody expecting the existing clamscan, clamupdate, clamilt users/group to exist?
I tested it here and it worked fine for upgrades, with one exception: the /etc/freshclam.conf.rpmnew file needed to be moved in place before freshclam would work.
I´m mostly worried that we´ll end up with confusing/different clamav and amavisd-new installations on our RHEL5 and RHEL6 servers, plus pushing this big change now will probably delay amavisd-new in EPEL6.. (and I need it now! :-)
Yeah, it's all no fun for sure. ;(
Where I would like to get:
* clamav packaged the new way on 4/5/6 * amavisd-new packaged to use that on 4/5/6
How we get there is up to the maintainers... I know several people were looking at amavisd-new. Perhaps we could get everyone together at an irc meeting and hash out what needs to happen?
kevin
On 2011-03-12, Kevin Fenzi kevin@scrye.com wrote:
Anyhow, yeah, if we could add the wrapper thing that amavisd-new needs that might be a quick solution.=20
Just tested now by copying /usr/share/clamav/clamd-wrapper from the old installation to the new.
First problem:
Mar 13 18:49:50 asav clamd[23281]: Can't save PID in file /var/run/clamd.amavisd/clamd.pid
(actually the same problem with old clamd-installation). So i manually created this directory, and things seems to be working.
What runs as 'clam'? clamd?
Yes.
yes, thats true. It does mean the clam user could modify the db files, but the additional security here I don't know is worth it.
.. and if we can get in the /usr/share/clamav/clamd-wrapper, running the virus-scanner as amavis instead becomes trivial.
If you wish to seperate things like that, I would suggest running clamscan instead as whatever user.=20
clamscan is waay too slow on a busy mailserver.
- clamav packaged the new way on 4/5/6
- amavisd-new packaged to use that on 4/5/6
How we get there is up to the maintainers... I know several people were looking at amavisd-new. Perhaps we could get everyone together at an irc meeting and hash out what needs to happen?
1 - Add back /usr/share/clamav/clamd-wrapper to the clamd-package + possibly the README-file /usr/share/doc/clamav-server-0.96.1/README which explains how to set up individual clamd-instances:
http://blag.tanso.net/code/clamav.spec http://blag.tanso.net/code/clamav-0.97-4.el6.src.rpm
It's maybe not pretty to put this in %{_prefix}/share/clamav/, but IMHO it's needed for compatibility with older packaging and existing installations on EL4/5.
2 - Modify amavisd-new from f14 to create the directory /var/run/clamd.amavisd (it's already adding the service "clamd.amavisd" which use this directory).
3 - Make amavisd-new not use "PidFile /var/run/amavisd/clamd.pid" in /etc/clamd.d/amavisd.conf, since it's using the wrapper which overrides this pidfile anyway.
I'll get #2/#3 done as well, but would appreciate if someone could sponsor me as a fedora maintainer, so that can also get this submitted to EPEL properly.
-jf
On 2011-03-13, Jan-Frode Myklebust janfrode@tanso.net wrote:
2 - Modify amavisd-new from f14 to create the directory /var/run/clamd.amavisd (it's already adding the service "clamd.amavisd" which use this directory).
3 - Make amavisd-new not use "PidFile /var/run/amavisd/clamd.pid" in /etc/clamd.d/amavisd.conf, since it's using the wrapper which overrides this pidfile anyway.
I'll get #2/#3 done as well, but would appreciate if someone could sponsor me as a fedora maintainer, so that can also get this submitted to EPEL properly.
These should work:
http://blag.tanso.net/code/amavisd-new/amavisd-new.spec http://blag.tanso.net/code/amavisd-new/amavisd-new-2.6.4-2.el6.src.rpm http://blag.tanso.net/code/amavisd-new/amavisd-new-2.6.4-2.el6.noarch.rpm http://blag.tanso.net/code/amavisd-new/amavisd-new-snmp-2.6.4-2.el6.noarch.r...
but also require altermime, cabextract and perl-Convert-TNEF which are missing from EPEL6, but SRPMs from EPEL5 builds and works without any change.
-jf
epel-devel@lists.fedoraproject.org