Hi,
Not sure if anyone else has run into this issue, but I thought I'd report back just in case someone does.
Issuing a "cobbler status" to see when systems were installed did not work for me with the following error:
Tue Apr 17 10:41:09 2012 - INFO | Exception occured: <type 'exceptions.ValueError'>
Tue Apr 17 10:41:09 2012 - INFO | Exception value: too many values to unpack
Tue Apr 17 10:41:09 2012 - INFO | Exception Info:
File "/usr/lib/python2.6/site-packages/cobbler/remote.py", line 1948, in _dispatch
return method_handle(*params)
File "/usr/lib/python2.6/site-packages/cobbler/remote.py", line 1598, in get_status
return self.api.status(mode=mode)
File "/usr/lib/python2.6/site-packages/cobbler/api.py", line 739, in status
return statusifier.run()
File "/usr/lib/python2.6/site-packages/cobbler/action_status.py", line 166, in run
self.scan_logfiles()
File "/usr/lib/python2.6/site-packages/cobbler/action_status.py", line 74, in scan_logfiles
(profile_or_system, name, ip, start_or_stop, ts) = tokens
"tokens" is a list that contains the elements of each line from /var/log/cobbler/install.log* split by whitespace. The code in action_status.py expects the lines in install.log to look like this:
system cobblertest None start 1334622964.41
If you are upgrading from 2.0.x to 2.2.x, you will likely have install.log entries like:
system cobblertest None stop 14/03/2012 15:15:52
As you can see, there has been a change in timestamps, so Python freaks out in line 74 when it finds more values in the "tokens" list than it expected. The way I fixed it was by simply removing old install.log entries that used the human-readable date/time. Of course, it could have been fixed by processing each file and converting to timestamp, but I personally don't care about the old install entries so it was quicker to delete them. Perhaps the better fix is to update action_status.py so it can detect the older format and do it for you, that way one less hiccup in the upgrade.
Lastly, my /etc/logrotate.conf is configured to compress log files, which means I have a few /var/log/install.log-YYYYMMDD.gz files. Clearly the code in action_status.py is not designed to handled gzipped install.log files. Should this condition be taken care of by the cobbler code or should install.log files not be gzipped?
- Gonzalo