Also, this might be a dumb question but does the livecd know how to
"install to self" as well?
The live CD (not to be confused with "cobbler buildiso", which is a
simpler "dead" CD) works by detecting the first available HDD during
boot up, then formats the drive and installs grub on it's MBR. Koan
is then invoked to modify grub on the MBR. The livecd can be built to
install to a specific profile name (as defined in Cobbler at the time of
installation, not build time), or can be set to autodiscover. In this
case, koan scans the interfaces for a mac address, and does a remote
look up in Cobbler (via XMLRPC) to find the name of the matching Cobbler
system object, if any.
This way, the live CD simulates the assignment of a given system (by MAC
address) to a given profile, in just the same way that PXE works.
However, this requires building the live CD on F8, and is not as
tolerant of finding "new" hardware (such as my SAS card), and the "dead"
CD will always work in those scenarios -- you just won't have the
potential for auto-discovery.
The question then remains do we keep the live CD around, and just use
the simpler "dead" CD, or what... the likely answer is that we end up
having both, and explain that for 90% of the users, the "dead" CD is
fine, and the live one is only needed if you want to do assignments
between systems and profiles remotely, to achieve "PXE equivalence" in
that respect. That is probably not critical for most folks, but might
be nice to have.
Yours,
Aaron
On Mon, May 5, 2008 at 10:47 AM, Michael DeHaan <mdehaan@xxxxxxxxxx
<mailto:mdehaan@xxxxxxxxxx>> wrote:
Subhendu Ghosh wrote:
Michael DeHaan wrote:
For a while Cobbler has had a solution based on koan and
the live CD to enable network provisioning of bare metal
in environments that either do not have DHCP, or do not
have control over DHCP that is sufficient enough to set up
a PXE environment. Naturally, if you can set up a PXE
environment with Cobbler, it's very useful to have, and
you'll want it.
So, along came the live CD.
The live CD was built using a recent Fedora, and it had
the magic ability to install any distro -- /except/ you
had to use Fedora to build the Live CD, and the build
process was slow, and the live image was a bit bigger than
it needed to be. However, due to driver constraints, it
didn't always support the latest in storage technology --
that was a
problem.
We have finally implemented the low-tech solution, thanks
to various folks in Red Hat GPS, and some hacking I've
done to integrate that closer into cobbler.
Using 0.9.X or later (it's checked in now into the git
"devel" branch) you can do:
cobbler buildiso [--iso=] [--tempdir=] [--profiles=]
This will automatically generate an ISO that allows for
menus just like Cobbler's PXE boot menus, for installing
new systems. I also plan to allow a configurable default
profile for those who want to mass deploy this image using
remote management processors, etc.
The menu will contain an entry for each bare metal
bootable profile, with the current data set in Cobbler.
Given that Cobbler now generates kickstarts in real time,
changes to the kickstart templates can be made without
reburning the CD!
Again, the live CD is more dynamic, but this is much
smaller, faster, and easier to build.
The one thing the live CD still offers is simulation of
the MAC address detection feature of PXE, but if you don't
need to use cobbler system records to provision your
lab/datacenter/etc, this will also get you there -- and is
probably the perfect fit if the Live CD was not working
out for you.
Test release will be available soon, git is available now.
--Michael
If the iso(s) can be made available through the web
infrastructure, and accessible via a predefined or calculated
path, then a external rules engine could drive the
provisioning process through the remote management
processors's virtual media capabilities.
It can :)
mkdir /var/www/html/foo
cobbler buildiso --iso=/var/www/html/foo/kickstart.iso
I just need add the flag for setting what the default is and
making the timeouts variable.
Perhaps the profiles module could be extended to define
whether a iso should be generated or not. An easy way to
automatically generate boot isos.
Right now there's some basic code to keep paravirt "-xen" distros
from showing up on the ISO since they have no chance of being
bootable. Though that is a good idea.
Another possibility is to add it as "cobbler profile edit
--name=foo ... --menu=foo" to do submenus, and if we really wanted
that. We could allow
--menu=hide as part of that syntax.
-sg
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx <mailto:et-mgmt-tools@xxxxxxxxxx>
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx <mailto: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
