Bug 210625 - 3rd party channels will not update when specified with the --channel option
3rd party channels will not update when specified with the --channel option
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: up2date (Show other bugs)
3.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Pradeep Kilambi
Brandon Perkins
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-13 09:01 EDT by Matt Ford
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version: RHBA-2007-0815
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-15 11:33:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Ford 2006-10-13 09:01:06 EDT
Description of problem:

After upgrading to the latest version of up2date via the RHN network, 3rd party
repositories, when specified via the --channel option no longer update due to a
bug in channel association logic.

Version-Release number of selected component (if applicable):

Name        : up2date                      Relocations: (not relocatable)
Version     : 4.4.69                            Vendor: Red Hat, Inc.
Release     : 24.2                          Build Date: Fri Aug 25 15:39:46 2006


How reproducible:

Run 

up2date-nox --channel eugridpma ca_policy_eugridpma-classic

where the channel is not part of RHN.
  
Actual results:

 up2date This system may not be updated until it is associated with a channel.
[Fri Oct 13 12:25:23 2006] up2date   File "/usr/sbin/up2date-nox", line 1290, in ?
    sys.exit(main() or 0)
   File "/usr/sbin/up2date-nox", line 601, in main
    rhnChannel.setChannels(tempchannels)
   File "/usr/share/rhn/up2date_client/rhnChannel.py", line 291, in setChannels
    return getChannels(label_whitelist=whitelist)
   File "/usr/share/rhn/up2date_client/rhnChannel.py", line 189, in getChannels
    raise up2dateErrors.NoChannelsError(_("This system may not be updated until
it is associated with a channel."))

Additional info:

This looks to be a bug introduced in the re-factoring of up2date python code.  I
fixed locally by modifying the file like so:

/usr/share/rhn/up2date_client/rhnChannel.py

def getChannels(force=None, label_whitelist=None):
    cfg = config.initUp2dateConfig()
    log = up2dateLog.initLog()
    global selected_channels
    ## Patch ##
    selected_channels=label_whitelist
    ## End of Patch ##

Without the patch the getChannels function ignores info sent to it by the new
setChannel function.
Comment 1 Pradeep Kilambi 2006-10-30 09:37:40 EST
What did you mean by 3rd party channels? (This is little confusing to me). What
happens if i give a regular red hat channel? looks like it follows the same code
path, then why is it specific to 3rd party channels?

Can you tell me if this happens in any other cases

Need more info...
Comment 2 Matt Ford 2006-10-31 08:39:09 EST
To replicate add a repo to up2date not part of the normal distribution and try
to do the update.

The getChannels function has the command in it

selected_channels = rhnChannelList()

so this is why the only 3rd parties are affected.  Without the patch line
,including lavel_whitelist, above the function has no way of importing the
options passed by --channel.

Comment 3 Pradeep Kilambi 2006-10-31 09:52:10 EST
ah I see what you mean. So you mean 3rd party channels as custom channels(non
redhat owned).

k added the fix to take care of this issue, 

Before Fix:

[rlx-2-24 ~]# up2date-nox --channel=test-push ElectricFence
An error has occurred:
This system may not be updated until it is associated with a channel.
See /var/log/up2date for more information
[rlx-2-24 ~]#

After Fix:

[rlx-2-24 ~]# up2date-nox --channel=test-push ElectricFence

Fetching Obsoletes list for channel: rhel-i386-as-4...

Fetching Obsoletes list for channel: redhat-rhn-satellite-4.1-as-i386-4...

Fetching rpm headers...
########################################

Name                                    Version        Rel     
----------------------------------------------------------
ElectricFence                           2.2.2          19                i386  


Testing package set / solving RPM inter-dependencies...
########################################
ElectricFence-2.2.2-19.i386 ########################## Done.                   
Preparing              ########################################### [100%]

Installing...
   1:ElectricFence          ########################################### [100%]


To test this create a custom channel on the serevr with a bunch of packages and
try to run up2date, this should not fail as in case 1.
Comment 4 Pradeep Kilambi 2006-10-31 10:34:00 EST
I added the fix under trunk. If this needs to go into any earlier releases, let
me know so that I can move the fix to relevant branches.
Comment 5 Red Hat Bugzilla 2007-04-11 21:25:39 EDT
User bnackash@redhat.com's account has been closed
Comment 6 Pradeep Kilambi 2007-07-05 13:54:51 EDT
the fix was checkin but never got qa'ed.. aligning to 4.6 for testing.
Comment 10 Pradeep Kilambi 2007-07-27 19:33:46 EDT
actually after little more testing looks like this is not what was causing the
problem.

 up2date-nox --channel=test-push ElectricFence
An error has occurred:
This system may not be updated until it is associated with a channel.
See /var/log/up2date for more information

is the right error and is exactly saying what it means..the 3rd party channel
exists on the satellite agreed but its is not subscribed to your system. So it
cannot get packages from an unsubscribed channel. 

What you need to do is goto the webui and subscribe your system to 'eugridpma'
channel as per your test:
up2date-nox --channel eugridpma ca_policy_eugridpma-classic

up2date is doing exactly what its expected to do..

test plan:

- please test this bug to make sure you can install package subscribed to a
custom channel.
Comment 14 errata-xmlrpc 2007-11-15 11:33:58 EST
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 the 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-2007-0815.html

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