Bug 1247773 - CentOS 7 servers can't be installed due to conflicting rhnlib and rhn-setup package versions.
CentOS 7 servers can't be installed due to conflicting rhnlib and rhn-setup p...
Status: NEW
Product: Spacewalk
Classification: Community
Component: Clients (Show other bugs)
2.3
Unspecified Linux
unspecified Severity high
: ---
: ---
Assigned To: Tomáš Kašpárek
Red Hat Satellite QA List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-07-28 16:30 EDT by Andy Speagle
Modified: 2015-11-11 15:13 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
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 Andy Speagle 2015-07-28 16:30:57 EDT
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 15:13:31 EST
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

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