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-29-2008, 09:25 PM
Pablo Iranzo G髆ez
 
Default Cobbler patch OMAPI v2 ;)

Hi all

Attached is a second patch which joins previous two patches and
adds another feature:

Parses /var/lib/dhcpd/dhpcd.leases and removes any "host" entry
using OMAPI as previous step to write the new ones, this is done to
ensure that hosts renamed, deleted or previous ones, still exist at
leases, that is... resets the state to cobbler known hosts.

Comments are still welcome

Regards!
Pablo

PD: Thist patch will get into ticket as previous


--
Pablo Iranzo G髆ez
(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醎___________________________________________ ___
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-30-2008, 02:27 AM
Michael DeHaan
 
Default Cobbler patch OMAPI v2 ;)

Pablo Iranzo G髆ez wrote:

Hi all

Attached is a second patch which joins previous two patches and
adds another feature:

Parses /var/lib/dhcpd/dhpcd.leases and removes any "host" entry
using OMAPI as previous step to write the new ones, this is done to
ensure that hosts renamed, deleted or previous ones, still exist at
leases, that is... resets the state to cobbler known hosts.

Comments are still welcome

Regards!
Pablo

PD: Thist patch will get into ticket as previous



------------------------------------------------------------------------


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


Should be applied Thursday or so barring any other comments, and that
will make this easier for people to test. I also need to do a test
release for 0.9 soon (let's call this 0.9.1 ... there will be more test
releases with some other features likely being added prior to the 1.0).


Quick question -- Should omapi in settings be off by default? It only
works with modifications to the dhcp.template to enable it -- though we
/could/ enable that by default in the template and solve the problem.


Comments from folks who use Cobbler for DHCP management?

The main goal of this is to keep DHCP running throughout sync operations
-- but also to allow for less reasons to ever need to do "sync". Since
kickstart generation is now dynamic in 0.9/1.0, the only real reason to
run sync is to rebuild some of the tftpboot tree, the rest of the
"partial" data gets built each time you make a change to the associated
objects (and all descendents automatically update).

We can probably even make that less important as time goes on, by
knowing basic things like if we add a profile, we can also quickly
rebuild the pxemenus (since the number of profiles is going to be very
small, etc).


--Michael



_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-30-2008, 06:37 AM
Pablo Iranzo G贸mez
 
Default Cobbler patch OMAPI v2 ;)

Morning!

El mar, 29-04-2008 a las 22:27 -0400, Michael DeHaan escribi贸:
> Should be applied Thursday or so barring any other comments, and that
> will make this easier for people to test. I also need to do a test
> release for 0.9 soon (let's call this 0.9.1 ... there will be more test
> releases with some other features likely being added prior to the 1.0).

Count with me for the beta-testing


> Quick question -- Should omapi in settings be off by default? It only
> works with modifications to the dhcp.template to enable it -- though we
> /could/ enable that by default in the template and solve the problem.

For me, as cobbler is rewriting dhcp info, should be enabled by
default. This could need another check for the code I submitted
yesterday to check if "manage dhcp is enabled for isc".

For example, in trigger, the code is:

if manage_dhcp_mode == "isc":
if not omapi:
if not omapi_port:
rc = os.system("/sbin/service dhcpd restart")

So, if manage mode is "ISC", and omapi is not enabled nor omapi_port,
then it does a restart.

I don't think that this could hurt anyone if already using Cobbler for
managing DHCP, if not, system will just do the other tasks, but nothing
about DHCP

>
> Comments from folks who use Cobbler for DHCP management?
>
> The main goal of this is to keep DHCP running throughout sync operations
> -- but also to allow for less reasons to ever need to do "sync". Since
> kickstart generation is now dynamic in 0.9/1.0, the only real reason to
> run sync is to rebuild some of the tftpboot tree, the rest of the
> "partial" data gets built each time you make a change to the associated
> objects (and all descendents automatically update).


