Rainer Duffner wrote:
Am 18.12.2007 um 22:31 schrieb Eugene Ventimiglia:
We're currently using a homebrew system to provision vms for developers,
and I'm in the process of switching that to cobbler.
I used to keep a giant monolithic /tftboot/pxelinux.cfg/default with
entries for each os we need to install, ie:
LABEL manager_plain64
kernel /bootimages/RH-ES-4.0-U4-AMD64/vmlinuz
append initrd=/bootimages/RH-ES-4.0-U4-AMD64/initrd.img \
ks=http://osserver/profiles/Linux/manager_plain64.cfg
LABEL agent_rh5_vm
kernel /bootimages/RH-5.0/vmlinuz
append initrd=/bootimages/RH-5.0/initrd.img
ks=http://osserver/profiles/Linux/build_rh5_agent.cfg
LABEL agent64_rh5_vm
kernel /bootimages/RH-5.0-64/vmlinuz
append initrd=/bootimages/RH-5.0-64/initrd.img
ks=http://osserver/profiles/Linux/build_rh5_agent64.cfg
I've played with cobbler for the past day or so, and while I've had
great success setting of new machines, I havn't been able to figure out
where to put these custom kickstart files.
I've read the f manual, and it doesn't say either
In cobbler, you create a profile referencing a kickstart-template (not
a complete kickstart-file).
It takes complete kickstart files too, but yes. The only thing is if you
are feeding it one you already have you'll want to escape any $'s with
\$, otherwise the templating
engine can get just a little bit confused.
The profile should be as generic as possible (mine generally just
select a kickstart-template for now).
Only if you want it to be... Systems and profiles simply map "things" to
"what those things do". They can be as minimal or as complex as you want.
The simplest profile example is just:
cobbler profile add --name=foo --distro=FC-8-i386
--kickstart=/etc/cobbler/kickstart_foo.ks
cobbler system add --name=X --mac=AA:BB:CC:DD:EE:FF --profile=foo
And of course if you do "cobbler import" you get some starter profiles
created for free.
Could it be made into a textarea?)
Yes, it could :)
I couldn't get the "create partition-table with external script"-thing
to work, so I use ksmeta-variables and different profiles/templates) -
it works, too, and our requirements are slightly different for each
server anyway...
So, you have to distill out what is common in your kickstart-files and
turn that into one or more kickstart-templates, create different
profiles for these kickstart-templates (you have to spell-out the path
on the server to in the input-field, there's no nifty "select file"
dialogue).
Right, because you're not uploading a local file, you're picking one on
the server that already exists.
I expect most people to use the command line, but as interest in the Web
UI grows, information like this about usability perceptions /is/ helpful.
If uploading kickstart files proves useful enough, that's something we
can think about adding.
Then, when you create systems, you can specify the details that
make-up the different systems.
I hope this was clear enough (I'm afraid not) - but it's all in the
wiki anyway.
I think the original poster is ok with that and just wanted to know
where to store files, but yes, there's lots of online docs on this.
My suggestion is to do all pre-production testing in either VMware
Workstation (or maybe the new Server 2.0 Beta, because of
RHEL5-support), for the simple fact that you will reboot often - and
that takes minutes on my blades, compared to 1 second with VMware...
I probably saved hours this way.
Or Xen.... or KVM .... both of which are free, open-source, and
supported in koan :)
cheers,
Rainer
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
