On 08/10/2009 02:54 AM, Vreman, Peter wrote:
Can the events system be extended to include a reference of the
system? Including also the kickstart status creates audit information
per system. Adding a unique identifier per deployment extends it with
additional audit per kickstart.
The format of the event log can look like:
<systemname>,<time>,<user>,<unique
deployid/taskid>,<msg>,<comments>
For the node independent actions a special Nodename field like
"<<task>>" can be added.
Node1,08-08-09_01:00:00,admin,3214343432,"Kickstart start",""
Node1,08-08-09_01:30:00,admin,3214343432,"Kickstart end" ,"See
/var/log/cobbler/anamon/node1/ for log files"
Node1,08-08-09_01:40:00,admin,3214343432,"Reboot done" ,""
Node1,08-08-09_01:42:00,admin,3214343432,"Final configuration start"
,""
Node1,08-08-09_01:45:00,admin,3214343432,"Final configuration end"
,""
<<task>>,08-08-09_01:30:00,testing,3214343456,"Sync start","
See
/var/log/cobbler/tasks/3214343456/ for log files"
<<task>>,08-08-09_01:31:00,testing,3214343456,"Sync
end",""
<<task>>,08-08-09_01:32:00,testing,3214343487,"Buildiso
start"," See
/var/log/cobbler/tasks/3214343487/ for log files"
<<task>>,08-08-09_01:33:00,testing,3214343487,"Buildiso
end","ISO now
available for <A
HREF=\"/cobbler/pub/generated.iso\">download</A>"
Work that I see that needs to be done:
- Event list shall be made persistent
- Add systemname field to event list
- Add an unique identifier in the kickstart template to indicate a new
(re)deployment
- Extend services to allow POST data for the message to support
generating an event message from the node with wget:
$ wget --post-data "msg=Final configuration start" http://`echo
<http://%60echo> $COBBLER_SERVER`/cblr/svc/event/node1" --o /dev/null
Thoughts?
Regards,
Peter
I'm for improvements in tracking, but is this doing much more than just
mingling the event logs? I'm not sure that specifically is needed.
We do keep cobbler status information in a seperate log
(/var/log/cobbler/kicklog/$ip) -- which shows some of this information,
and is parsed out by "cobbler status":
[mdehaan@mdehaan ~]$ cat /var/log/cobbler/install.log-20090625
profile profile0http: 127.0.0.1 stop 1244745896.46
profile Fedora10-PAE-i386 192.168.1.105 start 1244820385.82
profile Fedora10-PAE-i386 192.168.1.106 start 1244820455.26
profile Fedora10-PAE-i386 192.168.1.105 stop 1244820710.89
profile demo 192.168.1.100 start 1245175512.75
profile demo 192.168.1.100 stop 1245175738.28
profile Fedora10-PAE-i386 192.168.1.101 start 1245194636.09
profile Fedora10-PAE-i386 192.168.1.101 stop 1245194851.18
profile Fedora10-PAE-i386 192.168.1.102 start 1245271540.78
profile Fedora10-PAE-i386 192.168.1.102 stop 1245271763.76
Though it's not as granular as you speak of. Just starts and stops.
There isn't a provision to put arbitrary event breaks in there (yet).
I think it would be great to make this a little better though and also
surface this in the web app ... and if done right it might be nice to
show the last time
a system was redeployed.
Once catch though is that it's not really a secure system (wgets from a
world readable kickstart) -- that information could be false -- and also
for PXE-based installations there is no system record (unless
auto-registration is used) to show status on. Which is a feature we
had before, since it's simply a log of IPs.
Since most of our logs are task based though, I think we can probably
stick with keeping things seperate from the main log (just as task logs
are now seperate) -- we'll just have to make sure that "cobbler status"
recognizes when entries are not in the "right" format (assuming we are
adding information) and ignores those old lines (or something
similar). So, whatever we add needs to not explode if it sees logfiles
from a previous version -- however it ends up doing that; it does not
really matter how.
Also, minor note -- Anamon is off by default on most systems -- mainly
because it /also/ presents a log flood problem for the same reasons (it
is essentially a free API to upload lots of text to the cobbler server),
so the pointer to the logfile directory for it is probably not something
we'd want there by default. Example use case: college lab. Would
we want to have a setting in the config file and make this logging off
by default if we attempt to update the system objects?
Thoughts on the above?
--Michael