[et-mgmt-tools] intended use of cobbler

[Michael DeHaan]

Tru Huynh wrote:
> On Wed, Oct 11, 2006 at 05:48:53PM -0400, Michael DeHaan wrote:
> ...
>> Just out of curiosity -- what is your intended use for cobbler?
> 
> I have been making my own kickstart/dhcp/dns configurator.
> Mostly shell scripts to maintain our local machines.
> 
> That another RFE:
> - MAC adress -> fqdn for bind configuration?

This isn't what you want, but cobbler can set hostnames for dhcpd.conf 
if you set manage_dhcp to 1 in /var/lib/cobbler/settings and use 
--pxe-address.

I'm not entirely sure I'd want to include management for generating BIND 
configurations though as that seems like something that's usually not 
very generic -- something sysadmins don't want to auto-generate, 
although I'm not a DNS expert.

Since /var/lib/cobbler/systems is YAML, that does allow reading the 
pxe_address out of the config file and using that (in some other script) 
to generate the BIND config if you want to do that.

If you come up with something like this, I'd be very interested in 
seeing it and maybe that is something that could be incorporated if it 
made sense.

> 
> and another one:
> I would like to be able to choose the pxe bootloader:
> -  NetBSD's pxeboot loader
> http://www.bsdsupport.org/toc.php?paper=pxebootnbsd
> - FreeBSD's
> http://people.freebsd.org/~alfred/pxe/en_US.ISO8859-1/articles/pxe/article.html
> - grub's (ok one need to pre-build the pxegrub file for the NICs)
> ...
> - windows ?

Cobbler was initially written for fully-automatic Linux installs, 
specifically on OS's that support kickstart.  I'm not entirely sure, for 
instance, what the kickstart analog is for BSD -- I know the kickstart 
analog for Windows (XP's pre install environment), it's seriously evil 
(not to mention proprietary), and we aren't going there :)

I would consider patches on the BSD items.   Abstracting out the part 
the code behind "--pxe-arch" to make it more generic seems neccessary 
first, to allow such plugins to be written.  Currently --pxe-arch is 
just an IA64/x86 (or x86_64) toggle and supports configurations for only 
those two boot loaders.   That being said, things don't have to be that 
way.  Though making the bootloader abstraction better and easing some 
reliance on kickstart seems valid.  I'll add that the TODO list to 
enable such future changes.

It might end up that support for OS's that don't do kickstart gets 
added, but that they don't do automated installs and therefore rely on 
the sysadmin to set up the image appropriately.

Generally cobbler was written for things that support kickstart. 
Debian/Ubuntu *might* be nice to have.  This also seems to apply it 
would be nice for someone to add Debian/Ubuntu packaging along with that.

That all being said, my primary interest is still with kickstartable 
Linux systems.  Where it's easy enough to add more support, though, such 
things can be considered.

So, if I can abstract out the bootloader architecture bits to enable 
something that is more plugin centric, can I expect patches for 
FreeBSD/NetBSD?  :)

> 
> Best regards,
> 
> Tru
>