[et-mgmt-tools] Re: Two cobbler feature suggestions (fwd)

Michael DeHaan mdehaan at redhat.com
Mon May 7 13:09:27 UTC 2007

Bryan K. Wright wrote:
> Hi folks,
> 	Here's a note I sent recently to Michael DeHaan, and his response.
> He suggested I forward it to the list.  As he suggests, I'll take a look
> at Cobbler's trigger infrastructure and see what would be required
> to get Cobbler to play with dnsmasq.

Triggers are covered in this email:


Basically you'll want to look around at "api.py" in the source checkout 
to see what methods are available, call
cobbler_api.distros().find(name) on the first argument to the script, 
and retrieve the cobbler object for the system.   From there, you
can see what you want to manipulate for dnsmasq.   Once you have a 
cobbler object, you can access all of the information in 
"item_system.py", which includes things like the --pxe-address values, 
what the name of it's profile is, and so forth.

All of the above assumes something would be done in Python.... this 
doesn't have to be the case.  If you want to write something in another
language, that script will still be called with the system object name 
as the first argument.   Other information about that system can then be 
gathered from /var/lib/cobbler/systems by parsing the YAML file ... 
Perl's YAML.pm, I believe Ruby has a yaml.rb, etc.   Of course, using 
the cobbler API would be better/easier -- and would avoid the need to 
use a YAML module.

Now there currently isn't a value for --pxe-hostname in the systems 
source code (item_system.py) to allow setting that parameter, but it can 
be added in the same way that pxe-address is already in the code.   (A 
minor tweak will also need to be made to cobbler.py to allow that 
parameter to be used on the command line)

I'd be glad to help out with this, though I'll be away giving a 
presentation at Red Hat Summit for the rest of this week.
> 						Bryan Wright
> ------- Forwarded Message
> Date: Mon, 07 May 2007 08:15:51 -0400
> From: Michael DeHaan <mdehaan at redhat.com>
> User-Agent: Thunderbird (Macintosh/20070221)
> MIME-Version: 1.0
> To: bryan at Virginia.EDU
> Bryan K. Wright wrote:
> Bryan,
>> Hi Michael,
>> 	Thanks for writing cobbler! I've been using it for a little
>> while now, and I'm loving it.
> Glad you like it and thanks for the suggestions.   Quick question -- Can 
> this email be sent to et-mgmt-tools at redhat.com?     Other folks might 
> benefit from this discussion...
>> 	For what it's worth, here are a couple of feature suggestions
>> for future versions:
>> 1.  It would be nice to have a flag like "--pxe-name" when adding
>>     systems.  I'd like to be able to assign names to the hosts in
>>     the dhcpd.conf, instead of the default "label1", "label2", etc.
> Agreed.   I was having this discussion yesterday on IRC (#cobbler / 
> irc.freenode.net)
>> 2.  This would be a lot of work, but have you thought about supporting
>>     dnsmasq as an alternative to the ISC dhcpd?  Dnsmasq is nice since
>>     it can draw its dhcpd information directly from /etc/hosts and
>>     /etc/ethers, and it has a cacheing DNS built in.  Right now,
>>     I'm using cobbler for provisioning via dhcp/pxe, and maintaining 
>>     /etc/hosts by hand and running dnsmasq to serve up hostname resolution 
>>     from it (with dnsmasq's dhcp service turned off).  It'd be great
>>     to get rid of the duplication.
> It's doable, although I am not super-familiar with dnsmasq.    A couple 
> of options:
> (1)  You turn off manage_dhcp in /var/lib/cobbler/settings, and use the 
> trigger script infrastructure (think "plugins", they're mentioned in 
> the  manpage) and write a quick extension using the cobbler API to 
> update dnsmasq when new cobbler systems are added/removed.     Trigger 
> scripts are just executable scripts in /var/lib/cobbler/triggers that 
> get called with the name of the object being added.   If written in 
> Python, using the cobbler API to mine the rest of the system info (such 
> as the value for a --pxe-name parameter) is fairly easy.
> (2)  You can submit a patch to cobbler's api_sync mode, to accept both 
> modes of dealing with dhcp.   I would probably have to tweak it just a 
> little bit, but that would be a great start.  Ideally the choice of 
> servers would be in /var/lib/cobbler/settings, to switch between approaches.
> (3)  You can send me an example script of how you are configuring 
> dnsmasq today, and I can possibly incorporate something similar into 
> cobbler.
> Some other folks are exploring dynamic DNS integration and possible 
> tie-ins with omshell/OMAPI but I think this could be more interesting.   
> I would like to do some exploration myself and see where this goes.   
> Generally this looks like it would be best
> implemented as a trigger, and someone could choose whether or not to 
> install it -- possibly something that could be shipped in a "contrib" 
> directory.
> If you'd like to forward this to et-mgmt-tools at redhat.com that would be 
> great -- I'm sure other users have input on this as well.
> Thanks,
> Michael
>> 						Bryan
> ------- End of Forwarded Message

More information about the et-mgmt-tools mailing list