Red Hat Bugzilla – Bug 817370
spacecmd configchannel_import problems text files without trailing newlines
Last modified: 2017-09-28 13:56:58 EDT
Description of problem:
When using spacecmd configchannel_import, if a file in the json did not have a trailing newline it will be imported as some sort of binary garbage.
Version-Release number of selected component (if applicable):
Export a config channel that has text files without trailing newlines, import the json into a fresh spacewalk install. The file will be trashed when viewed in the spacewalk ui.
Steps to Reproduce:
1. spacecmd configchannel_export
2. spacecmd configchannel_import
3. view the imported files in the ui
File is filled with binary garbage
File is the same as it was when exported
Thanks for the report - can you please upload an example config file (as an attachment to the bz) which triggers this behaviour?
Note that there are some limitations in the API export of config-channel files - it's not just trailing newlines which require base64 encoding, any file containing characters not-valid in via the XMLRPC API must be exported (and therefore imported) as base64 encoded.
An example of such a character is the ASCII escape character, which is pretty common in config-files (e.g /etc/vimrc). This means these files must be export/imported into satellite base64 encoded, which is not ideal but it's a limitation of the API I had to work around.
Can you confirm (the spacewalk web-UI issue aside), does the file get correctly rendered when deployed to a system?
If you can provide further details of your specific issue, then I'll look into possible fixes/workarounds.
Ok, so I can't reproduce this on recent spacewalk-nightly:
# Create test config-channel, add a couple of files (both actually got uploaded as base64 encoded due to trailing newlines in fstab
spacecmd -- configchannel_create -n foobar -d foobar
spacecmd -- configchannel_addfile -c foobar -p /tmp/vimrc1 -f /etc/vimrc -b
spacecmd -- configchannel_addfile -c foobar -p /tmp/fstab -f /etc/fstab
# Check in web UI - both files are viewable/editable as text in the "file contents" box
# Export/delete/import via spacecmd
spacecmd --debug -- configchannel_export foobar
spacecmd configchannel_delete foobar
spacecmd configchannel_import foobar.json
# Check in web UI - both files are still viewable/editable as text in the "file contents" box
Please re-test on spacewalk-nightly, if you can still reproduce the problem please provide a detailed reproduce procedure
Ok, no additional information forthcoming, so I'm closing WORKSFORME.
Please reopen if you have more details and a reproduce procedure demonstrating the problem on latest spacewalk.
I'm still getting the file corruption when I updated to spacecmd-1.8.7-1.el6.noarch.rpm
The bug is triggered if the file is uploaded in plaintext mode, and the file doesn't contain any trailing newline.
I followed your steps above with the attached ssh_host_rsa_key.pub
Thanks for checking into this.
Created attachment 586675 [details]
This file will trigger the problem - make sure it has no newline at the end
spacecmd -- configchannel_addfile -c tml-config -p /tmp/rsa -f /tmp/attachment_586675
with both spacecmd-1.7.7-1.el5 and spacecmd-1.8.9-1.el5
and in both cases a correct file content was uploaded. The same works also with -b option.
Please, provide a reproducer that leads to a faulty behavior.
My testing also indicates this is not a spacecmd bug - as per comment #2 I suspect an issue with the reporters spacewalk installation
As per comments above, closing NOTABUG
This BZ closed some time during 2.5, 2.6 or 2.7. Adding to 2.7 tracking bug.