FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora/Linux Management Tools

 
 
LinkBack Thread Tools
 
Old 04-18-2008, 04:22 PM
Michael DeHaan
 
Default Cobbler, findks.cgi, registration, and so forth

Hi folks,

So earlier I wrote about some ideas around automatically registering
systems when Cobbler sees them, and I wrote up some example scripts for
usage by the FreeLinuxPC guys. To me, this seems pretty compelling as
you wouldn't have to manually build up a list of every MAC address in
your data center and so on.
It turns out some of the mac data I was relying on isn't present, so
this didn't work as well as I thought it did -- but -- good news -- I
can fix it.


So since I need to fix this, and wanted to bounce some ideas off
everyone and find out if this would be useful or not. It seems useful
to me anyway, at least as a configuration option.


The idea -- all kickstart requests through cobbler will now go through a
cgi (or more likely, a new mod python piece for performance reasons)
that will serve up the kickstart file for all cobbler-hosted kickstart
files. Then, we have the configuration ability to automatically add
new system objects (correctly configured to the proper profile) when
they get installed. Since we are also doing this via a web script, we
can also decide to re-evaluate the templates at runtime, effectively
eliminating the need for "cobbler sync" for anything but regenerating
DNS/DHCP.


For an example of the registration case -- if you tftpboot 500 new
systems ("straight off the truck"), and you use the PXE menu to assign
some to "webservers" and some to "dbservers", this reorganization of how
we do things would allow us to auto-create system records, correctly
assigned to the profile they were assigned to, with the MAC data already
filled in.


For security reasons, this would only add new system records if the
objects were not already there. Due to various catch-22's, if you add
a new system this way, and then reinstall it using the PXE menus, we
can't have it update the profile associations in cobbler. However --
you wouldn't need to do this, because you could do something as simple as:


cobbler system edit --name=foo --newprofile=bar --netboot-enabled=1
(and cycle power)

in order to do reinstalls.

This seems to be a nice solution for logging the profiles and mac info
at first install time and saves some data entry. (and yes, we'll have a
setting to turn this off).


Thoughts on this and on install time template evaluation?

--Michael

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-18-2008, 04:27 PM
Michael DeHaan
 
Default Cobbler, findks.cgi, registration, and so forth

Michael DeHaan wrote:


Hi folks,

So earlier I wrote about some ideas around automatically registering
systems when Cobbler sees them, and I wrote up some example scripts
for usage by the FreeLinuxPC guys. To me, this seems pretty
compelling as you wouldn't have to manually build up a list of every
MAC address in your data center and so on.
It turns out some of the mac data I was relying on isn't present, so
this didn't work as well as I thought it did -- but -- good news -- I
can fix it.


So since I need to fix this, and wanted to bounce some ideas off
everyone and find out if this would be useful or not. It seems useful
to me anyway, at least as a configuration option.


The idea -- all kickstart requests through cobbler will now go through
a cgi (or more likely, a new mod python piece for performance reasons)
that will serve up the kickstart file for all cobbler-hosted kickstart
files. Then, we have the configuration ability to automatically add
new system objects (correctly configured to the proper profile) when
they get installed. Since we are also doing this via a web script,
we can also decide to re-evaluate the templates at runtime,
effectively eliminating the need for "cobbler sync" for anything but
regenerating DNS/DHCP.


For an example of the registration case -- if you tftpboot 500 new
systems ("straight off the truck"), and you use the PXE menu to assign
some to "webservers" and some to "dbservers", this reorganization of
how we do things would allow us to auto-create system records,
correctly assigned to the profile they were assigned to, with the MAC
data already filled in.


For security reasons, this would only add new system records if the
objects were not already there. Due to various catch-22's, if you
add a new system this way, and then reinstall it using the PXE menus,
we can't have it update the profile associations in cobbler. However
-- you wouldn't need to do this, because you could do something as
simple as:


cobbler system edit --name=foo --newprofile=bar --netboot-enabled=1
(and cycle power)

in order to do reinstalls.

This seems to be a nice solution for logging the profiles and mac info
at first install time and saves some data entry. (and yes, we'll have
a setting to turn this off).


Thoughts on this and on install time template evaluation?

--Michael



Minor clarification -- if anyone is familiar with findks.cgi, this is
somewhat different. This would be more like
"http://$server/cobbler/getks?profile=foo", though Anaconda takes care
of feeding the mac (and the IP) info to the script/program. We would
want to log the mac, but I'm unsure if we want to store the IP... as
that would instantly turn a regular DHCP ip into a DHCP reservation if
using the mangage_dhcp feature. I kind of like that idea though, but
wanted to bounce that off people who were using Cobbler to manage DHCP
-- as that may not fit workflows.


In terms of settings, it looks like we're going to have

auto_register_new_systems y/n
(and possibly) auto_register_ip_info y/n

