EPEL tries to straddle the slow and steady world of Enterprise Linux and the fast and furious world of Fedora. This means that packages are usually held in epel-testing for at least 14 days or until the package has been tested by at least 3 people who give a positive score in bodhi . Because EPEL is a 'Stone Soup' set of packages, it does not have dedicated QA which test every update, but instead relies on what people bring to the table in the form of testing things if they need it. This has its benefits, but it does lead to problems where someone who wants to get a CVE fix out right away having to find willing testers or wait 14 days for the package to auto-promote.
Since I had used clamav years ago, and I needed an article to publish on Wednesday.. I decided I would give it a go. My first step was to find a system to test with. My main website still runs happily on CentOS-6 and I saw that while I had configured spamassassin with postfix I had not done so with clamav. This would make a good test candidate because I could roll back to an older setup if the package did not work.
First step was to install the clamav updates. Unlike my desktop where I have epel-testing always on, I keep the setup rather conservative on the web server. So to get the testing version of clamav I needed to the following:
# yum list --enable=epel-testing clamav* Available Packages clamav.i686 0.99.4-1.el6 epel-testing clamav-db.i686 0.99.4-1.el6 epel-testing clamav-devel.i686 0.99.4-1.el6 epel-testing clamav-milter.i686 0.99.4-1.el6 epel-testing ...
# yum install --enable=epel-testing clamav clamstmp clamd Loaded plugins: fastestmirror Setting up Install Process Loading mirror speeds from cached hostfile * base: mirrordenver.fdcservers.net * epel-testing: mirror.texas3006.com * extras: repos-tx.psychz.net * updates: centos.mirror.lstn.net Resolving Dependencies --> Running transaction check ... Is this ok [y/N]:
I didn't use a -y here because I wanted to confirm that no large number of dependencies or other things were pulled in. It all looked good so I hit y and the install happened. I then went through the other steps and saw that there was a change in setup from when the document was written.
[root@linode01 smooge]# chkconfig --list | grep clam clamd 0:off 1:off 2:off 3:off 4:off 5:off 6:off clamsmtp-clamd 0:off 1:off 2:off 3:on 4:on 5:on 6:off clamsmtpd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
I turned on clamsmtp-clamd instead of clamd, and continued through the configs. After this I emailed an eicar to myself and saw it get blocked in the logs. I then looked at the CVE and saw if I could trigger a test against it. It didn't look like I could so I skipped that part. I then repeated the setup in a EL-6 VM I have at home to see that it worked there also. At this point it was time to report my findings in bodhi. I opened the report the owner had pointed me to and logged into the bodhi system. I added a general comment that I had tested it on 2 systems, and then plus 1'd the parts I had tested. Other people joined in and this package was able to get pushed much earlier than it would have previously.
There are currently 326 packages in EPEL-testing for EL-6. Please take the time to test 1 or two packages if you can. [I did pax-utils in writing this because I wanted to replicate the steps I had done. It needs 2 more people to test and it is a security fix also.]