Bug 239452 - up2date 4.5.5 not downloading packages as specified by activation key
Summary: up2date 4.5.5 not downloading packages as specified by activation key
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date
Version: 4.5
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Pradeep Kilambi
QA Contact: Corey Welton
URL:
Whiteboard:
Depends On:
Blocks: 239808
TreeView+ depends on / blocked
 
Reported: 2007-05-08 15:21 UTC by Byron Schlemmer
Modified: 2018-10-19 23:31 UTC (History)
8 users (show)

Fixed In Version: RHBA-2007-0367
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-05-18 13:43:09 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
patch for activation key based package install.. (2.10 KB, text/x-patch)
2007-05-11 15:42 UTC, Pradeep Kilambi
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0367 0 normal SHIPPED_LIVE up2date bug fix update 2007-12-12 17:54:47 UTC

Description Byron Schlemmer 2007-05-08 15:21:25 UTC
Description of problem:

up2date-4.5.5-5.el4.x86_64 does not download packages listed in the "Packages"
section in an activation keys configuration within Satellite 4.2.0.

By this I mean, de-registering a system, removing the /etc/rhn/systemid file and
running rhnreg_ks --activationkey=XXXXXXXXXXXXXXXXX, although registering the
system and subscribing to the correct config and software channels, it does not
download the specified packages in "Systems->Activation Keys->Key->Packages".

This also as a result impacts kickstarts, as any packages listed here are not
installed as the updated up2date program has already been installed.

Increasing the debug level to 5 in /etc/rhn/rhn.conf on the Satellite server did
show the following for up2date-4.5.5-5.el4.x86_64 even though the packages were
not installed :

