Bug 666534 - [RHEL 5] rhnplugin does not respect metadata_expire setting
Summary: [RHEL 5] rhnplugin does not respect metadata_expire setting
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum-rhn-plugin
Version: 5.5
Hardware: All
OS: Linux
urgent
high
Target Milestone: rc
: ---
Assignee: Miroslav Suchý
QA Contact: Martin Minar
URL:
Whiteboard:
: 647152 (view as bug list)
Depends On: 666463 666876
Blocks: 681137
TreeView+ depends on / blocked
 
Reported: 2010-12-31 14:25 UTC by John Ruemker
Modified: 2018-11-14 17:34 UTC (History)
13 users (show)

Fixed In Version: yum-rhn-plugin-0.5.4-18.el5
Doc Type: Bug Fix
Doc Text:
Due to rhnplugin not considering the value of Yum's "metadata_expire" variable, all channels used default expiration time (21,700 seconds). This prevented a user from updating a system using RHN Satellite. rhnplugin now respects Yum's global settings.
Clone Of: 666463
Environment:
Last Closed: 2011-07-21 07:10:56 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
patch to add metadata_expire functionality to rhnplugin (1.19 KB, patch)
2010-12-31 14:30 UTC, John Ruemker
no flags Details | Diff


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:0998 0 normal SHIPPED_LIVE yum-rhn-plugin bug fix update 2011-07-20 15:44:51 UTC

Internal Links: 671360

Description John Ruemker 2010-12-31 14:25:16 UTC
+++ This bug was initially created as a clone of Bug #666463 +++

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

--- Additional comment from jruemker on 2010-12-30 18:52:41 EST ---

Created attachment 471226 [details]
patch to cause rhnplugin to respect metadata_expire

--- Additional comment from jruemker on 2010-12-30 19:06:45 EST ---

Created attachment 471228 [details]
patch to add metadata_expire functionality to rhnplugin (fixed whitespace typo in previous patch)

Comment 1 John Ruemker 2010-12-31 14:30:56 UTC
Created attachment 471282 [details]
patch to add metadata_expire functionality to rhnplugin

Comment 4 Martin Osvald 🛹 2011-01-18 07:07:24 UTC
*** Bug 647152 has been marked as a duplicate of this bug. ***

Comment 10 Miroslav Suchý 2011-03-01 07:28:25 UTC
cherry picked from https://bugzilla.redhat.com/show_bug.cgi?id=666463#c3 to svn as rev. 201156

Comment 15 Eliska Slobodova 2011-06-15 12:35:05 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Due to rhnplugin not considering the value of Yum's "metadata_expire" variable, all channels used default expiration time (21,700 seconds). This prevented a user from updating a system using RHN Satellite. rhnplugin now respects Yum's global settings.

Comment 16 errata-xmlrpc 2011-07-21 07:10:56 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-0998.html


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