Bug 593563
| Summary: | Traceback on rhn_check: <type 'exceptions.KeyError'>: 'md5sum' | ||
|---|---|---|---|
| Product: | [Community] Spacewalk | Reporter: | Sandro Mathys <sandro> |
| Component: | Clients | Assignee: | Michael Mráka <mmraka> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Red Hat Satellite QA List <satqe-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 1.0 | CC: | mmraka |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-11-19 16:16:19 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: | 623772 | ||
Would be nice to have this fixed before Fedora 13 is released (next Tuesday), by the way. There was a debug routine which hasn't reflect md5sum to checksum changes yet.
Fixed in
commit 08436e76d1ad0d655f7d5dc5077a25c3d95f5ed6
Automatic commit of package [rhncfg] release [5.9.22-1].
commit 0add7db89d13269547a8e9c0b9247bcc4ec3472f
593563 - fixed debug rutines according to checksum changes
Will be fixed in rhncfg-5.9.22-1
Will that make it into 1.0-client? Would be great if you could push it. Hi Sandro, there were some other changes made to rhncfg package from the time of Spacewalk-1.0 branched and we don't plan to backport this one-of change at the moment. On the other way AFAIK changes in the package are self-contained to it could be possible to use the new package within other Spacewalk 1.0 client packages. Eg. download it manually into your local client repo copy and let clients update it. Regards, Michael Can confirm that rhncfg-5.9.22-1 fixes this issue. Seems to work fine on Fedora 13. Verified - as per comment #5. Mass-aligning under space12, so that we don't lose track of this bugzilla. This however does not mean that we plan (will be able to) address this bug in Spacewalk 1.2. With Spacewalk 1.2 released, marking as CLOSED CURRENTRELEASE. https://www.redhat.com/archives/spacewalk-list/2010-November/msg00111.html |
Description of problem: I get the following in /var/log/up2date of the client when deploying config files: [Wed May 19 09:01:42 2010] up2date updateLoginInfo() login info [Wed May 19 09:01:42 2010] up2date logging into up2date server [Wed May 19 09:01:42 2010] up2date successfully retrieved authentication token from up2date server [Wed May 19 09:01:42 2010] up2date Traceback (most recent call last): File "/usr/sbin/rhn_check", line 283, in __run_action (status, message, data) = CheckCli.__do_call(method, params) File "/usr/sbin/rhn_check", line 276, in __do_call retval = method(*params) File "/usr/share/rhn/actions/configfiles.py", line 296, in deploy log_to_file(0, "Files successfully deployed: %s %s" % (format_file_string(files, create_key_list()), str(extras))) File "/usr/share/rhn/actions/configfiles.py", line 346, in format_file_string outstr = outstr + formatstr % (key, afile[key]) <type 'exceptions.KeyError'>: 'md5sum' In the webUI this results once more in: Client execution returned "Fatal error in Python code occured [[6]]" (code -1) Version-Release number of selected component (if applicable): rhn-check-1.0.6-1.fc12.noarch (on Fedora 13 client!) How reproducible: Always. Steps to Reproduce: 1. Deploy (single?) config file from webUI 2. Wait for rhnsd/osad/do rhn_check 3. Watch /var/log/up2date and the schedule in the webUI Actual results: Failed in webUI -> traceback on client, file IS deployed Expected results: Success in webUI -> no traceback, file is deployed Additional info: Every 24h there's an automatically executed "Show differences between profiled config files and deployed config files scheduled by (none)" task which also fails the same way. Package installation and remote commands are not seeing the problem.