Description of problem: configchannel.createOrUpdatePath() strips the return line '\n' character from the end of the file. Version-Release number of selected component (if applicable): Red Hat Satellite 5.7 How reproducible: 100% Steps to Reproduce: --- API script ↪ cat upload_configfile.py #!/usr/bin/python import xmlrpclib import os import base64 SATELLITE_URL = "http://orbital.usersys.redhat.com/rpc/api" SATELLITE_LOGIN = "admin" SATELLITE_PASSWORD = "redhat" client = xmlrpclib.Server(SATELLITE_URL, verbose=0) token = client.auth.login(SATELLITE_LOGIN, SATELLITE_PASSWORD) cf_channel = raw_input("Config Channel: ") cfg_path = raw_input("Config File: ") try: if os.path.isfile(cfg_path): with open(cfg_path, 'r') as fd: isDir = False #enc_cfg = base64.b64decode(fd.read()) enc_cfg = fd.read() ct = {} ct['contents'] = enc_cfg #ct['contents_enc64'] = True ct['contents_enc64'] = False ct['owner'] = 'root' ct['group'] = 'root' ct['permissions'] = '644' ct['macro-start-delimiter'] = '{|' ct['macro-end-delimiter'] = '|}' ct['binary'] = False ret = client.configchannel.createOrUpdatePath(token, cf_channel, cfg_path, isDir, ct) except: raise client.auth.logout(token) So to test it, the file we want to has this content (with the return line) # cat /etc/test-file-API this is a file # Then uploading it via the and deploying to the client we got the issue reproduced: ↪ ./upload_configfile.py Config Channel: test-configs Config File: /etc/test-file-API --- on the client [root@localhost ~]# rm -f /etc/test-file-API ; rhncfg-client get /etc/test-file-API ; cat /etc/test-file-API Using server name orbital.usersys.redhat.com Deploying /etc/test-file-API this is a file[root@localhost ~] Note: if we edit the file via webUI and add manually the return line, the file is deployed as expected. Actual results: \n is being stripped on Serializer when file is upload Expected results: respect what the contents of the file Additional info:
Attaching a debugger to ConfigChannelHandler.createOrUpdatePath(), and re-running the reproducer, shows me that data['contents'] has already had its trailing newlines stripped. Backing up the stack a ways, XmlRpcServlet.service() request.request.coyoteRequest.inputBuffer.bodyBuff, shows the newlines are *still there*. So - the newlines get to the backend correctly, and whatever is removing them happens well before the specific handler gets called. Investigation continues.
See the XMLRPC spec : https://www.w3.org/2008/xmlsec/Drafts/xml-norm/Overview.html Search on "TrimTextNodes" : === TrimTextNodes of type boolean, defaulting to true Whether to trim (i.e. remove leading and trailing whitespace) all text nodes while normalizing. Adjacent text nodes must be coalesced prior to trimming. If an element has an xml:space="preserve" attribute, then text node descendants of that element are not trimmed regardless the value of this parameter. === I expect we're seeing the default behavior of XMLRPC here.
*** Bug 1441590 has been marked as a duplicate of this bug. ***
As noted in #c5 this is redstone-xmlrpc doing its job. If whitespace is *really important*, you need to deal with the file as binary instead of text, to keep redstone's grubby paws off of it.