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 666463 - [RHEL 6] rhnplugin does not respect metadata_expire setting
Summary: [RHEL 6] rhnplugin does not respect metadata_expire setting
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: yum-rhn-plugin
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Miroslav Suchý
QA Contact: Martin Minar
URL:
Whiteboard:
Depends On: 666876
Blocks: 666534
TreeView+ depends on / blocked
 
Reported: 2010-12-30 23:52 UTC by John Ruemker
Modified: 2018-11-27 21:47 UTC (History)
9 users (show)

Fixed In Version: yum-rhn-plugin-0.9.1-9
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 666534 666876 (view as bug list)
Environment:
Last Closed: 2011-05-19 13:05:26 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
patch to cause rhnplugin to respect metadata_expire (1.12 KB, patch)
2010-12-30 23:52 UTC, John Ruemker 		no flags Details | Diff
patch to add metadata_expire functionality to rhnplugin (fixed whitespace typo in previous patch) (1.13 KB, patch)
2010-12-31 00:06 UTC, John Ruemker 		no flags Details | Diff
Evidence Bug not fixed (161.26 KB, application/x-gzip)
2011-07-20 07:55 UTC, Francisco Lopez 		no flags Details
Show Obsolete (1) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 671360 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHBA-2011:0565 0 normal SHIPPED_LIVE rhn-client-tools and yum-rhn-plugin bug fix and ehnancement update 2011-05-18 17:57:10 UTC

Internal Links: 671360

Description John Ruemker 2010-12-30 23:52:11 UTC 
Description of problem:  The rhnplugin provided by yum-rhn-plugin does not respect yum's metadata_expire setting, and therefore all channels from RHN/RHNS use the default expiration time of 6 hours (21700 seconds).  

This came up in regards to an issue reported while the customer was using Satellite.  The customer pushed new packages to their Satellite base channel and taskomatic successfully regenerated the repodata for that channel.  They then scheduled a package upgrade from the satellite, which triggered the clients to run a yum update, but the metadata had not yet expired and thus the packages could not be installed without either

a) waiting 6 hours for the metadata to expire, OR
b) manually running 'yum clean all' on all of the clients

This is very inconvenient for the customer, considering they are looking to roll out satellite with several thousand clients.  

In response to the customer's report, I reproduced the issue and attempted to prevent it by lowering the metadata_expire setting so that the clients would not have to wait so long after a package push.  When this was unsuccessful, further debugging showed that repos made available through rhnplugin were still calling withinCacheAge with an expiration_time of 21700, while standard yum repos (for instance epel) were respecting my custom metadata_expire setting.  

I have implemented and tested a patch (attached) against yum-rhn-plugin which allows rhnplugin-based channels to use this setting.  I tested the setting in [main] of yum.conf, [main] of rhnplugin.conf, and individual channels in rhnplugin.conf.  All were successful at expiring the metadata of rhnplugin-based channels after the configured amount of time.

Version-Release number of selected component (if applicable): yum-rhn-plugin-0.9.1-7.el6.noarch.  

How reproducible: Whenever RHN/RHNS channel metadata is updated and a client has updated its metadata within the last 6 hours.

Steps to Reproduce:
1. Create a channel in Satellite
2. Register system to channel
3. 'yum clean all; yum makecache' on system
4. Push new or updated packages to channel
5. Within 6 hours from step 3, EITHER:
  a. yum check-update / yum install <package>
   OR
  b. Schedule an install/upgrade of one of the new packages for this system using the satellite UI

Actual results: If the action was carried out with yum (5a), observe that the packages are not available.  If the action was scheduled through satellite (5b), observe that it is reported as successful but the packages are not actually installed/updated.  

Expected results: Packages are installed or updated

Additional info: Problem also exists on RHEL5, and if no objections to implementing this functionality are presented, I will be filing another bug against it as well
Comment 1 John Ruemker 2010-12-30 23:52:41 UTC 
Created attachment 471226 [details]
patch to cause rhnplugin to respect metadata_expire
Comment 2 John Ruemker 2010-12-31 00:06:45 UTC 
Created attachment 471228 [details]
patch to add metadata_expire functionality to rhnplugin (fixed whitespace typo in previous patch)
Comment 3 Miroslav Suchý 2011-01-12 10:02:40 UTC 
cherrypicked to satellite.git as f4cc1ea5ff6d2778e8cb18b98206c57b9a749ced
Comment 5 Martin Minar 2011-02-25 15:39:37 UTC 
Verified with yum-rhn-plugin-0.9.1-17.el6.noarch
Comment 7 errata-xmlrpc 2011-05-19 13:05:26 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0565.html
Comment 8 Francisco Lopez 2011-07-20 07:54:31 UTC 
Bug has been reported from customer side as not fixed.

Please find evidence attached to this ticket. 

SF Ticketnumber: 00384548

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Comment 9 Francisco Lopez 2011-07-20 07:55:41 UTC 
Created attachment 513943 [details]
Evidence Bug not fixed
Comment 10 Martin Minar 2011-07-20 08:25:17 UTC 
(In reply to comment #8)
> Bug has been reported from customer side as not fixed.
> 
> Please find evidence attached to this ticket. 
> 
> SF Ticketnumber: 00384548
> 
> '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Can you clarify few things, please:

1. What is the metadata_expire setting in yum.conf: cat /etc/yum.conf
2. What is the version of rhn-plugin: rpm -q yum-rhn-plugin
3. I'm not sure about customer's process here. This bug solves this problem: User will add new packages into channel and then after time specified in metadata_expire when he does yum update/install he will get new packages.

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