[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [et-mgmt-tools] Cobbler features



Tim Hughes wrote:
On 5/17/07, Michael DeHaan <mdehaan 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 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 redhat com
>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>>
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools redhat com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools 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 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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]