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:
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.
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.
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.
What would be the easiest work around?
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...
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...
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.
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
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.
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