(We could possibly also expand koan to use more of this data to help
prevent virtual MAC collisions when installing with --profile records
and not --system records, provided we make a remote XMLRPC call to
retrieve a free MAC address)





_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-18-2008, 07:32 PM
Peter Wright
 
Default Cobbler, findks.cgi, registration, and so forth

Michael DeHaan wrote:


Hi folks,


<snip>


The idea -- all kickstart requests through cobbler will now go through
a cgi (or more likely, a new mod python piece for performance reasons)
that will serve up the kickstart file for all cobbler-hosted kickstart
files. Then, we have the configuration ability to automatically add
new system objects (correctly configured to the proper profile) when
they get installed. Since we are also doing this via a web script,
we can also decide to re-evaluate the templates at runtime,
effectively eliminating the need for "cobbler sync" for anything but
regenerating DNS/DHCP.


For an example of the registration case -- if you tftpboot 500 new
systems ("straight off the truck"), and you use the PXE menu to assign
some to "webservers" and some to "dbservers", this reorganization of
how we do things would allow us to auto-create system records,
correctly assigned to the profile they were assigned to, with the MAC
data already filled in.


this would be very helpful indeed.

although i suspect having to manually select your install via a menu can
get painful when lighting up a bunch of blade systems - if i read this
correctly.

we've been kicking around the idea of polling MAC addresses from our
edge switches then having some glue code enter those addy's into cobbler
and assign them a specific profile (we usually find ourselves putting
all of our render nodes for example on their own edge switch so we don't
have to worry about mixed use profiles in the use case).


don't get me wrong though - auto-reg would be huge

-p

--
Peter Wright
Systems Engineer
Sony Pictures Imageworks
wright@imageworks.com
www.imageworks.com

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-18-2008, 10:55 PM
Michael DeHaan
 
Default Cobbler, findks.cgi, registration, and so forth

