[et-mgmt-tools] Re: Cobbler, findks.cgi, registration, and so forth

[Michael DeHaan]

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)