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