Bug 1133652 - "rhncfg-client get " can deploy empty files instead of the expected configuration
Summary: "rhncfg-client get " can deploy empty files instead of the expected configura...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Clients
Version: 2.2
Hardware: All
OS: All
high
high
Target Milestone: ---
Assignee: Stephen Herr
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On: 1119816 1139412
Blocks: space23
TreeView+ depends on / blocked
 
Reported: 2014-08-25 17:39 UTC by Stephen Herr
Modified: 2015-04-14 19:02 UTC (History)
7 users (show)

Fixed In Version: rhncfg-5.10.77-1
Doc Type: Bug Fix
Doc Text:
Clone Of: 1119816
Environment:
Last Closed: 2015-04-14 19:02:34 UTC
Embargoed:


Attachments (Terms of Use)

Description Stephen Herr 2014-08-25 17:39:45 UTC
+++ This bug was initially created as a clone of Bug #1119816 +++

Description of problem:
rhncfg-client get irregularly deploys empty files instead of the expected configuration files on systems

Version-Release number of selected component (if applicable):
5.10.55-6.el6

How reproducible:
rarely, no control on how frequently this happens

Steps to Reproduce:
1.rhncfg-client get 

Actual results:
config files are deployed, but all the files have no content.

Expected results:
config files are correctly deployed or if an error in getting the content of the files is met, empty files are not created

Additional info:
no error messages were collected due to the method used to call this (customer calls the script every 5 minutes on all the production machines he has, which executes in less than a second)

--- Additional comment from Stephen Herr on 2014-08-21 16:57:23 EDT ---

I have reviewed the code. I cannot find a code path that would allow for the creation of an empty file, nor can I recreate the issue.

However, currently we don't do any checking on the client side that the checksum of the recieved file contents are correct. It's /possible/ that this is happening because the customer's network is dropping out and the client is receiving a corrupt response of file info back from Satellite. If so, then comparing checksums on the file content before proceeding with the deployment should solve the issue.

Comment 1 Stephen Herr 2014-08-25 17:42:15 UTC
This is just a shot in the dark since I can't reproduce the actual problem, but I don't think that validating the contents of a config file before deploying it is a bad thing.

Committing to Spacewalk master:
15be917dbac6f233bb8e6a48af6f70346d3d2ae7

Comment 2 Stephen Herr 2014-09-11 19:55:31 UTC
An additional commit fixes:
1) file metadata may contain 'md5sum' instead of 'checksum' and 'checksum_type' on old Spacewalk servers
2) file metadata must contain one or the other, so checksum validation should not be optional
3) we should also support sha256 checksums, not just md5 or sha1
4) sha256 should be the checksum used when verifying files

Committing to Spacewalk master:
a80c26cd0642084cd7cd48d6b3c4a9bc88809905

Comment 3 Grant Gainey 2015-03-23 16:58:40 UTC
Moving bugs to ON_QA as we move to release Spacewalk 2.3

Comment 4 Grant Gainey 2015-04-14 19:02:34 UTC
Spacewalk 2.3 has been released. See

https://fedorahosted.org/spacewalk/wiki/ReleaseNotes23


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