this would be very helpful indeed.
although i suspect having to manually select your install via a menu
can get painful when lighting up a bunch of blade systems - if i read
this correctly.
we've been kicking around the idea of polling MAC addresses from our
edge switches then having some glue code enter those addy's into
cobbler and assign them a specific profile (we usually find ourselves
putting all of our render nodes for example on their own edge switch
so we don't have to worry about mixed use profiles in the use case).


don't get me wrong though - auto-reg would be huge



Good deal!

I think you might know about this, but you can also do the following
trick today that makes life a lot easier than using menus:


cobbler system add --name=default --profile=foo
# power up 500 systems
cobbler system add --name=default --profile=bar
# power up another 500

Coupled with auto-registration that could be pretty slick


-p



_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-18-2008, 10:56 PM
Michael DeHaan
 
Default Cobbler, findks.cgi, registration, and so forth

Michael DeHaan wrote:





this would be very helpful indeed.
although i suspect having to manually select your install via a menu
can get painful when lighting up a bunch of blade systems - if i read
this correctly.
we've been kicking around the idea of polling MAC addresses from our
edge switches then having some glue code enter those addy's into
cobbler and assign them a specific profile (we usually find ourselves
putting all of our render nodes for example on their own edge switch
so we don't have to worry about mixed use profiles in the use case).


don't get me wrong though - auto-reg would be huge



Good deal!

I think you might know about this, but you can also do the following
trick today that makes life a lot easier than using menus:


cobbler system add --name=default --profile=foo
# power up 500 systems
cobbler system add --name=default --profile=bar
# power up another 500

Coupled with auto-registration that could be pretty slick


-p






That of course should end with:

cobbler system remove --name=default

Otherwise, it would be rather suprising. When you have the "default"
system record engaged the menus do not fire up.


--Michael


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-19-2008, 06:30 PM
Pablo Iranzo Gómez
 
Default Cobbler, findks.cgi, registration, and so forth

Hi
This auto-registration feature seems not to work if using koan to
replace a machine, as it relies on MAC and:

koan -r downloads the file using wget to store it, so no mac info
sent, machine would be correctly deployed, but no ks request will be made
by anaconda, so no autoregistration.

wget in kickstart profile, also, doesn't send mac, so this will
not register the machine.

Solution:

¿Make Koan to always use http://cobblerserver as the ks path
instead of downloading to disk?

Regards
Pablo

PD: I like this idea of auto-registration





--
Pablo Iranzo Gómez
(http://Alufis35.uv.es/~iranzo/)
(PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp)
--
Postulado de Boling sobre la Ley de Murphy:

Si se encuentra bien, no se preocupe. Se le pasará

On Fri, 18 Apr 2008, Michael DeHaan wrote:

> Michael DeHaan wrote:
> >
> >>>
> >> this would be very helpful indeed.
> >> although i suspect having to manually select your install via a menu
> >> can get painful when lighting up a bunch of blade systems - if i read
> >> this correctly.
> >> we've been kicking around the idea of polling MAC addresses from our
> >> edge switches then having some glue code enter those addy's into
> >> cobbler and assign them a specific profile (we usually find ourselves
> >> putting all of our render nodes for example on their own edge switch
> >> so we don't have to worry about mixed use profiles in the use case).
> >>
> >> don't get me wrong though - auto-reg would be huge
> >>
> >
> > Good deal!
> >
> > I think you might know about this, but you can also do the following
> > trick today that makes life a lot easier than using menus:
> >
> > cobbler system add --name=default --profile=foo
> > # power up 500 systems
> > cobbler system add --name=default --profile=bar
> > # power up another 500
> >
> > Coupled with auto-registration that could be pretty slick
> >
> >> -p
> >>
> >
> >
>
> That of course should end with:
>
> cobbler system remove --name=default
>
> Otherwise, it would be rather suprising. When you have the "default"
> system record engaged the menus do not fire up.
>
> --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
 
Old 04-19-2008, 08:39 PM
Pablo Iranzo Gómez
 
Default Cobbler, findks.cgi, registration, and so forth

Just a question,

I've seen (using PHP) that the kssendmac, provides a parameter
named "X-RHN-PROVISIONING-MAC-0" with "-" instead of "_" is this ok for
the code in services.py? (scripts/services.py shows
"HTTP_X_RHN_PROVISIONING_MAC_0")

Also found that it requires profile to be defined, but I haven't
found the code for that in the apache handler.

But, for now, I can't make it to autoregister

Regards!
Pablo



--
Pablo Iranzo Gómez
(http://Alufis35.uv.es/~iranzo/)
(PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp)
--
Postulado de Boling sobre la Ley de Murphy:

Si se encuentra bien, no se preocupe. Se le pasará

On Sat, 19 Apr 2008, Pablo Iranzo Gómez wrote:

> Hi
> This auto-registration feature seems not to work if using koan to
> replace a machine, as it relies on MAC and:
>
> koan -r downloads the file using wget to store it, so no mac info
> sent, machine would be correctly deployed, but no ks request will be made
> by anaconda, so no autoregistration.
>
> wget in kickstart profile, also, doesn't send mac, so this will
> not register the machine.
>
> Solution:
>
> ¿Make Koan to always use http://cobblerserver as the ks path
> instead of downloading to disk?
>
> Regards
> Pablo
>
> PD: I like this idea of auto-registration
>
>
>
>
>
> --
> Pablo Iranzo Gómez
> (http://Alufis35.uv.es/~iranzo/)
> (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp)
> --
> Postulado de Boling sobre la Ley de Murphy:
>
> Si se encuentra bien, no se preocupe. Se le pasará
>
> On Fri, 18 Apr 2008, Michael DeHaan wrote:
>
> > Michael DeHaan wrote:
> > >
> > >>>
> > >> this would be very helpful indeed.
> > >> although i suspect having to manually select your install via a menu
> > >> can get painful when lighting up a bunch of blade systems - if i read
> > >> this correctly.
> > >> we've been kicking around the idea of polling MAC addresses from our
> > >> edge switches then having some glue code enter those addy's into
> > >> cobbler and assign them a specific profile (we usually find ourselves
> > >> putting all of our render nodes for example on their own edge switch
> > >> so we don't have to worry about mixed use profiles in the use case).
> > >>
> > >> don't get me wrong though - auto-reg would be huge
> > >>
> > >
> > > Good deal!
> > >
> > > I think you might know about this, but you can also do the following
> > > trick today that makes life a lot easier than using menus:
> > >
> > > cobbler system add --name=default --profile=foo
> > > # power up 500 systems
> > > cobbler system add --name=default --profile=bar
> > > # power up another 500
> > >
> > > Coupled with auto-registration that could be pretty slick
> > >
> > >> -p
> > >>
> > >
> > >
> >
> > That of course should end with:
> >
> > cobbler system remove --name=default
> >
> > Otherwise, it would be rather suprising. When you have the "default"
> > system record engaged the menus do not fire up.
> >
> > --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
 
Old 04-21-2008, 09:01 PM
Michael DeHaan
 
Default Cobbler, findks.cgi, registration, and so forth

Pablo Iranzo Gómez wrote:

Hi
This auto-registration feature seems not to work if using koan to
replace a machine, as it relies on MAC and:



Correct, it pre-downloads the kickstart. This was why I mentioned
possibly having an option not to embed the kickstart
earlier, though /that/ wouldn't work if you rely on koan embedding the
kickstart for DHCP reasons.



koan -r downloads the file using wget to store it, so no mac info
sent, machine would be correctly deployed, but no ks request will be made
by anaconda, so no autoregistration.

wget in kickstart profile, also, doesn't send mac, so this will
not register the machine.

Indeed. It needs to make that request on the kernel options line so
Anaconda adds that info.
As I mentioned earlier today, this is all in progress, stay tuned and
check back around Wednesday



_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 

Thread Tools




All times are GMT. The time now is 05:02 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org