RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 815568 - yum-security does not work with yum makecache and yum -C
Summary: yum-security does not work with yum makecache and yum -C
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: yum
Version: 6.2
Hardware: All
OS: All
medium
medium
Target Milestone: rc
: ---
Assignee: James Antill
QA Contact: Patrik Kis
URL: http://lists.baseurl.org/pipermail/yu...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-23 21:38 UTC by Christoph Anton Mitterer
Modified: 2014-01-21 06:25 UTC (History)
4 users (show)

Fixed In Version: yum-3.2.29-31.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 10:12:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0406 0 normal SHIPPED_LIVE yum bug fix and enhancement update 2013-02-20 20:50:44 UTC

Description Christoph Anton Mitterer 2012-04-23 21:38:01 UTC
Hi.

This is from http://lists.baseurl.org/pipermail/yum-devel/2012-April/009242.html :

What I do is running the nagios/icinga check_yum plugin periodically as 
non-root (!) user.
That the system is not cluttered with repository caches and because a 
simply yum check-update quite some time I run yum makecache periodically 
as root (!) via cron (every hour).

Now check_yum invokes yum like the following:
/usr/bin/yum --security check-update -C

Which leads as non-root user to the following output and error:
$ /usr/bin/yum --security check-update -C
Loaded plugins: changelog, downloadonly, fastestmirror, keys, 
priorities, protectbase, ps, security, verify
102 packages excluded due to repository priority protections
0 packages excluded due to repository protections
Limiting package lists to security relevant ones


[Errno 13] Permission denied: 
'/var/cache/yum/x86_64/6.2/epel/gen/updateinfo.xml'
$

Strace shows the following:
$ strace -e trace=open /usr/bin/yum --security check-update -C 2>&1 | 
grep EACCES
open("DB_CONFIG", O_RDONLY)             = -1 EACCES (Permission denied)
open("DB_CONFIG", O_RDONLY)             = -1 EACCES (Permission denied)
open("DB_CONFIG", O_RDONLY)             = -1 EACCES (Permission denied)
open("/var/cache/yum/x86_64/6.2/epel/20ea7be5624822f05d7cf61426ffcaf71f2104a5905ccc4880495741ab02a801-primary.sqlite", 
O_RDWR|O_CREAT, 0644) = -1 EACCES (Permission denied)
open("/var/cache/yum/x86_64/6.2/sl/primary.sqlite", O_RDWR|O_CREAT, 
0644) = -1 EACCES (Permission denied)
open("/var/cache/yum/x86_64/6.2/sl-security/primary.sqlite", 
O_RDWR|O_CREAT, 0644) = -1 EACCES (Permission denied)
open("/var/cache/yum/x86_64/6.2/epel/gen/updateinfo.xml", 
O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied)
$

All these files are root owned and -rw-r--r--.


When I then run
/usr/bin/yum --security check-update -C
as root, and after wards again as non-root user, it works for the 
non-root user (even though the permissions haven't changed. No idea why.



Hope you can provide a fix soon :)

Cheers,
Chris.


btw: I reported this here, as one cannot report bugs in the trac at http://yum.baseurl.org/ (missing permissions).

Comment 2 Christoph Anton Mitterer 2012-04-23 23:17:57 UTC
I tried to workaround that issue, by manually decompressing that file to ./gen
(as root and before I do the check as user).

But this does not (!!) help?!
Also, the file is already there (even though with an older timestamp and
therefore probably an older version of the file).

So how does check-update find out whether it needs to decompress that file or
not?
Cause when I ran /usr/bin/yum --security check-update -C as root before, then
it works as user, too.
There must be some condition that is now met, that yum no longer tries to
decompress it.


Cheers,
Chris.

Comment 3 Zdeněk Pavlas 2012-04-24 07:22:28 UTC
> There must be some condition that is now met, that yum no longer tries to
decompress it.

Hi, Yum compares timestamps, they have to match.  If you try to work this around by decompressing manually, adding "touch -r updateinfo.xml.gz gen/updateinfo.xml" should work.

Comment 4 James Antill 2012-04-24 14:15:45 UTC
 The easy way to work around it for all things is to use the data. Eg. for updateinfo change your cron to do:

yum makecache && yum updateinfo

...at least until we find a good way to fix this.

Comment 5 Christoph Anton Mitterer 2012-06-25 23:35:07 UTC
Hey...

Anything new here (read: chances for a real fix?) :-)

Cheers,
Chris.

Comment 6 James Antill 2012-07-31 20:09:11 UTC
Ok, posted a hacky fix for this upstream.

Comment 10 Christoph Anton Mitterer 2012-10-05 23:57:05 UTC
Hi James.

What is "yum updateinfo" actually doing? I haven't found it in the manpage.

So I guess this is being backported now to RHEL 6? When can we expect it there?


Thanks.

Comment 11 Karel Srot 2012-10-10 11:37:14 UTC
(In reply to comment #10)
> Hi James.
> What is "yum updateinfo" actually doing? I haven't found it in the manpage.

Hi,
you need to have yum-plugin-security installed, then check "man yum-security".

Comment 12 Christoph Anton Mitterer 2012-10-12 00:36:56 UTC
Hi

Uhm thanks, but that manpage does not really explain what happens, does it?

It merely tells that some file is downloaded, but not whether I (regularly) need to run updateinfo, in order to have all informations about security updates.
So is that the case?


Actually it seems to not even tell that one can run just "yum updateinfo"... in the manpage it shows just up with a 2nd argument info/list/summary.

Cheers,
Chris.

Comment 13 Karel Srot 2012-10-12 07:25:01 UTC
Hi,

(In reply to comment #12)
> Hi
> Uhm thanks, but that manpage does not really explain what happens, does it?
> 
> It merely tells that some file is downloaded, but not whether I (regularly)
> need to run updateinfo, in order to have all informations about security
> updates.
> So is that the case?

the information is taken from the updateinfo.xml file which is part of the repository. If you have up-to-date metadata, you have also recent information. If you want to be sure, refresh the yum cache manually (e.g. yum makecache). Otherwise you can rely on yum itself to fetch recent metadata when available.

> Actually it seems to not even tell that one can run just "yum updateinfo"...
> in the manpage it shows just up with a 2nd argument info/list/summary.

Yes, the summary command is the default.

I have filed a bug 865694  addressing some errors in the man page. Please, add a comment if I have missed something. Thank you in advance.

Comment 15 Christoph Anton Mitterer 2012-12-04 00:05:04 UTC
Should this already work in RHEL 6.3 now? Cause it seems not to.

Thx,
Chris.

Comment 16 Karel Srot 2012-12-04 07:06:23 UTC
Hello Chris, 
this bug will be fixed in RHEL 6.4.

Comment 18 errata-xmlrpc 2013-02-21 10:12:39 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0406.html


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