Latest Clamav update fails on 2 separate systems

17 posts / 0 new
Last post
#1 Fri, 04/03/2009 - 03:31
rduval

Latest Clamav update fails on 2 separate systems

System sends email: [code:1]An update to clamav 0.95-4.el5.art is available : New version released[/code:1]

but when I run the update it finishes with

[code:1] ---> Package fedora-usermgmt-default-fedora-setup.noarch 0:0.9-1.el5 set to be updated ---> Package fedora-usermgmt-core.noarch 0:0.9-1.el5 set to be updated ---> Package fedora-usermgmt-shadow-utils.noarch 0:0.9-1.el5 set to be updated --> Processing Conflict: clamav-filesystem conflicts clamav > 0.94.2-1.vm.el5 --> Finished Dependency Resolution Error: clamav-filesystem conflicts with clamav > 0.94.2-1.vm.el5

  .. install failed!

[/code:1]

This is a CentOS 5.2 system btw<br><br>Post edited by: rduval, at: 2009/04/03 03:32

Mon, 04/06/2009 - 03:53
rduval

No replies? Anybody else having this problem or know what it is?

Mon, 04/06/2009 - 06:58 (Reply to #2)
andreychek

There is a ticket with your same issue and how to resolve it here:

http://www.virtualmin.com/index.php?option=com_flyspray&amp;Itemid=82&am...

Tue, 04/07/2009 - 03:28 (Reply to #3)
rduval

Thanks, it's beginning to make more sense now. To be honest I don't 100% understand repos and how they interact with the system (or vice-versa).

Am I correct in assuming that anytime I add a repo to the system virtualmin will be notifying me of any updates from that repo?

Is there any way to tell them apart?

I needed the filters available in PHP 5.2.x which is why I added the atomic repo but other than that I only wanted to keep with the stock vm updates. I don't want to get into mixing and matching.

Any suggestions?

Thanks

Tue, 04/07/2009 - 12:08 (Reply to #4)
Joe
Joe's picture

<div class='quote'>I needed the filters available in PHP 5.2.x which is why I added the atomic repo but other than that I only wanted to keep with the stock vm updates. I don't want to get into mixing and matching.</div>

Then why not use our bleeding edge repo, that has PHP 5.2.9?

Documented here:

http://www.virtualmin.com/documentation/id,php_and_virtualmin/#bleeding_...

And here:

http://www.virtualmin.com/documentation/id,virtualmin_bleeding_edge_pack...

--

Check out the forum guidelines!

Wed, 04/08/2009 - 04:17 (Reply to #5)
rduval

I think I may be able to answer my own question. In /etc/yum.repos.d theres a file called atomic.repo which I have renamed to atomic.repo.old

So will that do the trick or will that cause any other problems?

I read the bleeding edge info, I really don't want bleeding edge anything. I really do want stable. The atomic repo was the only way I could find to update PHP to a version that had the filters. Apparently any 5.2.x would have done the job it didn't have to be 5.2.9.

Like I said.... repos and handling the updates are really still a bit of a mystery to me...

Wed, 04/08/2009 - 05:28 (Reply to #6)
andreychek

Another option for disabling a repo would be to edit the config file itself, and add this line: enabled=0

As far as the stability of this repo goes -- the most stable packages are going to be those included with your distro.

Once you go outside of that, you might as well use the Virtualmin Bleeding Edge repo. Lots of folks use it, Joe uses it on his own systems, and it's known to work well with Virtualmin.

So I'd say, if you need PHP 5.2.x, then go for it :-)
-Eric

Wed, 04/08/2009 - 20:46 (Reply to #7)
Joe
Joe's picture

<div class='quote'>I read the bleeding edge info, I really don't want bleeding edge anything. I really do want stable. The atomic repo was the only way I could find to update PHP to a version that had the filters. Apparently any 5.2.x would have done the job it didn't have to be 5.2.9.</div>

You're misunderstanding me.

The atomic repository is also providing bleeding edge packages. They just aren't nice enough to tell you so. CentOS packages are <i>dramatically</i> better tested than our bleeding edge repo packages <i>or</i> the atomic repo packages.

However, saying that both our packages and theirs are bleeding edge makes it sound like they are equal. In this case, they are not. Ours are known to work in the Virtualmin environment. Theirs are not (they might; I'm not suggesting there's anything wrong with the atomic packages). If you want pain-free PHP 5.2.x packages in a Virtualmin environment...wouldn't it make sense to use the ones provided by us and tested by us?

--

Check out the forum guidelines!

Thu, 04/09/2009 - 02:12 (Reply to #8)
rduval

I hear you Joe. I just wasn't aware that PHP 5.2.x was considered bleeding edge. I just wanted the filters element of PHP which wasn;t available and after googling around I found a step by step to install the latest PHP and it happened to be the atomic repository. It wasn't a conscious choice NOT to use yours.

I didn't know that yours existed and that it would have given me the version of PHP I needed or I definitely would have used yours. Stability is what I want and as you say yours is tested with Virtualmin so If I'd known about it I would have made that choice.

Thu, 04/09/2009 - 07:59 (Reply to #9)
Joe
Joe's picture

<div class='quote'>I just wasn't aware that PHP 5.2.x was considered bleeding edge.</div>

PHP 5.2.x is not considered bleeding edge. The <i>packages</i> in these third party repositories <i>are</i>. As I mentioned, our repos and pretty much all third party repos are tested by dramatically fewer users, and maintained by a much smaller group of people than the CentOS standard packages (which have the RHEL quality control folks behind them). The purpose of CentOS (and RHEL) is the provide a stable, reliable, secure, platform that doesn't change, and doesn't break. The purpose of most third party repositories is to provide a lot of packages. In general, third party repo packages are tested on <i>one</i> system before shipping (ours are tested on two, which isn't much better). The package is not merely the software contained within, and often problems come not from the software inside but the actual packaging.

But, if you need PHP 5.2.x, you need to get it from somewhere...so we provide it. Just so you can avoid running into other compatibility issues. At least you know that ours are nearly identical (in packaging) to the CentOS 5.1.6 packages, since that's what our packages are based on (our packaging policy is to replicate the OS-standard as much as possible...other third party repos may have other packaging policies and priorities).

Anyway, to get back to your original problem, you just have to be careful what you feed yum. It'll gobble up the latest versions of whatever is available (and the Virtualmin interface to yum has no way of distinguishing which ones are safe/sane and which ones are not). I'm not saying you should never use any third party repositories, or that the packages found within them are broken or bad, just that they <i>might</i> be broken or bad and that you need to exercise good judgement when using them, and understand the implications. Which generally means getting to know the exclude and includePkgs options in the yum configuration files.

--

Check out the forum guidelines!

Mon, 04/06/2009 - 10:43
rduval

Thanks but I don't understand why these &quot;updates&quot; are coming up if it's incompatible? This was a clean install from the virtualmin script on CentOS 5.2. The only other thing done was to update PHP to 5.2.9

Is this somehow related?

Tue, 04/07/2009 - 12:06 (Reply to #11)
Joe
Joe's picture

<div class='quote'>Thanks but I don't understand why these &quot;updates&quot; are coming up if it's incompatible? This was a clean install from the virtualmin script on CentOS 5.2.</div>

It's not a clean install. You have a third-party yum repository configured, and it has packages that are not compatible with ours.

You have to choose. You can't safely use the same package from multiple repositories.

You should also be very careful about configuring third party repositories if you don't understand the implications. There can be security concerns, stability concerns, and compatibility concerns, and third party repositories (including ours) have dramatically less testing than the OS standard repositories. That's not to say you should never use them (obviously, we recommend you use ours), but that you should understand those implications and think long and hard about what you need and don't need.

--

Check out the forum guidelines!

Mon, 04/06/2009 - 16:14
mdtiberi

Rick:

I also had the same issue. I use the atomic repo as well as ASL (Atomic Secured Linux) kernel. You have to make a choice between .art's package or .vm's. They are incompatible. The clamd database resides in different directories depending on which repo you use and owners are different. If you use .art then you have to make sure a clamd user and group are created.

I would recommend that you stick with the .vm package unless you have the asl kernel installed.

Mon, 04/06/2009 - 16:32
mdtiberi

BTW, the ticket mentioned in Eric's post is unrelated to your issue since your using the art repo.

Tue, 04/07/2009 - 08:05
mdtiberi

When you execute yum for updates it checks /etc/yum.repos.d/ for what repositories to query. You must be careful about accepting updates from various repos. I can only speak to .art since I have been using it for quite some time and have had zero issues with them. Perhaps now and then a conflict might arise but it's usually easily solved. Take advantage of the atomic forum as there are many expert users there and they are very helpful.

The only package I had any issues with is clam only because Atomics secured kernel installs a number of security packages like osses-hids, grsec, denyhosts, and clamd etc. It forced me to resolve the clam conflict issue. I would recommend that you stick to .vm for clam and use atomics repo for apps like php, mysql, etc.

BTW, it appears that you don't work from the command line and just use the webmin GUI. A simple way to disable a repo is by just renaming the appropriate file in /etc/yum/repos.d/. For example you will see a file atomic.repo, if you rename it to say atomic.repoold then yum will not check it. You could also disable it by editing the file as well.

Wed, 04/08/2009 - 03:57
rduval

Now that I have the atomic repo installed, how do remove the repo?

I'm assuming the removing the repo won't affect anything installed from that repo but I won't get any updates from it. Is that correct?

Sorry, repos are a bit of a mistery to me at this point.

Thu, 04/09/2009 - 08:31
mdtiberi

<div class='quote'>PHP 5.2.x is not considered bleeding edge. The packages in these third party repositories are.</div>

This may be true of other repositories but it is certainly not when it comes to atomics repo. I say this as a long time user of atomics packages. If you visit there forum you will find that it is host to many large and small users alike.

Topic locked