Well, regarding this, right now I had to put the new stanza for
cleaning leases just in case of machines removal. The best thing will be
to put the code in "cobbler system add" "cobbler system remove" and
"cobbler system rename" in order to just make this calls when needed,
remmoving the need for the "leases-cleanup code", as the systems will
get created on DHCP or removed dinamically.

> We can probably even make that less important as time goes on, by
> knowing basic things like if we add a profile, we can also quickly
> rebuild the pxemenus (since the number of profiles is going to be very
> small, etc).

That would be a good point, in this way, cobbler state could just use
"sync" for forcing a full cobbler files recreation just to be sure,
remove possible problems, as all the other operations would get
inmediate action on system .

Regards
Pablo

PD: Attached patch adds an extra check to the DHCP leases cleanup code
to check if we're doing ISC

--

Pablo Iranzo G贸mez (Pablo.Iranzo@redhat.com)
RHCE/Global Profesional Services Consultant Spain
Phone: +34 645 01 01 49 (CET/CEST)
GnuPG KeyID: 0xFAD3CF0D
---
Direcci贸n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3潞D, 28016 Madrid, Spain
Direcci贸n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, Spain
Inscrita en el Reg. Mercantil de Madrid 鈥 C.I.F. B82657941
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 05-02-2008, 04:00 PM
Michael DeHaan
 
Default Cobbler patch OMAPI v2 ;)

Pablo Iranzo G髆ez wrote:

Morning!

El mar, 29-04-2008 a las 22:27 -0400, Michael DeHaan escribi:



Applied to devel branch. As with John's patch, I'm going to be
working on moving this around

into the 'modules' directory, though this is very good to see. Thanks!

--Michael

Should be applied Thursday or so barring any other comments, and that
will make this easier for people to test. I also need to do a test
release for 0.9 soon (let's call this 0.9.1 ... there will be more test
releases with some other features likely being added prior to the 1.0).



Count with me for the beta-testing



Quick question -- Should omapi in settings be off by default? It only
works with modifications to the dhcp.template to enable it -- though we
/could/ enable that by default in the template and solve the problem.



For me, as cobbler is rewriting dhcp info, should be enabled by
default. This could need another check for the code I submitted
yesterday to check if "manage dhcp is enabled for isc".

For example, in trigger, the code is:

if manage_dhcp_mode == "isc":
if not omapi:
if not omapi_port:
rc = os.system("/sbin/service dhcpd restart")

So, if manage mode is "ISC", and omapi is not enabled nor omapi_port,
then it does a restart.


I don't think that this could hurt anyone if already using Cobbler for
managing DHCP, if not, system will just do the other tasks, but nothing
about DHCP



Comments from folks who use Cobbler for DHCP management?

The main goal of this is to keep DHCP running throughout sync operations
-- but also to allow for less reasons to ever need to do "sync". Since
kickstart generation is now dynamic in 0.9/1.0, the only real reason to
run sync is to rebuild some of the tftpboot tree, the rest of the
"partial" data gets built each time you make a change to the associated
objects (and all descendents automatically update).




Well, regarding this, right now I had to put the new stanza for
cleaning leases just in case of machines removal. The best thing will be
to put the code in "cobbler system add" "cobbler system remove" and
"cobbler system rename" in order to just make this calls when needed,
remmoving the need for the "leases-cleanup code", as the systems will
get created on DHCP or removed dinamically.


We can probably even make that less important as time goes on, by
knowing basic things like if we add a profile, we can also quickly
rebuild the pxemenus (since the number of profiles is going to be very
small, etc).



That would be a good point, in this way, cobbler state could just use
"sync" for forcing a full cobbler files recreation just to be sure,
remove possible problems, as all the other operations would get
inmediate action on system .

Regards
Pablo

PD: Attached patch adds an extra check to the DHCP leases cleanup code
to check if we're doing ISC


------------------------------------------------------------------------


_______________________________________________
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
 

Thread Tools




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

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