Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1247773

Summary: CentOS 7 servers can't be installed due to conflicting rhnlib and rhn-setup package versions.
Product: [Community] Spacewalk Reporter: Andy Speagle <andy.speagle>
Component: ClientsAssignee: Michael Mráka <mmraka>
Status: CLOSED EOL QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: 2.3CC: whtenben
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-07-12 12:10:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andy Speagle 2015-07-28 20:30:57 UTC 
Description of problem:

The rhnlib package in the Spacewalk 2.3 client repo is sufficiently new that it can't work with the rhnreg_ks utility that is packaged in the default rhn-setup package from the CentOS 7 repo.  In order to make it work, one has to add a post-install script that fires before the "Registration and server actions" built-in post-install script.  The issue is that the new rhnlib implements "idn_ascii_to_puny" in connections.py while the old rhnreg_ks is looking for "idn_ascii_to_pune" via its dependencies.

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


How reproducible:
This is a general issue that has to be worked around.

Steps to Reproduce:
1.  
2.
3.

Actual results:
Registration does due to script dependency issues.

Expected results:
Registration succeeds.

Additional info:
I wrote a post-install script that grabs the necessary files... but, I don't know that it's a permanent solution because I think the links to the required files will eventually expire:

mkdir -p /tmp/rhn_rpms/optional
cd /tmp/rhn_rpms/optional 
wget -P /tmp/rhn_rpms/optional http://spacewalk.wichita.edu/download/package/fcb44ada56d57e6fc033f7e19262952b4acee26f/1438140090557/1/194028/rhn-client-tools-2.3.16-1.el7.noarch.rpm http://spacewalk.wichita.edu/download/package/858a8a53048464399ab3b3468d8e4591be728aab/1438140073338/1/194025/rhn-setup-2.3.16-1.el7.noarch.rpm http://spacewalk.wichita.edu/download/package/dced25a61ed01c6df170f7c74e4302ffa4445f9f/1438140105463/1/194019/rhn-check-2.3.16-1.el7.noarch.rpm

rpm -Uvh --replacepkgs --replacefiles /tmp/rhn_rpms/optional/rhn*
Comment 1 whtenben 2015-11-11 20:13:31 UTC 
If I am reading the bug correct, this is how our company is bypassing this issue:

We sync the Spacewalk client to a channel, then under the kickstart we expose this channel via the UI -> kickstart Details -> Operating systems -> spacewalk 2.3 child channel. 

Then in the list of packages to install:
%packages
@ Base

#below pkg needed for rhn registration
subscription-manager
rhn-check
rhnsd
rhn-setup
rhn-client-tools
yum-rhn-plugin
libidn
rhncfg
rhncfg-client
rhncfg-actions
libxml2
pyOpenSSL
libxml2-phython
rhnlib
perl


The only issue that we have ran into is where the activation key channel has newer version of rhnlib for any OS version.  This is being tracked in bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1280167
Comment 2 Michael Mráka 2019-07-12 12:10:21 UTC 
Spacewalk 2.8 (and older) has already reached it's End Of Life.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before end of life. If you would still like
to see this bug fixed and are able to reproduce it against current version
of Spacewalk 2.9, you are encouraged change the 'version' and re-open it.