10:24 a.m.
What's the best method to define site specific settings? I basically have multiple
Cobbler servers setup at various physical locations and each of these locations have
different DNS, NTP, Timezones, etc. For DNS it appears I could use the
"name_servers" option in the settings file, but that would be the only one.
At first I thought I could maintain a separate snippet to define the options for each
location, but I do a full sync off of my master server would overwrite the said file. I
want to try and keep from touching the kickstart on each server anytime I do an update on
the master server. Perhaps something in cheetah_macros? This file is blank so I don't
have an example to use here, or even knowledge of what is capable with it.
I can do this via scripting, just thought there may be an easier way to just
"define" them so to speak ;-)
glenn - terremark
2:55 a.m.
On Mon, Jan 18, 2010 at 11:24:18AM -0500, Glenn Bailey wrote:
What's the best method to define site specific settings? I
basically
have multiple Cobbler servers setup at various physical locations
and each of these locations have different DNS, NTP, Timezones, etc.
For DNS it appears I could use the "name_servers" option in the
settings file, but that would be the only one.
Also cobbler-slaves in several locations here.
The different settings (i.e. what ldap-servers are to be used for
user-auth on the newly deployed server) are currently handed over
by the deploying admin using ksmeta-vars.
Cobbler evaluates those and creates the configfiles to be deployed
accordingly.
Currently these location-vars are stuffed into each new
'cobbler system'-object on the cobbler-slaves. This should work
better thou in setting the proper site-specific ksmeta-vars in the
profiles on the cobbler-slaves and have the cobbler-systems below
their profiles inheriting the site-specific ksmeta.
Here the data will at some point come from an ldap where also in-
herittance will happen.
Christian
10:37 a.m.
On Mon, Jan 18, 2010 at 11:24:18AM -0500, Glenn Bailey wrote:
> What's the best method to define site specific settings? I basically
> have multiple Cobbler servers setup at various physical locations
> and each of these locations have different DNS, NTP, Timezones, etc.
> For DNS it appears I could use the "name_servers" option in the
> settings file, but that would be the only one.
Also cobbler-slaves in several locations here.
The different settings (i.e. what ldap-servers are to be used for
user-auth on the newly deployed server) are currently handed over
by the deploying admin using ksmeta-vars.
So for each distro profile you create another distro locally that's a
slave for each distro? Seems a little cumbersome .. :-( I'm trying to
keep each distro location agnostic. It seems I would also have to make
a new name for each profile in each location as not to have them over
written when a sync happens, is this the case? I'm wanting to have a build
from a PXE menu look the same from each location as not to confuse data
center folks ..
Goes back to my original question, is there another method to do it
without creating separate slave profiles? I haven't seen any examples
for cheetah_macro's or even if this would be a good place.
11:19 a.m.
On Wed, Jan 20, 2010 at 11:37:34AM -0500, Glenn Bailey wrote:
> On Mon, Jan 18, 2010 at 11:24:18AM -0500, Glenn Bailey wrote:
> > What's the best method to define site specific settings? I basically
> > have multiple Cobbler servers setup at various physical locations
> > and each of these locations have different DNS, NTP, Timezones, etc.
> > For DNS it appears I could use the "name_servers" option in the
> > settings file, but that would be the only one.
>
> Also cobbler-slaves in several locations here.
> The different settings (i.e. what ldap-servers are to be used for
> user-auth on the newly deployed server) are currently handed over
> by the deploying admin using ksmeta-vars.
So for each distro profile you create another distro locally that's a
slave for each distro? Seems a little cumbersome .. :-( I'm trying to
keep each distro location agnostic. It seems I would also have to make
a new name for each profile in each location as not to have them over
written when a sync happens, is this the case?
Over here we do not use cobblers sync-features. Instead all distros
directories are offered to the cobbler-slaves via rsync and can selec-
tively be fetched. Then the directory is manually made known to the
cobbler-slave as distro/profile/repo in pasting some cobbler-commands
out of a wiki into the slaves terminal. One could then also in these
commands source a text-file on that slave that contains some slave-
specific ksmetas. Should also work that everything including the
profiles gets synced to the slaves and just then a local-only profile
is copied from the provided one, additionally setting ksmeta from the
textfile.
Goes back to my original question, is there another method to do it
without creating separate slave profiles? I haven't seen any examples
for cheetah_macro's or even if this would be a good place.
Or ksmeta to be fetched dynamically from the harddisc.. maybe hooks
can help you.
Christian
11:32 a.m.
You might want to consider using a configuration management tool like Puppet
to achieve this. It's a fairly common use case.
On 1/20/10 11:19 AM, "Christian Horn" <chorn(a)fluxcoil.net> wrote:
On Wed, Jan 20, 2010 at 11:37:34AM -0500, Glenn Bailey wrote:
>> On Mon, Jan 18, 2010 at 11:24:18AM -0500, Glenn Bailey wrote:
>>> What's the best method to define site specific settings? I basically
>>> have multiple Cobbler servers setup at various physical locations
>>> and each of these locations have different DNS, NTP, Timezones, etc.
>>> For DNS it appears I could use the "name_servers" option in the
>>> settings file, but that would be the only one.
>>
>> Also cobbler-slaves in several locations here.
>> The different settings (i.e. what ldap-servers are to be used for
>> user-auth on the newly deployed server) are currently handed over
>> by the deploying admin using ksmeta-vars.
>
> So for each distro profile you create another distro locally that's a
> slave for each distro? Seems a little cumbersome .. :-( I'm trying to
> keep each distro location agnostic. It seems I would also have to make
> a new name for each profile in each location as not to have them over
> written when a sync happens, is this the case?
Over here we do not use cobblers sync-features. Instead all distros
directories are offered to the cobbler-slaves via rsync and can selec-
tively be fetched. Then the directory is manually made known to the
cobbler-slave as distro/profile/repo in pasting some cobbler-commands
out of a wiki into the slaves terminal. One could then also in these
commands source a text-file on that slave that contains some slave-
specific ksmetas. Should also work that everything including the
profiles gets synced to the slaves and just then a local-only profile
is copied from the provided one, additionally setting ksmeta from the
textfile.
> Goes back to my original question, is there another method to do it
> without creating separate slave profiles? I haven't seen any examples
> for cheetah_macro's or even if this would be a good place.
Or ksmeta to be fetched dynamically from the harddisc.. maybe hooks
can help you.
Christian
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
12:05 p.m.
New subject: Issue with "cobbler sync"
Cobbler Gurus:
We recently installed cobbler_1.6.6 and were able to import distributions but when
we run "cobbler sync" we get " cannot find directory: -c". We are not
sure which directory "-c" is being referenced. If we run "cobbler
check", it tells us to create directory "-c".
Please advice,
Jose Rivera
HP Enterprise Services
8:49 a.m.
New subject: Issue with "cobbler sync"
I would encourage you to move to cobbler 2.x if possible
-- Phil
2010/1/21 Rivera, Jose B (Jose)** CTR ** <jbrivera(a)alcatel-lucent.com>
Cobbler Gurus:
We recently installed cobbler_1.6.6 and were able to import
distributions but when we run "cobbler sync" we get " cannot find
directory: -c". We are not sure which directory "-c" is being referenced.
If
we run "cobbler check", it tells us to create directory "-c".
Please advice,
Jose Rivera
HP Enterprise Services
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
9:31 a.m.
New subject: Issue with "cobbler sync"
Am I missing something here? The latest version of Cobbler I see is 1.6.8.
--- On Fri, 1/22/10, Philippe Eveque <philippe.eveque(a)gmail.com> wrote:
From: Philippe Eveque <philippe.eveque(a)gmail.com>
Subject: Re: Issue with "cobbler sync"
To: "cobbler mailing list" <cobbler(a)lists.fedorahosted.org>
Date: Friday, January 22, 2010, 6:49 AM
I would encourage you to move to cobbler 2.x if possible
-- Phil
2010/1/21 Rivera, Jose B (Jose)** CTR ** <jbrivera(a)alcatel-lucent.com>
Cobbler Gurus:
We recently
installed cobbler_1.6.6 and were able to import distributions but when we run
"cobbler sync" we get " cannot find directory: -c". We are not sure
which
directory "-c" is being referenced. If we run "cobbler
check", it tells us to create directory "-c".
Please advice,
Jose Rivera
HP Enterprise Services
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
-----Inline Attachment Follows-----
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
11:45 a.m.
New subject: Issue with "cobbler sync"
I am not familiar with this at all. How does one get access to this software?
--- On Fri, 1/22/10, Philippe Eveque <philippe.eveque(a)gmail.com> wrote:
From: Philippe Eveque <philippe.eveque(a)gmail.com>
Subject: Re: Issue with "cobbler sync"
To: "cobbler mailing list" <cobbler(a)lists.fedorahosted.org>
Date: Friday, January 22, 2010, 7:51 AM
2.0.2 is in epel-testing for quite a while now.
--Phil.
2010/1/22 brown wrap <gramos(a)yahoo.com>
Am I missing something here? The latest version of Cobbler I see is 1.6.8.
-----Inline Attachment Follows-----
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
12:36 p.m.
New subject: epel-testing software site
I thought I'd change the subject line to get a response. how does one get access to
the epel software? Thanks.
1:02 p.m.
New subject: epel-testing software site
I'm no expert but this is what I've done...
If you are using yum, configure a repo file for fedora's epeltest in /etc/yum.repos.d
as such:
[fedora-epeltest]
name=Red Hat Enterprise Linux $releasever - $basearch - Debug
baseurl=http://download.fedora.redhat.com/pub/epel/testing/5/$basearch
...
...
Then run "yum -enablerepo=fedora-epeltest info cobbler" and you should see it
available.
Regards,
Jos? B. Rivera
________________________________
From: cobbler-bounces(a)lists.fedorahosted.org
[mailto:cobbler-bounces@lists.fedorahosted.org] On Behalf Of brown wrap
Sent: Friday, January 22, 2010 1:37 PM
To: cobbler mailing list
Subject: epel-testing software site
I thought I'd change the subject line to get a response. how does one get access to
the epel software? Thanks.
9:42 a.m.
New subject: Issue with "cobbler sync"
I hope not. Due to all of the unresolved bugs in 2.0.2, we've downgraded to 2.0.1.
Bryan Schneiders
bschneiders(a)woti.com
301-562-1900 ext 305
On 01/22/2010 12:49 PM, mark wrote:
On Fri, Jan 22, 2010 at 10:51 AM, Philippe Eveque
<philippe.eveque(a)gmail.com <mailto:philippe.eveque@gmail.com>> wrote:
2.0.2 is in epel-testing for quite a while now.
--Phil.
Is there a target date for this release to come out of testing yet?
mark
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
1:57 p.m.
So for each distro profile you create another distro locally
that's a
slave for each distro? Seems a little cumbersome .. :-( I'm trying to
keep each distro location agnostic. It seems I would also have to make
a new name for each profile in each location as not to have them over
written when a sync happens, is this the case? I'm wanting to have a
build
from a PXE menu look the same from each location as not to confuse data
center folks ..
Goes back to my original question, is there another method to do it
without creating separate slave profiles? I haven't seen any examples
for cheetah_macro's or even if this would be a good place.
Got it .. in /etc/cobbler/settings I was able to add the following:
mgmt_parameters:
from_cobbler: 1
time_zone: American/Central
Which gives me the option to do this in the kickstart:
timezone $mgmt_parameters['time_zone']
6:42 p.m.
On 01/18/2010 10:24 AM, Glenn Bailey wrote:
At first I thought I could maintain a separate snippet to define the
options
for each location, but I do a full sync off of my master server would
overwrite the said file. I want to try and keep from touching the kickstart
on each server anytime I do an update on the master server. Perhaps something
in cheetah_macros? This file is blank so I don't have an example to use here,
or even knowledge of what is capable with it.
I see you've already come up with another solution, but I solve this issue here
with snippets. Below is my snippet for setting the time zone. I'm not a python
programmer and still get confused by Cheetah, so the regex logic is actually
stolen from another standard Cobbler snippet I think. I pretty much just built
the array and added some ifs.
In my case, we have standardized host names with a site code being the first 3
characters, which I simply evaluate to determine where in the world it is.
Although this snippet actually looks at the Cobbler system name so non-standard
names can still be accommodated by prefixing the system name and leaving the
configured host name correct. My system names typically match my host names. I
don't yet do any synchronization between my Cobbler servers, but this snippet
could be used on any of them as is. And since I don't intend to put Cobbler
servers at all these sites, it's very likely I would need to build a system
destined for a time zone other than the Cobbler server's local time zone.
#import re
#if $getVar("system_name","") != ""
#set $system = $getVar('system_name')
#set $TimeZone = {}
#set $TimeZone['aus'] = 'America/Chicago'
#set $TimeZone['bat'] = 'Asia/Manila'
#set $TimeZone['bgl'] = 'Asia/Kolkata'
#set $TimeZone['cav'] = 'Asia/Manila'
#set $TimeZone['cat'] = 'Europe/Rome'
#set $TimeZone['chb'] = 'Asia/Bangkok'
#set $TimeZone['chd'] = 'America/Phoenix'
#set $TimeZone['chm'] = 'America/New_York'
#set $TimeZone['cos'] = 'America/Denver'
#set $TimeZone['cpn'] = 'America/Chicago'
#set $TimeZone['cri'] = 'America/New_York'
#set $TimeZone['dal'] = 'America/Chicago'
#set $TimeZone['dlf'] = 'Europe/Amsterdam'
#set $TimeZone['drs'] = 'Europe/Berlin'
#set $TimeZone['ftc'] = 'America/Denver'
#set $TimeZone['gdh'] = 'Asia/Kolkata'
#set $TimeZone['grn'] = 'Europe/Paris'
#set $TimeZone['hlb'] = 'America/Los_Angeles'
#set $TimeZone['hrt'] = 'America/Chicago'
#set $TimeZone['irv'] = 'America/Los_Angeles'
#set $TimeZone['ist'] = 'Asia/Istanbul'
#set $TimeZone['kws'] = 'Asia/Toyko'
#set $TimeZone['lac'] = 'Europe/Paris'
#set $TimeZone['lee'] = 'America/New_York'
#set $TimeZone['mbf'] = 'America/New_York'
#set $TimeZone['mfn'] = 'America/Los_Angeles'
#set $TimeZone['nwb'] = 'Europe/London'
#set $TimeZone['pav'] = 'Europe/Rome'
#set $TimeZone['rlh'] = 'America/New_York'
#set $TimeZone['roz'] = 'Europe/Rome'
#set $TimeZone['shg'] = 'Asia/Shanghai'
#set $TimeZone['sjc'] = 'America/Los_Angeles'
#set $TimeZone['ssk'] = 'Asia/Seoul'
#set $TimeZone['svl'] = 'America/Los_Angeles'
#set $TimeZone['tai'] = 'Asia/Taipei'
#set $TimeZone['ups'] = 'Europe/Vienna'
#set $TimeZone['wst'] = 'America/Indiana/Indianapolis'
#set $site = re.match('^.{3}', $system.lower()).group()
#if $site in $TimeZone
# Site: $site
#set $localTZ = $TimeZone[$site]
timezone --utc $localTZ
#else
# Site: Can't match $site
timezone --utc
#end if
#else
# Site Unknown
timezone --utc
#end if
--
/* Wes Hardin */
5227
days inactive
5234
days old
cobbler@lists.fedorahosted.org
16 comments
10 participants
participants (10)
-
brown wrap -
Bryan Schneiders -
Christian Horn -
Glenn Bailey -
Maarten Coenaerts -
mark -
Phil Gardner -
Philippe Eveque -
Rivera, Jose B (Jose)** CTR ** -
Wes Hardin