Bug 122635

Summary: XMLRPC protocol incompatibility between RHEL3 client and Satellite
Product: Red Hat Satellite 5 Reporter: Aleksandr Brezhnev <brezhnev>
Component: Configuration ManagementAssignee: Bret McMillan <bretm>
Status: CLOSED CURRENTRELEASE QA Contact: Paul Dorsey <pdorsey>
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: rhn-bugs, tao
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-06-18 16:32:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 119090    

Description Aleksandr Brezhnev 2004-05-06 15:08:33 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)
Gecko/20040301

Description of problem:
Looks like libxml2-python library on RHEL3 can't provide transparent
transfers of non-text data and substitutes strings like "%fa" with
byte code 0xfa during communications with RHN Satellite 3.2.0.

This problem directly affects rhncfg-client because it fails to deploy
files with non-text data and corrupts files containing strings like
"%fa". 

I created a short text file (size 126 bytes) /tmp/f126 and put it into
config channel.
12345678901234567890
12345678901234567890
12345678901234567890
12345678901234567890
12345678901234567890
12345678901234567890

RHEL 3 client was able to deploy it:

# rhncfg-client get /tmp/f126
Deploying /tmp/f126

Then I added one byte with null code into beginning of this file:
dd if=/dev/zero of=zz bs=1 count=1
cat zz /tmp/f126 > /tmp/z127

I put this file into config channel and switched its type to binary.
File /tmp/z127 looks like (od -c /tmp/z127):
0000000  \0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
0000020   6   7   8   9   0  \n   1   2   3   4   5   6   7   8   9   0
0000040   1   2   3   4   5   6   7   8   9   0  \n   1   2   3   4   5
0000060   6   7   8   9   0   1   2   3   4   5   6   7   8   9   0  \n
0000100   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5   6
0000120   7   8   9   0  \n   1   2   3   4   5   6   7   8   9   0   1
0000140   2   3   4   5   6   7   8   9   0  \n   1   2   3   4   5   6
0000160   7   8   9   0   1   2   3   4   5   6   7   8   9   0  \n
0000177

RHEL3 client failed to deploy it:

# rhncfg-client get /tmp/z127
XML-RPC error while talking to
https://rhnsat.fmrco.com/CONFIG-MANAGEMENT: not well-formed (invalid
token): line 16, column 15

Version-Release number of selected component (if applicable):
libxml2-python-2.5.10-6 rhncfg-client-3.1.5-3

How reproducible:
Always

Steps to Reproduce:
1. Create a short text file (size 126 bytes) /tmp/f126:
12345678901234567890
12345678901234567890
12345678901234567890
12345678901234567890
12345678901234567890
12345678901234567890

2. Add one byte with null code to the beginning of this file:
dd if=/dev/zero of=zz bs=1 count=1
cat zz /tmp/f126 > /tmp/z127

3. Upload /tmp/z127 into config channel on RHN Sat.
Switch its type to binary (but text type gives the dame effect).

File /tmp/z127 looks like (od -c /tmp/z127):
0000000  \0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
0000020   6   7   8   9   0  \n   1   2   3   4   5   6   7   8   9   0
0000040   1   2   3   4   5   6   7   8   9   0  \n   1   2   3   4   5
0000060   6   7   8   9   0   1   2   3   4   5   6   7   8   9   0  \n
0000100   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5   6
0000120   7   8   9   0  \n   1   2   3   4   5   6   7   8   9   0   1
0000140   2   3   4   5   6   7   8   9   0  \n   1   2   3   4   5   6
0000160   7   8   9   0   1   2   3   4   5   6   7   8   9   0  \n
0000177

4. Try to deploy /tmp/z127 file to RHEL3 client using rhncfg-client


Actual Results:  # rhncfg-client get /tmp/z127
XML-RPC error while talking to
https://rhnsat.fmrco.com/CONFIG-MANAGEMENT: not well-formed (invalid
token): line 16, column 15

Expected Results:  File should be deployed in /tmp directory.

Additional info:

