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 []" (code -1)
Version-Release number of selected component (if applicable):
rhn-check-1.0.6-1.fc12.noarch (on Fedora 13 client!)
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
Failed in webUI -> traceback on client, file IS deployed
Success in webUI -> no traceback, file is deployed
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.
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.
Automatic commit of package [rhncfg] release [5.9.22-1].
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.
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.
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.