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
