[et-mgmt-tools] Cobbler features

[Michael DeHaan]

Tim Hughes wrote:
> On 5/17/07, Michael DeHaan <mdehaan at redhat.com> wrote:
>> Aaron Lippold wrote:
>> > Hi Miheal,
>> >
>> > These sound like great options! The moment the "create install CD/DVD"
>> > feature is ready I will be using it!! Thank you for being so open and
>> > responsive to us the lowly end user :).
>> >
>> > Question, you call it a 'netinstall cd' does that mean that the CD
>> > would or would not contain  the install packages? If not, could that
>> > be added as an option? i.e. cobbler --createcd-netinstall or
>> > --createcd-mediainstall ... myinstall.iso? I would guess adding the
>> > copy of the rpms from the repo would be a small bit of code.
>> Yeah, I think there is a need for both.    From what I'm told the later
>> isn't incredibly complex either, and there
>> are some people that are already quite good at doing this who I can tap
>> for advice.
>>
>> When doing the non-net-install the kickstart files have to be managled a
>> bit such that the source changes, and that
>> the tracking options in post don't occur, so the netinstall bit would
>> probably happen first.
>> >
>> > I know I would use  both very heavily along with cobblers regular
>> > pattern. In some cases it might be easier just to walk and or mail a
>> > DVD to some places. Distributed group review of a system, testing
>> > that's just 'plug in the cd and then run your tests, etc.
>> >
>> > Thanks again!
>> >
>> > Aaron
>> >
>> > On 5/16/07, Michael DeHaan <mdehaan at redhat.com> wrote:
>> >> Based on recent list activity, and a talking with everyone at 
>> Summit and
>> >> IRC, here's my list of the top 4 things I'd like to see added to 
>> cobbler
>> >> in the near term:
>> >>
>> >> -- Virt support for deploying additional virt types
>> >>     KVM, etc
>> >>     Fullvirt Xen
>> >>
>> >> -- Extend the repo management code to deal with older non-yum content
>> >> (RHN), like mrepo can do, such that running mrepo as a seperate 
>> tool for
>> >> older distros is not required.
>> >>
>> >> -- Build a netinstall CD from cobbler for environments that don't do
>> >> PXE.    Tie the CD to a specific profile (or better, eventually, 
>> provide
>> >> a boot menu).   Lots of folks need baremetal provisioning and due to
>> >> aspects beyond their control can't use PXE.
>> >>
>> >> -- Support either om_shell or DNSMasq, to avoid the dhcp reload wait
>> >> time when manage_dhcp is enabled and systems are updated.   (Some 
>> folks
>> >> I believe are looking at both of these?)
>> >>
>> >> If there's something you'd like to see added feature-wise, I'd be 
>> glad
>> >> to hear ideas.
>> >>
>> >> --Michael
>> >>
>> >> _______________________________________________
>> >> et-mgmt-tools mailing list
>> >> et-mgmt-tools at redhat.com
>> >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>> >>
>> >
>> > _______________________________________________
>> > et-mgmt-tools mailing list
>> > et-mgmt-tools at redhat.com
>> > https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>>
>> _______________________________________________
>> et-mgmt-tools mailing list
>> et-mgmt-tools at redhat.com
>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>>
>
> Just an idea for scalability, would it possable to store a lot of this
> in a database, I have setup a cobbler server at each of my three sites
> so that i can do pxi and it would be much easier to manage the
> configurations all from a central database that the cobbler servers
> could each contact rather than having to configure 3 individual
> servers
>

One easy way to do this without a lot of database and active 
connectivity infrastructure (which rather complicates the app)
would be to have one master server and several slaves.   All that has to 
be done is to copy the source information over to the slaves
and ask cobbler sync to keep things up to date.

-- On each slave server, install cobbler, run "cobbler check", and 
configure /var/lib/cobbler/settings only
-- Whenever a change takes place on the master, and you want to sync up 
the slaves, run a script that ...
-- (A) Scp /var/lib/(distros|systems|profiles) to the slaves. 
-- (B) rsync /etc/cobbler to the slaves
-- (C) Also rsync all of the kernel, initrd, and kickstart files stored 
in other directories to the slaves.   A common NFS mount point would 
eliminate this.
-- (D) If you have used "cobbler import", rsync /var/www/cobbler also to 
get the kickstart tree sources
-- (E) for each slave "ssh root at slave01.example.com cobbler sync".  

I think that would work nicely and still leaves the config files human 
readable.   If this is something a lot of people are interested in 
doing, I can probably
include a command to automate it, though I imagine particular install 
variations might need site specific customizations.   An article on the 
Wiki is probably a
better bet.

Having alternate storage backends (like a database) is interesting and 
that may happen someday, but since there are variations in the 
configurations between
the servers, just putting everything in a database still leaves some 
stuff out of the picture (whether all the content is accessible from the 
same paths, etc).

Thoughts?

--Michael