2007/05/08 12:53:27 +01:00 6819 10.201.1.23: action/packages.update([['ntp', '',
'', ''], ['openssh', '', '', ''], ['openssh-
clients', '', '', ''], ['openssh-server', '', '', ''], ['rhncfg', '', '', ''],
['rhncfg-actions', '', '', ''], ['rhncfg-clien
t', '', '', ''], ['syslog-ng', '', '', '']],)

Downgrading to up2date-4.4.69-25.x86_64 fixes the problem and the applications
are downloaded.

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

up2date-4.5.5-5.el4.x86_64

How reproducible:

Very

Steps to Reproduce:
1. Install up2date-4.5.5-5.el4.x86_64
2. add a package no installed by default to the packages section in the
activation key menu
3.and attempt to register a system against Satellite.
  
Actual results:

System registers correctly, but doesn't download packages specified.

Expected results:

System to register and download any packages specified.

Additional info:

Comment 5 RHEL Program Management 2007-05-09 04:32:14 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 6 RHEL Program Management 2007-05-09 06:03:49 UTC
This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.

Comment 8 Pradeep Kilambi 2007-05-09 13:25:25 UTC
Hello:

This change was made as a result of resolving bz#158787.

up2date basically only grabs the name of the package rather than comparing nevra
and compares it to availableUpdates call which only grabs the latest, So we do
two things now, when doing up2date we allow it to behave the usual way. But when
dealing with scheduled actions, we compare the nvre and may be arch as well(not
yet) and check the queued list with the availablelist and select the ones
 that match the available and then pass it on to up2dates depSolver. In regular up
2dates case we by-pass the actions and do the usual behavior.

looks like the issue we are seeing with activation keys is due to
regression..I'll investigate further as to why this is happening. But the fix
for this issue should not be changing back the nvre compare to name, but for
activation key logic to bypass the actions code and use regular
self.__selectPackagesToInstall() call instead of selectActionPackagesToInstall.


Comment 9 Rene Zbinden 2007-05-10 07:54:20 UTC
What would be the easiest work around?

Comment 10 Pradeep Kilambi 2007-05-10 19:55:53 UTC
I did not get a chance to reproduce it yet, but I can explain why this is
happening. When including packages using activation key we only include the name
without vre and hence it compared the name with nvrea string on client and
thinks the packages does'nt exists. But the updates case the server sends in all
the nvre info.

The quick fix would be to add an if check to see if pkg[:] has just name or all
nvre info, if it is jus n compare name alone like before otherwise use
name-version-release-arch info so it wont effect other issue we fixed in bz#158787. 

so something like:
In /usr/share/rhn/up2date_client/up2dateBatch.py

Index: up2dateBatch.py
===================================================================
--- up2dateBatch.py     (revision 114702)
+++ up2dateBatch.py     (working copy)
@@ -245,8 +245,14 @@
         # should probably iterate over remotePackageNames once
         # using a counter, and use that to index into remotePackages
         for pkg in actionPkgs:
-           # compare nvre instead of just names. 
-            for tmppkg in filter(lambda a,b=pkg: a[:4]==b[:4], remotePackages):
+            if ''.join(pkg) == pkg[0]:
+                # In this case, server sent just name info
+                pkg_list = filter(lambda a,b=pkg: a[0]==b[0], remotePackages)
+            else:
+                # compare all fields, as server gave us the info
+                pkg_list = filter(lambda a,b=pkg: a[:4]==b[:4], remotePackages)
+           
+            for tmppkg in pkg_list:
                 updList.append(tmppkg[0])
                 self.actionPkgListInfo.append(tmppkg)
 
This should suffice the case of package updates and activation key installs as
well. 

This patch is still *untested* as I *haven't* got a chance to reproduce the
issue yet. PLease do not use it on your main boxes. Feel free to test it on your
test machines.
But in mean time this probably is a good start to test it out, this might be a
possible work around. 

I'll let you know once i reproduce the issue...



Comment 13 Pradeep Kilambi 2007-05-11 14:58:18 UTC
k I tracked this down a little more.. 

[root@rlx-2-22 up2date_client]# rhnreg_ks --username=xixixi --password=test1
--serverUrl=http://rlx-1-20.rhndev.redhat.com/XMLRPC
--noSSLServerURL=http://rlx-1-20.rhndev.redhat.com/XMLRPC --force
--activationkey=testkey239452

Name                                    Version        Rel
----------------------------------------------------------
acroread                                7.0.9          1.2.0.EL4         i386
acroread                                7.0.1          1.2.0.EL4         i386
acroread                                7.0.0          4.2.0.EL4         i386
acroread                                5.10           0.EL4             i386

when it shows that whats happening is its adding all available versions of to
the transaction set and tries to install em and results in conflicts.. from
/var/log/up2date this is what i see:

file /usr/lib/acroread/Reader/intellinux/lib/libCoolType.so conflicts between at
tempted installs of acroread-5.10-0.EL4 and acroread-7.0.1-1.2.0.EL4
file /usr/lib/acroread/Reader/intellinux/plug_ins/AcroForm.api conflicts between
 attempted installs of acroread-5.10-0.EL4 and acroread-7.0.1-1.2.0.EL4
file /usr/lib/acroread/Reader/intellinux/plug_ins/EScript.api conflicts between 
attempted installs of acroread-5.10-0.EL4 and acroread-7.0.1-1.2.0.EL4
file /usr/lib/acroread/Reader/intellinux/plug_ins/ewh.api conflicts between atte
mpted installs of acroread-5.10-0.EL4 and acroread-7.0.1-1.2.0.EL4
file /usr/lib/acroread/Reader/intellinux/plug_ins/wwwlink.api conflicts between 
attempted installs of acroread-5.10-0.EL4 and acroread-7.0.1-1.2.0.EL4
file /usr/lib/acroread/Reader/intellinux/res conflicts between attempted install
s of acroread-5.10-0.EL4 and acroread-7.0.1-1.2.0.EL4

This explains the reason why it does'nt install.. i'm putting together a fix for
this, will test it and will update you guys...


Comment 14 Pradeep Kilambi 2007-05-11 15:42:08 UTC
Created attachment 154551 [details]
patch for activation key based package install..

k I have a working patch that fixes the issue, this still needs clean up here
is the patch. see attached.

Comment 15 Pradeep Kilambi 2007-05-11 15:46:16 UTC
Xixi : 

attached is the patch in comment#14 that should fix the issue. I remodifed your
modified patch in comment#11.

after applying the patch on my test system against your sat:

[root@rlx-2-22 up2date_client]# rhnreg_ks --username=xixixi --password=test1
--serverUrl=http://rlx-1-20.rhndev.redhat.com/XMLRPC
--noSSLServerURL=http://rlx-1-20.rhndev.redhat.com/XMLRPC --force
--activationkey=testkey239452

%%%%%%%%%%%%%%%%% [['acroread', '7.0.9', '1.2.0.EL4', '', 'i386', '38652569',
'clone-2-rhel-i386-as-4-extras']]

Name                                    Version        Rel     
----------------------------------------------------------
acroread                                7.0.9          1.2.0.EL4         i386  

acroread-7.0.9-1.2.0.EL4.i3 ############################# Done.                   
Preparing              ########################################### [100%]

Installing...
   1:acroread               ########################################### [100%]
[root@rlx-2-22 up2date_client]#

I will do little more testing and clean the patch up with some error checking.
But this i think should fix the issue we have now.

let me know.

thanks,
Prad


Comment 17 RHEL Program Management 2007-05-14 18:26:15 UTC
This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being marked as a blocker for this release.  

Please resolve ASAP.

Comment 23 Red Hat Bugzilla 2007-05-18 13:43:10 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 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-0367.html



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