No log records on Satellite in /var/log/rhn/rhn_server_xmlrpc.log,
/var/log/rhn/rhn_server_app.log and /var/log/httpd/error_log.

/var/log/httpd/access_log has following:

172.17.237.29 - - [06/May/2004:11:13:22 -0400] "POST
/CONFIG-MANAGEMENT HTTP/1.1" 200 379
172.17.237.29 - - [06/May/2004:11:13:22 -0400] "POST
/CONFIG-MANAGEMENT HTTP/1.1" 200 265

The same experiment with rhncfg-client on RHEL 2.1 works well.
Comment 1 Aleksandr Brezhnev 2004-05-06 15:09:57 UTC 
Another discovery.
I created a text file /tmp/hex-test with substring "%fa":

1234567890%fa1234567890

and uploaded this file into Satellite.
Satellite shows this file properly.
RHEL3 client can deploy it but substitutes substring "%fa" with one
byte with code 0xfa:

# od -t x1 /tmp/hex-test
0000000 31 32 33 34 35 36 37 38 39 30 fa 31 32 33 34 35
0000020 36 37 38 39 30 0a
0000026
Comment 2 Bret McMillan 2004-05-06 15:22:51 UTC 
Bumping priority, adding as a blocker for rhn340hosted.  Need to
determine if responsability lies w/ libxml2/libxml2-python or if it's
somewhere in the RHN stack.
Comment 3 Aleksandr Brezhnev 2004-05-06 15:24:16 UTC 
Related problem is described in IT#38514:

We have an activation key with a list of packages to install:
python-optik
rhncfg
rhncfg-actions
rhncfg-client
rhncfg-management
rhns-config-libs

When we are trying to register RHEL3 client with Satellite using

rhnreg_ks --force --activationkey ACTIVATION_KEY

the package deployment action fails with error code 30 returned to
Satellite. In fact, all rpms are installed but Satellite gets error
code 0x30 which would be 0 if libxml2-python had transfered this hex
code correctly.
Comment 4 Bret McMillan 2004-05-06 15:25:34 UTC 
PS -- thank you for the excellently detailed bug report!
Comment 5 Aleksandr Brezhnev 2004-05-06 19:02:54 UTC 
rhncfg-client on RHEL 2.1 corrupts files containing %xx strings the
same way as it does so on RHEL 3. 

For example, 

rhncfg-client get /etc/ftpaccess

deploys file but converts "%65534" to "e534".
Comment 6 Mihai Ibanescu 2004-05-20 21:15:19 UTC 
Bret is working on it.
Comment 7 Bret McMillan 2004-05-25 02:35:08 UTC 
Ok, nest of bugs uncovered and hopefully squashed.  This needs to be
fully tested.

The new client rpms (rhncfg-*3.1.6-6-*) need to be tested on both
RHEL3 and RHEL2.1.  Specifically, need to run through the scheduled
action, rhncfg-client, and rhncfg-manager tests.

They need to be pointed at *both* a 3.2 satellite to ensure they work
as much as the old ones did when pointed at old app code, and they
need to be pointed at a new rhn340 satellite and new rhn340 hosted env
(aka, webdev).  The new server side packages should be confirmed to be
>= 3.4.0-7

Be sure to include /etc/mail/sendmail.cf, a text file of your choice,
and a binary file of your choice in the import and deploy tests.
Comment 8 Bret McMillan 2004-05-25 02:37:52 UTC 
Oh, and we also need to test the clients in prod against the new
server side code to make sure they work together as much as the
clients in prod did w/ the rhn320 code.

So, rhncfg*-3.1.5-3-* against the rhns >= 3.4.0-7 backend packages.
Comment 9 Bret McMillan 2004-06-01 14:11:01 UTC 
when testing in qa, be sure to test w/ rhncfg*3.1.6-7
Comment 10 Paul Dorsey 2004-06-09 16:46:24 UTC 
All steps verified
rhncfg-client
rhncfg-manager
Paul

Note test plans for all rhncfg functions should be writen and automated
Comment 11 Robert Perkins 2005-06-30 18:51:01 UTC 
When will this be released?