Michael DeHaan wrote:
Michael DeHaan wrote:
Hi folks,
So earlier I wrote about some ideas around automatically registering
systems when Cobbler sees them, and I wrote up some example scripts
for usage by the FreeLinuxPC guys. To me, this seems pretty
compelling as you wouldn't have to manually build up a list of every
MAC address in your data center and so on.
It turns out some of the mac data I was relying on isn't present, so
this didn't work as well as I thought it did -- but -- good news -- I
can fix it.
So since I need to fix this, and wanted to bounce some ideas off
everyone and find out if this would be useful or not. It seems
useful to me anyway, at least as a configuration option.
The idea -- all kickstart requests through cobbler will now go
through a cgi (or more likely, a new mod python piece for performance
reasons) that will serve up the kickstart file for all cobbler-hosted
kickstart files. Then, we have the configuration ability to
automatically add new system objects (correctly configured to the
proper profile) when they get installed. Since we are also doing
this via a web script, we can also decide to re-evaluate the
templates at runtime, effectively eliminating the need for "cobbler
sync" for anything but regenerating DNS/DHCP.
For an example of the registration case -- if you tftpboot 500 new
systems ("straight off the truck"), and you use the PXE menu to
assign some to "webservers" and some to "dbservers", this
reorganization of how we do things would allow us to auto-create
system records, correctly assigned to the profile they were assigned
to, with the MAC data already filled in.
For security reasons, this would only add new system records if the
objects were not already there. Due to various catch-22's, if you
add a new system this way, and then reinstall it using the PXE menus,
we can't have it update the profile associations in cobbler. However
-- you wouldn't need to do this, because you could do something as
simple as:
cobbler system edit --name=foo --newprofile=bar --netboot-enabled=1
(and cycle power)
in order to do reinstalls.
This seems to be a nice solution for logging the profiles and mac
info at first install time and saves some data entry. (and yes,
we'll have a setting to turn this off).
Thoughts on this and on install time template evaluation?
--Michael
Minor clarification -- if anyone is familiar with findks.cgi, this is
somewhat different. This would be more like
"http://$server/cobbler/getks?profile=foo";, though Anaconda takes care
of feeding the mac (and the IP) info to the script/program. We
would want to log the mac, but I'm unsure if we want to store the
IP... as that would instantly turn a regular DHCP ip into a DHCP
reservation if using the mangage_dhcp feature. I kind of like that
idea though, but wanted to bounce that off people who were using
Cobbler to manage DHCP -- as that may not fit workflows.
In terms of settings, it looks like we're going to have
auto_register_new_systems y/n
(and possibly) auto_register_ip_info y/n
(We could possibly also expand koan to use more of this data to help
prevent virtual MAC collisions when installing with --profile records
and not --system records, provided we make a remote XMLRPC call to
retrieve a free MAC address)
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
A good bit of this is checked in now -- registration will just use the
mac and happens when a system requests a kickstart and also has
kssendmac set. There will be a setting to enable this behavior (off by
default). I've been able to clean up the sync code /considerably/ by
removing a lot of legacy filesystem stuff from previous Cobbler
versions. The code for DHCP, yum, and PXE templating is now split out
into different files and so forth. All CGIs have been moved to
mod_python as well and use the XMLRPC API directly. I will be
testing/refining all of this next week -- and it looks like we can get
the 0.9 test release out much sooner than I expected given the roadmap:
https://fedorahosted.org/cobbler/wiki/TheRoadmap
Another nice thing about this cleanup is it is making sync, as well as
individual system edits, a good deal speedier too.
--Michael
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
