9:55 a.m.
Hi,
I'm looking at cobbler to replace our actual home brewed kickstart system to ease
'off truck' scenarios.
We currently rely on the servers BMC (Ilo's XMLRPC interface) to initiate our
kickstarts and map a boot media. In this way it is easy to match the bare metal hardware
with a system profile but I would like to have a solution independent of the BMC.
Going forward with Cobbler and PXE based installs, I see a challenge with managing
mac-adresses and linking them with a system profile as we have a lots of different server
models with 2/4 nics and various network configuration where not all NICs can reach a
cobbler server.
I really like the auto-registration feature and I was thinking of using it the following
way and get around the MAC address challenge:
1. Use a default system profile all 'off truck' servers will network boot to.
The boot image is a custom CentOS 5 livecd with the following onboard:
* Needed binaries to identify the hardware (dmidecode etc.)
* Koan client
* Func client
* Utilities to create vendor RAID arrays and firmware updates
* Utilities to configure BMC if still in vanilla state (IPMI tools / Hponcfg).
* Fancy perl module used as a Cisco CDP querier
2. The image finds the server model, firmware, serial number and all possible NIC details
3. Cobbler-register creates the server's system entry using the server model and
serial number since we have no idea of its hostname right now.
4. Func connects to its master and wait for commands.
From the func master being also the cobbler server, I know which
servers are ready to be kickstarted and can rename/assign their profiles easier,
translating serial numbers into hostnames. I can also push firmware updates, create RAID
arrays and perform some inventory tasks.
All is left is trigger a remote koan --replace-self with func to fire the install.
b.t.w... I really like the hidden --kexec switch :-)
Do you think I'm going a too complicated way or does this make sense to some of you ?
I remember Michael had some thoughts about extending the auto-registration feature to
include other fields but I have not seen much interest on the list.
Happy new year,
Jean-Francois Nadeau
6:20 p.m.
On Fri, 31 Dec 2010 10:55:36 -0500, Jean-Francois Nadeau <jfnadeau(a)taleo.com>
wrote:
Hi,
I'm looking at cobbler to replace our actual home brewed kickstart system to ease
'off truck' scenarios.
We currently rely on the servers BMC (Ilo's XMLRPC interface) to initiate our
kickstarts and map a boot media. In this way it is easy to match the bare metal hardware
with a system profile but I would like to have a solution independent of the BMC.
Independent of the BMC in what way? We use the BMC currently to do
power management, I'm curious how you currently use them.
Going forward with Cobbler and PXE based installs, I see a challenge
with managing mac-adresses and linking them with a system profile as we have a lots of
different server models with 2/4 nics and various network configuration where not all NICs
can reach a cobbler server.
We have a similar issue. We end up putting all interfaces into cobbler
and then having some logic in the kickstarts sort things out. I find
the easiest way to figure out which interface has access to cobbler is
to dhcp over the interfaces till one works.
I really like the auto-registration feature and I was thinking of
using it the following way and get around the MAC address challenge:
1. Use a default system profile all 'off truck' servers will network boot to.
The boot image is a custom CentOS 5 livecd with the following onboard:
* Needed binaries to identify the hardware (dmidecode etc.)
* Koan client
* Func client
* Utilities to create vendor RAID arrays and firmware updates
* Utilities to configure BMC if still in vanilla state (IPMI tools / Hponcfg).
* Fancy perl module used as a Cisco CDP querier
2. The image finds the server model, firmware, serial number and all possible NIC
details
3. Cobbler-register creates the server's system entry using the server model and
serial number since we have no idea of its hostname right now.
4. Func connects to its master and wait for commands.
>From the func master being also the cobbler server, I know which servers are ready to
be kickstarted and can rename/assign their profiles easier, translating serial numbers
into hostnames. I can also push firmware updates, create RAID arrays and perform some
inventory tasks.
All is left is trigger a remote koan --replace-self with func to fire the install.
b.t.w... I really like the hidden --kexec switch :-)
Do you think I'm going a too complicated way or does this make sense to some of you ?
I remember Michael had some thoughts about extending the auto-registration feature to
include other fields but I have not seen much interest on the list.
It feels a bit complex to me, but everything you have listed there seem
doable. I would shy away from a 'live' image and go with a default
profile/install. But I tend to shy away from images out of habit.
As for extending the auto-registration feature to have other fields. It
is basically only limited by the information that cobbler can store. I
thought about expanding the comment field to be able to take complex
data structures (aka a python dict), but I've not really had any need
for it. I'm definitely willing to do that if people would find use for
it. Perhaps even call it something else and leave the comment field
alone.
--
Scott Henson
Red Hat CIS Operator
WVU Alum BSAE/BSME
9:41 a.m.
Hi Scott,
Thanks for replying. See my comments below...
JFN
________________________________________
From: Scott Henson [shenson(a)redhat.com]
Sent: Sunday, January 02, 2011 7:20 PM
To: Jean-Francois Nadeau; 'cobbler(a)lists.fedorahosted.org'
Subject: Re: Ideas around auto registration
On Fri, 31 Dec 2010 10:55:36 -0500, Jean-Francois Nadeau <jfnadeau(a)taleo.com>
wrote:
Hi,
I'm looking at cobbler to replace our actual home brewed kickstart system to ease
'off truck' scenarios.
We currently rely on the servers BMC (Ilo's XMLRPC interface) to initiate our
kickstarts and map a boot media. In this way it is easy to match the bare metal hardware
with a system profile but I would like to have a solution independent of the BMC.
Independent of the BMC in what way? We use the BMC currently to do
power management, I'm curious how you currently use them.
JFN: I should have specify: idenpendant from the virtual console and media for the
kickstart phase. This cost extra $$/year with HP's ILO3 now. ILO xmlrpc API have
been working great in the past to control both power and virtual media... but I seek
another solution since we introduced IPMI only capable servers and IPMI 2.0 can't
mount virtual medias generated from our kickstart system.
Going forward with Cobbler and PXE based installs, I see a challenge
with managing mac-adresses and linking them with a system profile as we have a lots of
different server models with 2/4 nics and various network configuration where not all NICs
can reach a cobbler server.
We have a similar issue. We end up putting all interfaces into cobbler
and then having some logic in the kickstarts sort things out. I find
the easiest way to figure out which interface has access to cobbler is
to dhcp over the interfaces till one works.
JFN: But without an auto-registration phase you need to feed them all into cobbler right
? I was seeking an alternative to this MAC resolution into a system hostname/profile.
I.e. We have standardized BMC hostnames we could automatically guess the server hostname
from via triggers (if I understand well what they are for)
I really like the auto-registration feature and I was thinking of
using it the following way and get around the MAC address challenge:
1. Use a default system profile all 'off truck' servers will network boot to.
The boot image is a custom CentOS 5 livecd with the following onboard:
* Needed binaries to identify the hardware (dmidecode etc.)
* Koan client
* Func client
* Utilities to create vendor RAID arrays and firmware updates
* Utilities to configure BMC if still in vanilla state (IPMI tools / Hponcfg).
* Fancy perl module used as a Cisco CDP querier
2. The image finds the server model, firmware, serial number and all possible NIC
details
3. Cobbler-register creates the server's system entry using the server model and
serial number since we have no idea of its hostname right now.
4. Func connects to its master and wait for commands.
>From the func master being also the cobbler server, I know which servers are ready to
be kickstarted and can rename/assign their profiles easier, translating serial numbers
into hostnames. I can also push firmware updates, create RAID arrays and perform some
inventory tasks.
All is left is trigger a remote koan --replace-self with func to fire the install.
b.t.w... I really like the hidden --kexec switch :-)
Do you think I'm going a too complicated way or does this make sense to some of you ?
I remember Michael had some thoughts about extending the auto-registration feature to
include other fields but I have not seen much interest on the list.
It feels a bit complex to me, but everything you have listed there seem
doable. I would shy away from a 'live' image and go with a default
profile/install. But I tend to shy away from images out of habit.
As for extending the auto-registration feature to have other fields. It
is basically only limited by the information that cobbler can store. I
thought about expanding the comment field to be able to take complex
data structures (aka a python dict), but I've not really had any need
for it. I'm definitely willing to do that if people would find use for
it. Perhaps even call it something else and leave the comment field
alone.
JFN: I.m.h.o. auto-registration could fill all valid system fields... the first that
comes to me is the BMC settings that can easily be found locally using IPMI or vendor
tools. Serial number / UUID (virt) would be nice too.
Thanks for the great product.
--
Scott Henson
Red Hat CIS Operator
WVU Alum BSAE/BSME
9:57 a.m.
On Mon, 3 Jan 2011 10:41:43 -0500, Jean-Francois Nadeau <jfnadeau(a)taleo.com> wrote:
Hi Scott,
Thanks for replying. See my comments below...
JFN
________________________________________
From: Scott Henson [shenson(a)redhat.com]
Sent: Sunday, January 02, 2011 7:20 PM
To: Jean-Francois Nadeau; 'cobbler(a)lists.fedorahosted.org'
Subject: Re: Ideas around auto registration
On Fri, 31 Dec 2010 10:55:36 -0500, Jean-Francois Nadeau <jfnadeau(a)taleo.com>
wrote:
> Hi,
>
> I'm looking at cobbler to replace our actual home brewed kickstart system to
ease 'off truck' scenarios.
>
> We currently rely on the servers BMC (Ilo's XMLRPC interface) to initiate our
kickstarts and map a boot media. In this way it is easy to match the bare metal hardware
with a system profile but I would like to have a solution independent of the BMC.
Independent of the BMC in what way? We use the BMC currently to do
power management, I'm curious how you currently use them.
JFN: I should have specify: idenpendant from the virtual console and media for the
kickstart phase. This cost extra $$/year with HP's ILO3 now. ILO xmlrpc API have
been working great in the past to control both power and virtual media... but I seek
another solution since we introduced IPMI only capable servers and IPMI 2.0 can't
mount virtual medias generated from our kickstart system.
Ahh, that makes sense and is exactly what we currently do.
> Going forward with Cobbler and PXE based installs, I see a
challenge with managing mac-adresses and linking them with a system profile as we have a
lots of different server models with 2/4 nics and various network configuration where not
all NICs can reach a cobbler server.
We have a similar issue. We end up putting all interfaces into cobbler
and then having some logic in the kickstarts sort things out. I find
the easiest way to figure out which interface has access to cobbler is
to dhcp over the interfaces till one works.
JFN: But without an auto-registration phase you need to feed them all into cobbler right
? I was seeking an alternative to this MAC resolution into a system hostname/profile.
I.e. We have standardized BMC hostnames we could automatically guess the server hostname
from via triggers (if I understand well what they are for)
Yes, we have a listing of these provided by the vendor, but I see no
reason why one would not be able to use an initial provisioning phase to
provide that information into cobbler via auto-registration. This seems
like a very good idea in that case.
> I really like the auto-registration feature and I was thinking
of using it the following way and get around the MAC address challenge:
>
> 1. Use a default system profile all 'off truck' servers will network boot
to.
> The boot image is a custom CentOS 5 livecd with the following onboard:
> * Needed binaries to identify the hardware (dmidecode etc.)
> * Koan client
> * Func client
> * Utilities to create vendor RAID arrays and firmware updates
> * Utilities to configure BMC if still in vanilla state (IPMI tools / Hponcfg).
> * Fancy perl module used as a Cisco CDP querier
> 2. The image finds the server model, firmware, serial number and all possible NIC
details
> 3. Cobbler-register creates the server's system entry using the server model and
serial number since we have no idea of its hostname right now.
> 4. Func connects to its master and wait for commands.
>
> >From the func master being also the cobbler server, I know which servers are
ready to be kickstarted and can rename/assign their profiles easier, translating serial
numbers into hostnames. I can also push firmware updates, create RAID arrays and perform
some inventory tasks.
>
> All is left is trigger a remote koan --replace-self with func to fire the install.
b.t.w... I really like the hidden --kexec switch :-)
>
> Do you think I'm going a too complicated way or does this make sense to some of
you ? I remember Michael had some thoughts about extending the auto-registration
feature to include other fields but I have not seen much interest on the list.
It feels a bit complex to me, but everything you have listed there seem
doable. I would shy away from a 'live' image and go with a default
profile/install. But I tend to shy away from images out of habit.
As for extending the auto-registration feature to have other fields. It
is basically only limited by the information that cobbler can store. I
thought about expanding the comment field to be able to take complex
data structures (aka a python dict), but I've not really had any need
for it. I'm definitely willing to do that if people would find use for
it. Perhaps even call it something else and leave the comment field
alone.
JFN: I.m.h.o. auto-registration could fill all valid system fields... the first that
comes to me is the BMC settings that can easily be found locally using IPMI or vendor
tools. Serial number / UUID (virt) would be nice too.
The problem is that the fields change on a vendor basis and depend on
what the user wants to collect. I could definitely see us putting
together a framework for storing arbitrary data inside of cobbler
though. But this would be a 2.1 feature, not something that would be
added to the current stable release (2.0).
--
Scott Henson
Red Hat CIS Operator
WVU Alum BSAE/BSME
4887
days inactive
4890
days old
cobbler@lists.fedorahosted.org
3 comments
2 participants
participants (2)
-
Jean-Francois Nadeau -
Scott Henson