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

[Michael DeHaan]

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 at redhat.com
> 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