Ok, kickstart tracking is implemented and pushed, so if anyone wants to
play with this, please check out the Mercurial repository. Just run a
"cobbler sync" after the upgrade to get Apache configured correctly. I
probably won't release this (along with the rest of 0.3.6) until
mid-next week. Manpage docs have to be written first :)
In order to see when machines have truly finished, the kickstart files
need to contain the following somewhere in post:
%post
TEMPLATE::kickstart_done
I have updated the default kickstarts that come with cobbler, so you can
see what is done there.
And then, at any time, one can run the following and see following for
all distros in their system:
[root@mdehaan cobbler]# cobbler status
Address | State | Started |
Last Request | Seconds | File Count
172.16.56.91 | notdone | Thu Jan 4 16:23:16 2007 | Thu
Jan 4 17:13:32 2007 | 3016 | 1422
Individual status of files transferred is stored in
/var/log/cobbler/kicklog/$IPADDR. Right now, these files are not
pruned, though in future versions I might decide to delete them if they
haven't been modified in 30 days, or something like that. This really
shouldn't be a problem as the files won't be huge.
If you're using kickstart trees on another partition, you'll only see a
few files transferred, if at all, and will have less resolution into
kickstart status. To fix this, just create a symlink to
/var/www/cobbler/localmirror/$foo for each kickstart tree $foo you have,
and provision from http://$server/cobbler_track/localmirror/$foo as
source URL in the kickstart. The "track" in the URL is a bit of
magic, and if you're using "cobbler import" that will be done
automatically for you.
As usual, this feature can be ignored for those that don't need to
understand it. It will still be there, though :)
For all those with suggestions (or better, patches) to improve the
tracking information, those are definitely welcome. I intend to add
some YAML and/or XML output in the future to supplement the existing
command. (i.e. "cobbler status --mode=yaml").
--Michael
Michael DeHaan wrote:
Friendly Neighborhood Cobbler Users,
One of the things I've wanted to do with cobbler for some time was be
able to keep track of systems as they kickstart, so that higher level
applications and scripts could, if they wanted, try to detect which
machines had stalled or otherwise failed to complete. Some
rudimentary support for this is going into upstream now, and I'll be
refining it some more over the next few days.
How does it work?
Well, it only works for kickstart trees that come out of
/var/www/cobbler -- local content -- so if you're installing off of a
Fedora mirror, this gives you more reason to let Cobbler mirror that
distro and serve it locally (plus, it's nicer to the guy running the
mirror). This means kickstart tracking will work for any distros
that have been pulled down via "cobbler import" or any distributions
you have created yourself in that directory
(/var/www/cobbler/localmirror/foo is the preferred destination for
such content). If you already have a kickstart tree elsewhere,
symlinking it should be good enough if you configure Apache
appropriately.
So, how it works -- this new release installs a mod_python filter
handler automagically for /var/www/cobbler, and access to certain
files in that directory are logged with the IP address of the
requester, the time, and the file requested. From this, it is
possible to tell what profiles are being requested, what RPM's they've
requested, and when they are done (they request a special filename at
the bottom of their kickstarts when they are done). This all
currently goes into /var/log/cobbler/cobbler.log and there is a
logrotate script in /etc/logrotate.d that keeps the logfile
manageable. This is all done from the RPM basically, so there isn't
any added pain on the user.
This will probably require some more advanced tools to understand the
logfiles and report on the status of the kickstarts. Some things
this tool might need to look at would be things like produce reports
that provide information such as "this machine hasn't requested an
file in 30 minutes and is not yet finished" and so on.
If anybody is already doing this sort of thing, or has ideas on what
sort of form factor reporting tools should take, I'd love to hear your
opinion. I may end up keeping the log data itself as YAML, so that
it is more easily read back by cobbler to produce a report.
Imagine:
cobbler showkickstarting
192.168.1.10 IN PROGRESS | 50 rpms requested | 35 minutes
elapsed 192.168.1.11 FINISHED | 250 rpms requested | 55
minutes elapsed
192.168.1.12 STALLED? | 15 rpms requested | 250 minutes elapsed
and so on.
Comments?
--Michael
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
