Re: [CentOS] sa-update error with perl
>>> OK ... then it ought to move (probably) :) >> >> See my post on repoforge users list. >> http://lists.repoforge.org/pipermail/users/2012-January/022634.html >> There's no one to move the package but Dag. > > Per your suggestion, I filed a bug report on this, although > that tracker seems like a lonely place. :) > > https://github.com/repoforge/repoforge.github.com/issues/2 FYI for the CentOS list, this issue has been resolved (perl-NetAddr-IP has been moved to the RepoForge extras repository). Yum no longer complains that perl-NetAddr-IP has to be updated and spamassassin does not produce errors. Thanks again ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
>> OK ... then it ought to move (probably) :) > > Se my post on repoforge users list. > http://lists.repoforge.org/pipermail/users/2012-January/022634.html > There's no one to move the package but Dag. Per your suggestion, I filed a bug report on this, although that tracker seems like a lonely place. :) https://github.com/repoforge/repoforge.github.com/issues/2 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
>> And then there's the problem Nicolas is pointing out, which seems >> to be part of my problem. If such conflicting packages are supposed >> to be in rfx but are not. Maybe Daniel could move it, which >> would definitely help my yum to stop complaining > > It is now part of RFX and not part of RF. If you look here, you will > see no perl-NetAddr-IP now in RF. > > http://apt.sw.be/redhat/el6/en/x86_64/ > > (there is a repoforge and and extras dir under there) I'm on a 32 bit machine, not sure if that makes a difference. What I do know is this: yum update == Package Arch Version Repository Size == Updating: perl-NetAddr-IP i386 4.044-1.el5.rf rpmforge 140 k Transaction Summary == Install 0 Package(s) Upgrade 1 Package(s) Is this because I need to migrate something from rpmforge to RepoForge??? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
> And then there's the problem Nicolas is pointing out, which seems > to be part of my problem. If such conflicting packages are supposed > to be in rfx but are not. Maybe Daniel could move it, which > would definitely help my yum to stop complaining David not Daniel. My apologies missing your name. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
>>> Well, kind of. If you review this thread, you'll see that the the >>> fix >>> was to stop using the RepoForge package for perl-NetAddr-IP so that it >>> wasn't mixed with CentOS packages for perl-Net-DNS and >>> perl-IO-Socket-INET6. Maybe your position is that you won't fix >>> perl-NetAddr-IP because you only support it when used when all other >>> packages are from RepoForge, but I don't think that's realistic >>> at all >>> - everyone running CentOS will have mostly CentOS packages - >>> naturally. They'll pick up some others they want or need for >>> various >>> reasons from RepoForge, so I'd imagine you'll see mixing of >>> packages >>> quite often amongst people who add RepoForge to their yum systems. >>> Therefore, I'd have thought you'd be interested to learn of an >>> incompatibility in one of the RepoForge packages. >> Well, >> I will definitely not fix it. Most of users does not pick up the >> particular packages but enables the repo entity. Basically it would be >> really hard to support both scenarios. I consider packages you mention >> as a whole email stack provided by RF. The stack includes: >> amavisd-new >> spamassassin >> dependent perl-\* >> dependent file de-compressors >> Regards, >> DH > I agree with David here ... > > repoforge has moved all packages that replace CentOS base packages to > their rfx (repoforge extras) repository. > > If you are going to use rfx packages, you likely need to use all > relevant rfx packages and not mix and match (which is what caused this > problem). In this case, that would include the whole stack for > spamassassin. This DOES replace base CentOS packages ... but that is the > purpose of the RFX repo, so don't enable it in the first place if you > don't want to replace CentOS packages. And if you DO want to replace > CentOS packages, then replace them all for the things you are installing > from rfx. > > A different way to accomplish the same thing without replacing CentOS > base packages (if your goal is to prevent replacing base packages ... > which may or may not be your goal) is to first try EPEL. EPEL has a > version of amavisd-new (for this particular scenario) which works > properly with all the base CentOS packages. A goal of EPEL is that they > can not replace packages from RHEL (so also not CentOS). But the version > of amavisd-new is older in EPEL than the one in RFX. Which is best ... > that is up to you. > > I am not recommending one approach over the other ... which approach you > take depends on your goals. Most of the time my personal goals are to > stay as close to the enterprise OS as I possibly can and only replace > packages if absolutely necessary, so I would likely try EPEL first and > go to RFX later. But, I do not know of any packages in RFX that break > things, so I think either approach can be equally "stable" on CentOS > servers. I don't 100% understand your explanation of EPEL, but I'm definitely going to go learn about it. > The bottom line is that you need to understand what you are trying to > accomplish and adjust your strategy as necessary. You need to understand > what the goals of a repository is before you enable it (does it replace > base packages, do I want to try to block that aspect of the repo, etc) > ... and you need to enable it correctly if you intend to use it. > > For RFX (as an example)... if you enable things like yum-priorities > (which will always choose base/updates from CentOS over newer packages > from RFX), that is going to cause issues where some packages from RFX > may not work properly with the base CentOS packages. > > Adding 3rd party repos is complicated and if you do it, you need to pay > close attention to what each one does and enable it properly. You can't > expect 3rd party repos to support using only parts of the repo and not > others (ie, yum-priorities) ... but you also can't expect CentOS to > support the packages installed by the 3rd party repos that replace base > packages. Therefore, YOU have to support yourself if you add them :D I understand this in principle, but I think reality ends up being a little more difficult. I think I ended up with what RepoForge packages I did because at the time I built the server, CentOS either didn't have amavisd-new at all or RepoForge's was newer and without knowing about yum-priorities, I got the RepoForge one (and a bunch of other dependencies) without really understanding the implications (I had enabled RepoForge to get a version of Postfix that wasn't horribly crippled, although at this point both RepoForge and CentOS's versions of postfix are deplorably ancient - compiling by hand may be in order). So I could have been better educated for sure, but the way it plays out also isn't going to be straight forward in a lot of cases I think. Maybe RepoForge should make it more clear on their site what the implications of using their packages are or that users may want to use yum-priorities for a bett
Re: [CentOS] sa-update error with perl
>> Why? Just remove that package and install the one from CentOS. >> Spamassassin doesn't need to be touched. > > Seems to me that you are still using the mix of repos. Packages from RF > work fine. Well, kind of. If you review this thread, you'll see that the the fix was to stop using the RepoForge package for perl-NetAddr-IP so that it wasn't mixed with CentOS packages for perl-Net-DNS and perl-IO-Socket-INET6. Maybe your position is that you won't fix perl-NetAddr-IP because you only support it when used when all other packages are from RepoForge, but I don't think that's realistic at all - everyone running CentOS will have mostly CentOS packages - naturally. They'll pick up some others they want or need for various reasons from RepoForge, so I'd imagine you'll see mixing of packages quite often amongst people who add RepoForge to their yum systems. Therefore, I'd have thought you'd be interested to learn of an incompatibility in one of the RepoForge packages. > root@specs2:1280:279:/$ rpm -q spamassassin perl-IO-Socket-INET6 > perl-Net-DNS perl-NetAddr-IP| sort > perl-IO-Socket-INET6-2.57-2.el5.rfx > perl-NetAddr-IP-4.044-1.el5.rf > perl-Net-DNS-0.66-1.el5.rfx > spamassassin-3.3.2-2.el5.rfx ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] yum-priorities behavior with downgrades [was: sa-update error with perl]
After solving my problem by downgrading perl-NetAddr-IP to the CentOS repo's version, yum is of course telling me perl-NetAddr-IP is out of date and needs to be updated (back to the buggy one in RepoForge). So looks like yum-priorities is in order (ha! the pun!), but I have a question >> Hmm, OK, prioritze CentOS repo over RepoForge then will yum update >> figure out the rest? I don't see any priority settings in my yum conf >> files... > > # yum list | grep priorities > yum-priorities.noarch 1.1.16-16.el5.centos > installed > > # cat /etc/yum/pluginconf.d/priorities.conf > [main] > enabled = 1 > check_obsoletes=1 > > Then add "priority=n" to the repos sections. > n=1 for CentOS > n=2 for repo 2 > etc... If I already have a bunch of packages from RepoForge, some of which might also be in the CentOS repo (some presumably with lower version numbers), what happens after installing and configuring yum-priorities? Do those packages automatically get downgraded? Does yum complain and tell me I should downgrade? I assume upgrades would happen per usual if there are newer versions of packages in CentOS repo. I'm slightly concerned because I have a handful of packages that got installed automatically from RepoForge when I installed amavisd-new from there, and I'd hate to break something. Thanks for any preemptive advice ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
>> I have three e-mail servers and the error is on all three. >> >> [root@MailIn ~]# service spamassassin restart >> Stopping spamd: [ OK ] >> Starting spamd: Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at > /usr/lib/perl5/5.8.8/Exporter.pm line 65. >> at > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm > > line 66 >> [ OK ] >> >> When you report the bug would you post the bug number so we could follow > it. > > The problem was solved for the OP when he downgraded perl-NetAddr-IP to > use the stock version from centos (perl-NetAddr-IP-4.027-5.el5_6) > instead of the one from repoforge. > Doesn't this solve it for you? > - > > Thanks! > > I will not be able to change things for a couple of days, but sure > appreciate the information. Looks like I will need to remove > spamassassin and then re-install it. Why? Just remove that package and install the one from CentOS. Spamassassin doesn't need to be touched. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
>> Is there somewhere at RepoForge I could notify them about this? > > users mailing list: > us...@lists.repoforge.org > http://lists.repoforge.org/mailman/listinfo/users Thank you. I am reporting it now ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
>> So maybe I *do* need to open a bug report? Where do I do
>> that?
>
> can you try to disable ipv6, then reboot and see if you still
> get the
> error message?
Sorry, it's a production machine, I'd rather not do that.
I can
make small
changes but a reboot-- Beside, if this is the set of packages
CentOS
gives me when I install something like spamassassin, it seems like
they should work no matter what. But don't get me wrong, I
really
appreciate your suggestion.
>>>
>>> It is not the CentOS packages causing your issues. I told you already
>>> that I have spamassassin running with these packages with no problems:
>>
>> Although I have the 32-bit packages which could be slightly different, no?
>>
>> That said, I would tend to think you're correct:
>>
>>> The issue you are having, based on the error that you posted, is that
>>> something else is already providing the subroutine
>>> "Net::DNS::Resolver::Base::AF_INET6" when it is trying to be
>>> loaded by
>>> perl module provided by CentOS (perl-Net-DNS-0.59-3.el5.i386). What we
>>> do not know is what ELSE is providing that routine.
>>
>> It seems like it shouldn't be hard to grep for who the culprit is, but
>> what
>> do I know - doing this didn't turn up anything I could too easily
>> decypher:
>>
>> cd /usr/lib/perl5
>> grep -rin 'af_inet6' *
>>
>> I only got 40 lines of output from that so I could post them if needed.
>> Grepping exactly for "sub af_inet6" gives me only one result:
>>
>> 5.8.8/i386-linux-thread-multi/bits/socket.ph:66: eval 'sub AF_INET6
>> () { &PF_INET6;}' unless defined(&AF_INET6);
>>
>> Are there modules that are placed somewhere other than
>> /usr/lib/perl5 that could have the offending code? Or is this
>> a fruitless way to track down the problem?
>>
>
> perl-NetAddr-IP-4.044-1.el5.rf <=== I think that is the problem package
>
> I don't know if that version is required by the repoforge packages ... but
> base contains perl-NetAddr-IP-4.027-5.el5_6
>
> I would see if I could replace perl-NetAddr-IP-4.044-1.el5.rf from repoforge
> with perl-NetAddr-IP-4.027-5.el5_6 from base.
rpm -e --nodeps perl-NetAddr-IP
vi /etc/yum.repos.d/rpmforge.repo
-- change all enabled = 1 to enabled = 0 temporarily (seems like
yum priorities is going to be a good idea) --
yum install perl-NetAddr-IP
/etc/init.d/spamassassin condrestart
Stopping spamd: [ OK ]
Starting spamd: [ OK ]
That did it. Thanks a lot to Nicolas for sharing and thanks very very
much to Johnny for the patient help.
Is there somewhere at RepoForge I could notify them about this?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
So maybe I *do* need to open a bug report? Where do I do that?
>>>
>>> can you try to disable ipv6, then reboot and see if you still get the
>>> error message?
>>
>> Sorry, it's a production machine, I'd rather not do that. I can
>> make small
>> changes but a reboot-- Beside, if this is the set of packages CentOS
>> gives me when I install something like spamassassin, it seems like
>> they should work no matter what. But don't get me wrong, I really
>> appreciate your suggestion.
>
> It is not the CentOS packages causing your issues. I told you already
> that I have spamassassin running with these packages with no problems:
Although I have the 32-bit packages which could be slightly different, no?
That said, I would tend to think you're correct:
> The issue you are having, based on the error that you posted, is that
> something else is already providing the subroutine
> "Net::DNS::Resolver::Base::AF_INET6" when it is trying to be loaded by
> perl module provided by CentOS (perl-Net-DNS-0.59-3.el5.i386). What we
> do not know is what ELSE is providing that routine.
It seems like it shouldn't be hard to grep for who the culprit is, but what
do I know - doing this didn't turn up anything I could too easily decypher:
cd /usr/lib/perl5
grep -rin 'af_inet6' *
I only got 40 lines of output from that so I could post them if needed.
Grepping exactly for "sub af_inet6" gives me only one result:
5.8.8/i386-linux-thread-multi/bits/socket.ph:66: eval 'sub AF_INET6 () {
&PF_INET6;}' unless defined(&AF_INET6);
Are there modules that are placed somewhere other than
/usr/lib/perl5 that could have the offending code? Or is this
a fruitless way to track down the problem?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
>>> I don't know what is causing your specific issue ... whether you >>> are >>> getting something newer in sa-update than is designed to work with >>> CentOS (sa-update bypasses the normal rpm type updates and does updates >>> from elsewhere). It should only update rules, so maybe some of the new >>> rules require a new version of perl-Net-DNS. If that is the case, then >>> a Red Hat bugzilla entry needs to be made. >> >> See above - it's the spamassassin restart that causes the error, in >> the end, nothing really to do with sa-update. >> >>> If it will not work with the CentOS version of perl-Net-DNS and if it >>> works with the rfx version, then obviously you would run that. If that >>> is the case, we need to get the rhel one upgraded. >> >> So maybe I *do* need to open a bug report? Where do I do that? > > can you try to disable ipv6, then reboot and see if you still get the > error message? Sorry, it's a production machine, I'd rather not do that. I can make small changes but a reboot-- Beside, if this is the set of packages CentOS gives me when I install something like spamassassin, it seems like they should work no matter what. But don't get me wrong, I really appreciate your suggestion. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
>>> But before I try that, I'm wondering, shouldn't it be easy >>> from the error message to simply understand what package >>> is creating the problem? >>> >>> It turns out it's not sa-update specifically doing this, but the >>> restart of spamassassin itself: >>> >>> /etc/init.d/spamassassin condrestart >>> >>> Stopping spamd: [ OK ] >>> Starting spamd: Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined > at >>> /usr/lib/perl5/5.8.8/Exporter.pm line 65. >>> at >>> > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm > > >>> line 66 >>> [ OK ] >>> >>> I've ensured that my spamassassin, perl-Net-DNS and >>> per-IO-Socket-INET6 packages are all from the CentOS >>> repo, so is it just a crap shoot to find what is causing >>> this? I'd expect the error message to be more helpful >>> than that... >>> >>> Recap on my versions: >>> >>> perl-IO-Socket-INET6-2.51-2.fc6 >>> perl-Net-DNS-0.59-3.el5 >>> spamassassin-3.3.1-2.el5 >> In fact, it was suggested on the spamassassin list that version >> 0.59-3.el5 is vastly out of date and known to be buggy and, >> contrary to the suggestion here of ensuring I prioritize CentOS >> repos, I would be better served to get the newer version of >> per-Net-DNS from the RepoForge (extras) repository. >> >> Other thoughts (on this or my main question in my last email >> above) would be greatly appreciated. > > RHEL (and therefore CentOS) is designed to work with items that it uses > as dependencies. > If you know what you are doing and understand how to validate the > dependency trees, check for repo closure, etc ... then upgrading items > to newer versions is fine. If you do not know how to do that, then you > end up with a hot pile of mess and eventually an unusable system. I understand, and I agree. My strongest desire is to stay away from all this manual manipulation. But (see above) I *AM* using the newest spamassassin and per-Net-DNS (where the error is happening?) packages from the CentOS repo, so why in the world are they not working together?? That's the kicker. What else can I do if CentOS provides buggy packages? > I don't know what is causing your specific issue ... whether you are > getting something newer in sa-update than is designed to work with > CentOS (sa-update bypasses the normal rpm type updates and does updates > from elsewhere). It should only update rules, so maybe some of the new > rules require a new version of perl-Net-DNS. If that is the case, then > a Red Hat bugzilla entry needs to be made. See above - it's the spamassassin restart that causes the error, in the end, nothing really to do with sa-update. > If it will not work with the CentOS version of perl-Net-DNS and if it > works with the rfx version, then obviously you would run that. If that > is the case, we need to get the rhel one upgraded. So maybe I *do* need to open a bug report? Where do I do that? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
>>> 1.) Attacker uses apache remote exploit (or other means) to obtain >>> your /etc/shadow file (not a remote shell, just GET the file >>> without that fact being logged); >> >> I don't mean to thread-hijack, but I'm curious, if apache runs as >> its >> own non-root user and /etc/shadow is root-owned and 0400, then >> how could any exploit of software not running as root ever have >> access to that file?? > > Apache starts as root so it can open port 80. Certain bugs might > happen before it switched to a non-privileged user. But, a more > likely scenario would be to get the ability to run some arbitrary > command through an apache, app, or library vulnerability, and that > command would use a different kernel, library, or suid program > vulnerability to get root access. Look back through the update > release notes and you'll find an assortment of suitable bugs that have > been there... That makes sense - but that scenario seems like the vulnerability is more in some third party application or tool that happens to be executable by apache. Seems like the best defense against that is not running things like WordPress ;-p :-) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
>>> Hmm, OK, prioritze CentOS repo over RepoForge then will yum update > >>> figure out the rest? I don't see any priority settings in my yum > conf >>> files... >> >> # yum list | grep priorities >> yum-priorities.noarch 1.1.16-16.el5.centos > installed >> >> # cat /etc/yum/pluginconf.d/priorities.conf >> [main] >> enabled = 1 >> check_obsoletes=1 >> >> Then add "priority=n" to the repos sections. >> n=1 for CentOS >> n=2 for repo 2 >> etc... > > Ah, it's a separate package. OK thanks for the info! > > But before I try that, I'm wondering, shouldn't it be easy > from the error message to simply understand what package > is creating the problem? > > It turns out it's not sa-update specifically doing this, but the > restart of spamassassin itself: > > /etc/init.d/spamassassin condrestart > > Stopping spamd: [ OK ] > Starting spamd: Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at > /usr/lib/perl5/5.8.8/Exporter.pm line 65. > at > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm > > line 66 > [ OK ] > > I've ensured that my spamassassin, perl-Net-DNS and > per-IO-Socket-INET6 packages are all from the CentOS > repo, so is it just a crap shoot to find what is causing > this? I'd expect the error message to be more helpful > than that... > > Recap on my versions: > > perl-IO-Socket-INET6-2.51-2.fc6 > perl-Net-DNS-0.59-3.el5 > spamassassin-3.3.1-2.el5 In fact, it was suggested on the spamassassin list that version 0.59-3.el5 is vastly out of date and known to be buggy and, contrary to the suggestion here of ensuring I prioritize CentOS repos, I would be better served to get the newer version of per-Net-DNS from the RepoForge (extras) repository. Other thoughts (on this or my main question in my last email above) would be greatly appreciated. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
> 1.) Attacker uses apache remote exploit (or other means) to obtain > your /etc/shadow file (not a remote shell, just GET the file > without that fact being logged); I don't mean to thread-hijack, but I'm curious, if apache runs as its own non-root user and /etc/shadow is root-owned and 0400, then how could any exploit of software not running as root ever have access to that file?? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
>> Hmm, OK, prioritze CentOS repo over RepoForge then will yum update >> figure out the rest? I don't see any priority settings in my yum conf >> files... > > # yum list | grep priorities > yum-priorities.noarch 1.1.16-16.el5.centos > installed > > # cat /etc/yum/pluginconf.d/priorities.conf > [main] > enabled = 1 > check_obsoletes=1 > > Then add "priority=n" to the repos sections. > n=1 for CentOS > n=2 for repo 2 > etc... Ah, it's a separate package. OK thanks for the info! But before I try that, I'm wondering, shouldn't it be easy from the error message to simply understand what package is creating the problem? It turns out it's not sa-update specifically doing this, but the restart of spamassassin itself: /etc/init.d/spamassassin condrestart Stopping spamd: [ OK ] Starting spamd: Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm line 66 [ OK ] I've ensured that my spamassassin, perl-Net-DNS and per-IO-Socket-INET6 packages are all from the CentOS repo, so is it just a crap shoot to find what is causing this? I'd expect the error message to be more helpful than that... Recap on my versions: perl-IO-Socket-INET6-2.51-2.fc6 perl-Net-DNS-0.59-3.el5 spamassassin-3.3.1-2.el5 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
>> The only hints I can find seem to suggest to remove >> perl-IO-Socket-INET6, but trying to do so using yum (I > don't >> want to start using another method of package > management) >> tells me that spamassassin is a dependency and will also > be >> removed - obviously undesirable. > If you really want to remove it, use rpm instead. > rpm -e --nodeps perl-IO-Socket-INET6 > But it will annoy you at every update... That was my fear... I'm wondering why this crept up again, since all my packages are completely up to date according to yum. >>> >>> yum only does what we tell it to do. >> >> I told it to update all my packages. :-) >> >>> It is possible that you have a package installed that is not from the >>> CentOS repos, etc. >>> >>> If people add external repositories, it is very easy to get conflicts. >> >> I do have rpmforge as a repo in order to get a thing or two that >> CentOS does not offer. How can I diagnose if this is the problem? >> Here's a list of perl packages according to rpm -qa are the > ".rf" >> ones from rpmforge? I think most of those are requirements for the >> amavisd-new package. >> > > .rf? is from RepoForge (ex-RPMForge). > > You might need to use priorities and set RepoForge lower then SA repo. > maybe you will need to downgrade few packages. Hmm, OK, prioritze CentOS repo over RepoForge then will yum update figure out the rest? I don't see any priority settings in my yum conf files... I'll have to read up on that. Interestingly, I get this: rpm -q --whatrequires perl-IO-Socket-INET6 no package requires perl-IO-Socket-INET6 However, yum remove perl-IO-Socket-INET6 Loaded plugins: fastestmirror Setting up Remove Process Resolving Dependencies --> Running transaction check ---> Package perl-IO-Socket-INET6.noarch 0:2.51-2.fc6 set to be erased --> Processing Dependency: perl(IO::Socket::INET6) for package: spamassassin --> Running transaction check ---> Package spamassassin.i386 0:3.3.1-2.el5 set to be erased --> Processing Dependency: perl(Mail::SpamAssassin) for package: amavisd-new --> Running transaction check ---> Package amavisd-new.i386 0:2.6.6-1.el5.rf set to be erased --> Finished Dependency Resolution Dependencies Resolved == Package Arch Version Repository Size == Removing: perl-IO-Socket-INET6 noarch 2.51-2.fc6 installed 22 k Removing for dependencies: amavisd-new i386 2.6.6-1.el5.rf installed 2.7 M spamassassin i386 3.3.1-2.el5 installed 3.1 M Transaction Summary == Remove 3 Package(s) Reinstall 0 Package(s) Downgrade 0 Package(s) Is this ok [y/N]: n Exiting on user Command > There is "Perl package problems" thread on this list from ~20 days > ago. > Read it for more info. OK I'll go try to find it ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
The only hints I can find seem to suggest to remove perl-IO-Socket-INET6, but trying to do so using yum (I don't want to start using another method of package management) tells me that spamassassin is a dependency and will also be removed - obviously undesirable. >>> If you really want to remove it, use rpm instead. >>> rpm -e --nodeps perl-IO-Socket-INET6 >>> But it will annoy you at every update... >> That was my fear... I'm wondering why this crept up again, >> since all my packages are completely up to date according >> to yum. > > yum only does what we tell it to do. I told it to update all my packages. :-) > It is possible that you have a package installed that is not from the > CentOS repos, etc. > > If people add external repositories, it is very easy to get conflicts. I do have rpmforge as a repo in order to get a thing or two that CentOS does not offer. How can I diagnose if this is the problem? Here's a list of perl packages according to rpm -qa are the ".rf" ones from rpmforge? I think most of those are requirements for the amavisd-new package. perl-Net-DNS-0.63-1.el5.rf perl-URI-1.35-3 perl-libwww-perl-5.805-1.1.1 perl-Package-Constants-0.02-1.el5.rf perl-Pod-Escapes-1.04-1.2.el5.rf perl-Crypt-OpenSSL-RSA-0.26-1.el5.rf perl-NetAddr-IP-4.044-1.el5.rf perl-Socket6-0.19-3.fc6 perl-5.8.8-32.el5_7.6 perl-String-CRC32-1.4-2.fc6 perl-Digest-SHA1-2.11-1.2.1 perl-Digest-HMAC-1.01-15 perl-HTML-Tagset-3.20-1.el5.rf perl-IO-Socket-SSL-1.17-1.el5.rf perl-Compress-Zlib-1.42-1.fc6 perl-TimeDate-1.16-5.el5 perl-Convert-BinHex-1.119-2.2.el5.rf perl-Convert-TNEF-0.17-3.2.el5.rf perl-Mail-SPF-2.006-1.el5.rf perl-DBI-1.52-2.el5 perl-Digest-SHA-5.50-1.el5.rf perl-Crypt-OpenSSL-Random-0.04-1.el5.rf perl-Pod-Simple-3.16-1.el5.rf perl-Git-1.7.6.4-1.el5.rf perl-Unix-Syslog-1.1-1.el5.rf perl-Archive-Tar-1.39.1-1.el5_5.2 perl-Error-0.17016-1.el5.rf perl-Email-Date-Format-1.002-1.el5.rf perl-Mail-DKIM-0.39-1.el5.rf perl-Net-SSLeay-1.30-4.fc6 perl-IO-Zlib-1.09-1.el5.rf perl-HTML-Parser-3.59-1.el5.rf perl-IO-stringy-2.110-1.2.el5.rf perl-Archive-Zip-1.26-1.el5.rf perl-MIME-tools-5.420-2.el5.rf perl-Razor-Agent-2.84-1.el5.rf perl-DBD-MySQL-3.0007-2.el5 perl-BerkeleyDB-0.43-1.el5.rf perl-Convert-UUlib-1.34-1.el5.rf perl-Net-Server-0.99-1.el5.rf perl-Test-Pod-1.45-1.el5.rf perl-MIME-Lite-3.027-1.el5.rf perl-MailTools-2.08-1.el5.rf perl-version-0.91-1.el5.rf perl-IO-Socket-INET6-2.51-2.fc6 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
>>> On my Zimbra server (CentOS 5.7), sa works fine. > >>> I have spamassassin-3.3.1-2.el5 and >>> perl-IO-Socket-INET6-2.51-2.fc6 installed. >> Same here. Are you running sa-update? SpamAssassin works >> fine for me, but sa-update is giving this error every time it runs. > > Yes, it seems to run fine: > Updating (Sun Jan 1 00:00:01 CET 2012)... > Update available for channel updates.spamassassin.org > Update was available, and was downloaded and installed successfully Weird then. Wondering why I'm getting this problem. Name : spamassassin Arch : i386 Version : 3.3.1 Release : 2.el5 Size : 3.1 M Repo : installed Name : perl-IO-Socket-INET6 Arch : noarch Version : 2.51 Release : 2.fc6 Size : 22 k Repo : installed >>> Did you disable IPV6? >> No - can you explain what you are implying? > > Hum... not sure anymore why I asked... ^_^ > Nevermind. > > Did you install any perl libs out of rpm/yum...? > BTW, 64bits here... 32 for me. Thanks for your help... ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
John, THANK YOU very much for responding -- >> The only hints I can find seem to suggest to remove >> perl-IO-Socket-INET6, but trying to do so using yum (I don't >> want to start using another method of package management) >> tells me that spamassassin is a dependency and will also be >> removed - obviously undesirable. > > If you really want to remove it, use rpm instead. > rpm -e --nodeps perl-IO-Socket-INET6 > But it will annoy you at every update... That was my fear... I'm wondering why this crept up again, since all my packages are completely up to date according to yum. > On my Zimbra server (CentOS 5.7), sa works fine. > I have spamassassin-3.3.1-2.el5 and > perl-IO-Socket-INET6-2.51-2.fc6 installed. Same here. Are you running sa-update? SpamAssassin works fine for me, but sa-update is giving this error every time it runs. > Did you disable IPV6? No - can you explain what you are implying? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] sa-update error with perl
Hi, Running CentOS5 with SpamAssassin v3.3.1-2.el5 installed via yum I remember getting this error a while ago, and it was fixed, but now it's happening again: Subroutine Net::DNS::Resolver::Base::AF_INET6 redefined at /usr/lib/perl5/5.8.8/Exporter.pm line 65. at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Net/DNS/Resolver/Base.pm line 65 The results I get from Google regarding this are all circa 2008. The only hints I can find seem to suggest to remove perl-IO-Socket-INET6, but trying to do so using yum (I don't want to start using another method of package management) tells me that spamassassin is a dependency and will also be removed - obviously undesirable. Perl is up to date on the machinge. Am I the only one seeing this? What can I do to fix it? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Auto-updates -- Bad Idea?
> >>Is the only reasonable solution to schedule a "human cron" once a week >to look > >> at needed updates? Ouch. > > > > A middle-of-the-road approach is to have a machine or VM where you can > > test things, perhaps the one you use as your own desktop or for > > development, where you have all the packages installed that the other > > systems use. You can 'yum update' this one frequently, noting what > > packages are affected and that everything still works after a reboot > > (for things where that might make a difference). > > I use a VM set up this way with the following crontab: > > # check for yum updates every 12 hours > 5 0,12 * * * root /usr/bin/yum -q check-update 2>/dev/null > > so I get an email whenever there's any updates due. I can then > evaluate, test, and (perhaps) schedule a time to manually update the > production servers. The yum-updatesd package does all of this. Its config file is pretty simple and has your choice of whether to download, whether to install, and where updates should go. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Auto-updates -- Bad Idea?
- Original Message > From: Robert Heller > To: CentOS mailing list > Cc: centos@centos.org > Sent: Wed, April 6, 2011 11:58:46 AM > Subject: Re: [CentOS] Auto-updates -- Bad Idea? > > At Wed, 6 Apr 2011 11:35:47 -0700 (PDT) CentOS mailing list > >wrote: > > > > > Hello, > > > > As I've learned recently, I do not have any auto updates configured on > > my > > system. I see some posts on the web encouraging the use of "yum-cron", > > but >I'd > > > like to know what people feel about the use of automatic updates. > > > > That is, for a server (non-desktop) system, automatic updates could > > break > > things or have other unforeseen consequences, and that could happen at the >worst > > > of times, since the process runs regularly. > > > > On the other hand, for small businesses without highly trained sysadmins >or > > > ones with enough time to baby their servers, missing critical updates to, >say > > > openssl or some other mission-critical package could spell disaster. > > > > Is the only reasonable solution to schedule a "human cron" once a week > > to >look > > > at needed updates? Ouch. > > I use the "human cron" option. It might make some sense to use > "yum-cron", but the ideal way that would work best would be if the > machines using "yum-cron" were tied to a local repo that contains only > tested updates -- that is there would be developmental / test systems > getting manually updated and then the updates would be tested. Once the > updates have pased a QA process, they would be pushed to te internal / > local repo, where they would be automagically picked up by "yum-cron". > This covers both worlds: avoiding a automagical disaster AND automating > updates across a pile of machines without a lot of manual labor. > > For small shop, just doing manual updates is probably best. Generally, > basic CentOS updates are unlikely to cause problems, unless there is > odd (non-standard) q hardware and/or odd software involved, so for many > people a (blind) yum-cron might actually work just fine. It just > depends on how much of a disaster a machine brought down by a update > that happens to break something. Thanks for taking the time to answer. This seems to be the consensus of all those who answered, and that was my hunch, so that it is. Too bad those posting instructions for yum-cron on their blogs don't talk about these issues, but they are likely desktop users I suppose. Thanks again ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Auto-updates -- Bad Idea?
Hello, As I've learned recently, I do not have any auto updates configured on my system. I see some posts on the web encouraging the use of "yum-cron", but I'd like to know what people feel about the use of automatic updates. That is, for a server (non-desktop) system, automatic updates could break things or have other unforeseen consequences, and that could happen at the worst of times, since the process runs regularly. On the other hand, for small businesses without highly trained sysadmins or ones with enough time to baby their servers, missing critical updates to, say openssl or some other mission-critical package could spell disaster. Is the only reasonable solution to schedule a "human cron" once a week to look at needed updates? Ouch. Thanks in advance for your considered opinions. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Understanding yum automatic upgrades
> > It does look like updates are happening, but it's not clear to me by > > whom. > > do_update is set to "no", but notification is by "dbus", so I assumed > > that > > "dbus" is notifying another process to do the actual updates. Is > there > > a way I > > can track that down? > > > > > Are you sure the updates are actually getting installed, and it's > > not > > > just noise in the log from yum-updatesd? > > > > Well, if I can take it at its word, updates *are* happening. Here is > a > > snippet > > I clipped out of a logwatch a few months ago: > > > > - yum Begin > > > > > > Packages Updated: > > php-dba - 5.1.6-27.el5_5.3.i386 > > php - 5.1.6-27.el5_5.3.i386 > > php-devel - 5.1.6-27.el5_5.3.i386 > > php-cli - 5.1.6-27.el5_5.3.i386 > > php-common - 5.1.6-27.el5_5.3.i386 > > php-gd - 5.1.6-27.el5_5.3.i386 > > php-pdo - 5.1.6-27.el5_5.3.i386 > > php-mysql - 5.1.6-27.el5_5.3.i386 > > > > -- yum End - > > A much more reliable way to check is > rpm -qa --last |less Thanks for that. I think this clears things up -- it looks like the updates are all manual ones, especially judging from how dates are grouped. So I must apologize to you and the other responders on this thread. The notifications I have seen in logwatch must have been from manual updates that I was unaware of or did not remember. > or simply run > yum update > and see what it thinks needs updated yet. > > If things are reasonably up-to-date I would expect the --last list to > have a tzdata-2011b package listed near the top. Indeed, it's not there yet I see an update available. > One other thing the --last list will revel is WHEN the updates were > applied, if they consistently are at a particular time of the morning > then it may be based on a cron job. The date/times appear to indicate manual interaction from a human. In any case, my question seems to be answered. I will watch logwatch a little longer and make sure this is the case. Thanks to everyone and sorry for the confusion. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Understanding yum automatic upgrades
> > then the outstanding question is how to figure out why certain > > packages are not being updated. > > Well, first action: did you actually check with the repo that there is a > newer package? Yes. I'm not sure why would you think otherwise...? > Just because a package isn't updated doesn't mean it's not > working. I *do* think the updater is working, judging from my logwatch emails. But it's quite clear that some packages, clamav being the example here, are definitely not being updated. > Especially in the case of clamav I think you haven't done the > obvious. Why do you say that? What is the obvious? Checking for an update? Perhaps what would clear this up for you is to note that this is an ongoing issue, not anything *right now*. That is, I've watched clam tell me via logwatch that it is out of date for weeks at a time before I finally go log in and run "yum update clamav" on the command line, which updates things nicely as expected. So clearly in those cases there IS an update available (I also check via "yum info" before the update). So while *some* packages get updated automatically by some mystery process that no one here seems to know about (??), some *do not*. Please don't take me wrong; I'm grateful for the help, but while I'm not a highly skilled sysadmin, I'm not asking entirely bonehead questions I think. Correct me if I'm wrong though! :-) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Understanding yum automatic upgrades
> > Do you know how to determine which repo a particular package is from? For > > example, when I do "yum info" against clamav (which isn't receiving >automatic > > > updates), it just says "Repo: installed". I don't know what repo it comes >from. > > > "yum list clamav --showduplicates" should show you all clamav packages > available in all repos, and will show the installed version so you can > compare. Hmmm Command line error: no such option: --showduplicates > Also, do you have some software that could do updates automaticaly? I > think Virtualmin (like Webmin but for domain control, CPanel, etc.) can > be set to do automatic updates. I'm not looking for an auto-update system, I'm just trying to understand the one that is currently running (yum-updatesd and whomever is listening on the other end of dbus). It seems to work for the most part, but I want to understand why some packages don't get upgraded. A partial answer I got to that was that such packages would be from non-enabled repos, but when I do a "yum upgrade clamav" from the command line, it works fine -- doesn't that mean that the repo *IS* enabled? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Understanding yum automatic upgrades
> > >> >> Sorry if this is somewhat naive, but I'm a little confused as to >what > > >the > > >> >> criteria is for that which will get upgraded automatically by > > >> yum >and > > > what > > >> >> will not. > > >> >> > > >> >> I see in our logwatch messages from time to time that yum upgraded > > >> >> a bunch of stuff, but I also notice that yum will not upgrade >other > > >> >> packages at all (easy example is clamav, but there are others). > > >> >> > > >> >> Can someone explain or point me to where I can read about the > > > distinction > > >> >> between what is and is not subjected to automatic upgrade? > > >> > > > >> > More info: yum-updatesd is running and I do not have yum-cron. > > > yum-updatesd > > >> > does a fine job from what I can tell, but I still cannot understand > what > > >> > criteria it applies to know which packages get upgraded and which > > do > > >not. > > >> (?) > > >> > > > >> > The yum-updatesd configuration file is ultra-simple, so that > > doesn't > > >seem to > > >>be > > >> > where the update choice/distinction is being made. > > >> > > > >> > There seem to be people posting in various places that they prefer > > >> > to > > >use > > >> > yum-cron, but I have no problems with yum-updatesd and I suspect > >yum-cron > > >> > wouldn't address/answer my question anyway. > > >> > > > >> > Help? > > >> > > >> Yum-updatesd does not automatically install packages (unless you > > >> configure it to), it only notifies you of ones that need updating. If > > >> no one is manually doing it, and you don't have "do_update = yes" in > > >> /etc/yum/yum-updatesd.conf, then you have installed something else > > >> that is performing the updates automatically. > > > > > > It does look like updates are happening, but it's not clear to me by >whom. > > > do_update is set to "no", but notification is by "dbus", so I assumed >that > > > "dbus" is notifying another process to do the actual updates. Is there > > > a > > >way I > > > can track that down? > > > > > >> Are you sure the updates are actually getting installed, and it's not > > >> just noise in the log from yum-updatesd? > > > > > > Well, if I can take it at its word, updates *are* happening. Here is a > >snippet > > > I clipped out of a logwatch a few months ago: > > > > > > - yum Begin > > > > > > > > > Packages Updated: > > > php-dba - 5.1.6-27.el5_5.3.i386 > > >php - 5.1.6-27.el5_5.3.i386 > > > php-devel - 5.1.6-27.el5_5.3.i386 > > >php-cli - 5.1.6-27.el5_5.3.i386 > > >php-common - 5.1.6-27.el5_5.3.i386 > > > php-gd - 5.1.6-27.el5_5.3.i386 > > >php-pdo - 5.1.6-27.el5_5.3.i386 > > >php-mysql - 5.1.6-27.el5_5.3.i386 > > > > > > -- yum End - > > > > > >> P.S. The yum log doesn't have the year in the timestamp, and if it's > > >> not active it might not get rotated by logrotate. This can cause > > >> false messages sent from logwatch about packages that were installed > > >> last year. > > > > > > Hmm, is there a known fix for this? > > > > > > Rotate the log file yourself once a year. You can check if you are > > seeing this bug by looking at the /var/log/yum.log last modified time. > > If it was yesterday, then I suppose the packages were installed. > > > > As far as your other questions, how does it determine what packages to > > update, I think you will find it's not actually doing any updating. I > > have not used yum-updatesd to auto-update packages myself, but I would > > think it would automatically install any updated package. > > It's dated a couple days ago, so I'd say it's doing what it's supposed to. >I'm > > not sure what the "dbus" notification does, but I presume it's telling > someone > > to do the updating. It'd probably be more informative if I could understand >who > > is picking up such notifications. /etc/dbus-1/system.d/yum-updatesd.conf Doesn't really tell me anything. I'm guessing that someone is watching dbus for notifications, but I can't figure out how to see who that is. > Do you know how to determine which repo a particular package is from? For > example, when I do "yum info" against clamav (which isn't receiving > automatic > updates), it just says "Repo: installed". I don't know what repo it comes >from. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Understanding yum automatic upgrades
> >> >> Sorry if this is somewhat naive, but I'm a little confused as to > >> >> what >the > >> >> criteria is for that which will get upgraded automatically by yum and > > what > >> >> will not. > >> >> > >> >> I see in our logwatch messages from time to time that yum upgraded > >> >> a bunch of stuff, but I also notice that yum will not upgrade other > >> >> packages at all (easy example is clamav, but there are others). > >> >> > >> >> Can someone explain or point me to where I can read about the > > distinction > >> >> between what is and is not subjected to automatic upgrade? > >> > > >> > More info: yum-updatesd is running and I do not have yum-cron. > > yum-updatesd > >> > does a fine job from what I can tell, but I still cannot understand what > >> > criteria it applies to know which packages get upgraded and which do >not. > >> (?) > >> > > >> > The yum-updatesd configuration file is ultra-simple, so that doesn't >seem to > >>be > >> > where the update choice/distinction is being made. > >> > > >> > There seem to be people posting in various places that they prefer to >use > >> > yum-cron, but I have no problems with yum-updatesd and I suspect >yum-cron > >> > wouldn't address/answer my question anyway. > >> > > >> > Help? > >> > >> Yum-updatesd does not automatically install packages (unless you > >> configure it to), it only notifies you of ones that need updating. If > >> no one is manually doing it, and you don't have "do_update = yes" in > >> /etc/yum/yum-updatesd.conf, then you have installed something else > >> that is performing the updates automatically. > > > > It does look like updates are happening, but it's not clear to me by whom. > > do_update is set to "no", but notification is by "dbus", so I assumed that > > "dbus" is notifying another process to do the actual updates. Is there a >way I > > can track that down? > > > >> Are you sure the updates are actually getting installed, and it's not > >> just noise in the log from yum-updatesd? > > > > Well, if I can take it at its word, updates *are* happening. Here is a >snippet > > I clipped out of a logwatch a few months ago: > > > > - yum Begin > > > > > > Packages Updated: > > php-dba - 5.1.6-27.el5_5.3.i386 > >php - 5.1.6-27.el5_5.3.i386 > > php-devel - 5.1.6-27.el5_5.3.i386 > >php-cli - 5.1.6-27.el5_5.3.i386 > >php-common - 5.1.6-27.el5_5.3.i386 > > php-gd - 5.1.6-27.el5_5.3.i386 > >php-pdo - 5.1.6-27.el5_5.3.i386 > >php-mysql - 5.1.6-27.el5_5.3.i386 > > > > -- yum End - > > > >> P.S. The yum log doesn't have the year in the timestamp, and if it's > >> not active it might not get rotated by logrotate. This can cause > >> false messages sent from logwatch about packages that were installed > >> last year. > > > > Hmm, is there a known fix for this? > > > Rotate the log file yourself once a year. You can check if you are > seeing this bug by looking at the /var/log/yum.log last modified time. > If it was yesterday, then I suppose the packages were installed. > > As far as your other questions, how does it determine what packages to > update, I think you will find it's not actually doing any updating. I > have not used yum-updatesd to auto-update packages myself, but I would > think it would automatically install any updated package. It's dated a couple days ago, so I'd say it's doing what it's supposed to. I'm not sure what the "dbus" notification does, but I presume it's telling someone to do the updating. It'd probably be more informative if I could understand who is picking up such notifications. Do you know how to determine which repo a particular package is from? For example, when I do "yum info" against clamav (which isn't receiving automatic updates), it just says "Repo: installed". I don't know what repo it comes from. Thanks much ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Understanding yum automatic upgrades
> > Sorry if this is somewhat naive, but I'm a little confused as to what > > the > > criteria is for that which will get upgraded automatically by yum and what >will > > > not. > > > > I see in our logwatch messages from time to time that yum upgraded a > > bunch >of > > > stuff, but I also notice that yum will not upgrade other packages at all >(easy > > > example is clamav, but there are others). > > > > Can someone explain or point me to where I can read about the > > distinction > > between what is and is not subjected to automatic upgrade? > > > > Automatic upgrade (if "yum upgrade" is run), will upgrade all newer rpm > packages that are in *enabled* repositories. If you installed from > external repository that you keep disabled, those packages will not be > automatically upgraded. Well, as I mentioned, yum-updatesd is running and doing the automatic updates. I'm specifically referring to the automatic updates and not manual command line updates by me. But assuming that yum-updatesd does the same thing as "yum upgrade" (how do I confirm this?), then the outstanding question is how to figure out why certain packages are not being updated. To take my easy example, clamav, when I need to update clamav, I have to go to the command line and do a "yum upgrade clamav" and it works as expected. Doesn't that mean its repo is enabled? If so, why isn't yum-updatesd updating it for me? If not, how do I find which repo it's coming from so I can enable it? (yum info just says "installed" for the "Repo" field). TIA! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Understanding yum automatic upgrades
> >> Sorry if this is somewhat naive, but I'm a little confused as to what the > >> criteria is for that which will get upgraded automatically by yum and what > >> will not. > >> > >> I see in our logwatch messages from time to time that yum upgraded > >> a bunch of stuff, but I also notice that yum will not upgrade other > >> packages at all (easy example is clamav, but there are others). > >> > >> Can someone explain or point me to where I can read about the distinction > >> between what is and is not subjected to automatic upgrade? > > > > More info: yum-updatesd is running and I do not have yum-cron. yum-updatesd > > does a fine job from what I can tell, but I still cannot understand what > > criteria it applies to know which packages get upgraded and which do not. > (?) > > > > The yum-updatesd configuration file is ultra-simple, so that doesn't seem > > to >be > > where the update choice/distinction is being made. > > > > There seem to be people posting in various places that they prefer to use > > yum-cron, but I have no problems with yum-updatesd and I suspect yum-cron > > wouldn't address/answer my question anyway. > > > > Help? > > Yum-updatesd does not automatically install packages (unless you > configure it to), it only notifies you of ones that need updating. If > no one is manually doing it, and you don't have "do_update = yes" in > /etc/yum/yum-updatesd.conf, then you have installed something else > that is performing the updates automatically. It does look like updates are happening, but it's not clear to me by whom. do_update is set to "no", but notification is by "dbus", so I assumed that "dbus" is notifying another process to do the actual updates. Is there a way I can track that down? > Are you sure the updates are actually getting installed, and it's not > just noise in the log from yum-updatesd? Well, if I can take it at its word, updates *are* happening. Here is a snippet I clipped out of a logwatch a few months ago: - yum Begin Packages Updated: php-dba - 5.1.6-27.el5_5.3.i386 php - 5.1.6-27.el5_5.3.i386 php-devel - 5.1.6-27.el5_5.3.i386 php-cli - 5.1.6-27.el5_5.3.i386 php-common - 5.1.6-27.el5_5.3.i386 php-gd - 5.1.6-27.el5_5.3.i386 php-pdo - 5.1.6-27.el5_5.3.i386 php-mysql - 5.1.6-27.el5_5.3.i386 -- yum End - > P.S. The yum log doesn't have the year in the timestamp, and if it's > not active it might not get rotated by logrotate. This can cause > false messages sent from logwatch about packages that were installed > last year. Hmm, is there a known fix for this? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Understanding yum automatic upgrades
> Sorry if this is somewhat naive, but I'm a little confused as to what the > criteria is for that which will get upgraded automatically by yum and what >will > > not. > > I see in our logwatch messages from time to time that yum upgraded a bunch >of > > stuff, but I also notice that yum will not upgrade other packages at all > (easy > > example is clamav, but there are others). > > Can someone explain or point me to where I can read about the distinction > between what is and is not subjected to automatic upgrade? More info: yum-updatesd is running and I do not have yum-cron. yum-updatesd does a fine job from what I can tell, but I still cannot understand what criteria it applies to know which packages get upgraded and which do not. (?) The yum-updatesd configuration file is ultra-simple, so that doesn't seem to be where the update choice/distinction is being made. There seem to be people posting in various places that they prefer to use yum-cron, but I have no problems with yum-updatesd and I suspect yum-cron wouldn't address/answer my question anyway. Help? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Understanding yum automatic upgrades
Hello, Sorry if this is somewhat naive, but I'm a little confused as to what the criteria is for that which will get upgraded automatically by yum and what will not. I see in our logwatch messages from time to time that yum upgraded a bunch of stuff, but I also notice that yum will not upgrade other packages at all (easy example is clamav, but there are others). Can someone explain or point me to where I can read about the distinction between what is and is not subjected to automatic upgrade? Thanks! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
