Hi there
In common with many of you, we run various types of server
(webservers, mail gateways, etc) in several datacentres. I can''t work
out a clean way to configure location-specific variables in otherwise
identically-configured servers. These location-dependent settings are
used in many modules: e.g., the HTTP proxy name is needed by yum,
Apache, Squid, etc.
At the moment I''m using a pretty clumsy-feeling set of custom facts. I
have a $location fact that determines the location from $domain and
then installs a specific /etc/facts.txt file containing the location-
specific settings, which are turned into Facter variables using
another custom fact. This sort of works, but it''s not ideal: what if
the domain name doesn''t match the location? It also falls flat on its
face during the bootstrap run; I need to configure yum to use a proxy
in the first instance, but I don''t know the proxy name until
I''ve run
Puppet once to fact sync and then a second time to use the facts. It
all feels very brittle.
I could set global variables in the node definitions:
node "web1.london.my.domain" {
include apache
include sendmail
$httpproxy = "http-proxy.london.my.domain"
$dnsservers = ["10.1.1.1", "10.1.1.2"]
}
node "web1.ny.my.domain" {
include apache
include sendmail
$httpproxy = "http-proxy.ny.my.domain"
$dnsservers = ["10.2.2.1", "10.2.2.2"]
}
This doesn''t seem very Puppety to me. I''d prefer:
node "web1.london.my.domain" {
include apache
include sendmail
include location::london
}
node "web1.ny.my.domain" {
include apache
include sendmail
include location::ny
}
Where the appropriate location class somehow informs other classes
that need to make changes based on the node''s location. Obviously
setting variables inside location will scope them to location, where
apache:: and friends can''t see them. And I don''t particularly
like
setting a slew of global variables for every node (yeah, LDAP or
external nodes would help; they''re on the todo list) -- it''s
not very
DRY.
So, how''re you coping with this?
Cheers,
Mark
PS I know, I should configure my HTTP proxy name to be http-proxy.
$datacentre.my.domain so "http_proxy=http-proxy" works in all
locations. I''m heading that way, but it''s not a lot more
flexible and
some services (DNS resolvers) have to be listed by IP anyway.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
I solve similar problem using the parameter option in external nodes. cheers, Ohad On Thu, Nov 13, 2008 at 7:47 PM, Mark Drayton <mdrayton@gmail.com> wrote:> > Hi there > > In common with many of you, we run various types of server > (webservers, mail gateways, etc) in several datacentres. I can''t work > out a clean way to configure location-specific variables in otherwise > identically-configured servers. These location-dependent settings are > used in many modules: e.g., the HTTP proxy name is needed by yum, > Apache, Squid, etc. > > At the moment I''m using a pretty clumsy-feeling set of custom facts. I > have a $location fact that determines the location from $domain and > then installs a specific /etc/facts.txt file containing the location- > specific settings, which are turned into Facter variables using > another custom fact. This sort of works, but it''s not ideal: what if > the domain name doesn''t match the location? It also falls flat on its > face during the bootstrap run; I need to configure yum to use a proxy > in the first instance, but I don''t know the proxy name until I''ve run > Puppet once to fact sync and then a second time to use the facts. It > all feels very brittle. > > I could set global variables in the node definitions: > > node "web1.london.my.domain" { > include apache > include sendmail > $httpproxy = "http-proxy.london.my.domain" > $dnsservers = ["10.1.1.1", "10.1.1.2"] > } > > node "web1.ny.my.domain" { > include apache > include sendmail > $httpproxy = "http-proxy.ny.my.domain" > $dnsservers = ["10.2.2.1", "10.2.2.2"] > } > > This doesn''t seem very Puppety to me. I''d prefer: > > node "web1.london.my.domain" { > include apache > include sendmail > include location::london > } > > node "web1.ny.my.domain" { > include apache > include sendmail > include location::ny > } > > Where the appropriate location class somehow informs other classes > that need to make changes based on the node''s location. Obviously > setting variables inside location will scope them to location, where > apache:: and friends can''t see them. And I don''t particularly like > setting a slew of global variables for every node (yeah, LDAP or > external nodes would help; they''re on the todo list) -- it''s not very > DRY. > > So, how''re you coping with this? > > Cheers, > > Mark > > PS I know, I should configure my HTTP proxy name to be http-proxy. > $datacentre.my.domain so "http_proxy=http-proxy" works in all > locations. I''m heading that way, but it''s not a lot more flexible and > some services (DNS resolvers) have to be listed by IP anyway. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Andrew Shafer
2008-Nov-13 16:20 UTC
[Puppet Users] Re: Setting location-specific variables
+1 for external nodes This allows you to dynamically add variables to the classes when they are evaluated. On Thu, Nov 13, 2008 at 8:02 AM, Ohad Levy <ohadlevy@gmail.com> wrote:> I solve similar problem using the parameter option in external nodes. > > cheers, > Ohad > > > On Thu, Nov 13, 2008 at 7:47 PM, Mark Drayton <mdrayton@gmail.com> wrote: > >> >> Hi there >> >> In common with many of you, we run various types of server >> (webservers, mail gateways, etc) in several datacentres. I can''t work >> out a clean way to configure location-specific variables in otherwise >> identically-configured servers. These location-dependent settings are >> used in many modules: e.g., the HTTP proxy name is needed by yum, >> Apache, Squid, etc. >> >> At the moment I''m using a pretty clumsy-feeling set of custom facts. I >> have a $location fact that determines the location from $domain and >> then installs a specific /etc/facts.txt file containing the location- >> specific settings, which are turned into Facter variables using >> another custom fact. This sort of works, but it''s not ideal: what if >> the domain name doesn''t match the location? It also falls flat on its >> face during the bootstrap run; I need to configure yum to use a proxy >> in the first instance, but I don''t know the proxy name until I''ve run >> Puppet once to fact sync and then a second time to use the facts. It >> all feels very brittle. >> >> I could set global variables in the node definitions: >> >> node "web1.london.my.domain" { >> include apache >> include sendmail >> $httpproxy = "http-proxy.london.my.domain" >> $dnsservers = ["10.1.1.1", "10.1.1.2"] >> } >> >> node "web1.ny.my.domain" { >> include apache >> include sendmail >> $httpproxy = "http-proxy.ny.my.domain" >> $dnsservers = ["10.2.2.1", "10.2.2.2"] >> } >> >> This doesn''t seem very Puppety to me. I''d prefer: >> >> node "web1.london.my.domain" { >> include apache >> include sendmail >> include location::london >> } >> >> node "web1.ny.my.domain" { >> include apache >> include sendmail >> include location::ny >> } >> >> Where the appropriate location class somehow informs other classes >> that need to make changes based on the node''s location. Obviously >> setting variables inside location will scope them to location, where >> apache:: and friends can''t see them. And I don''t particularly like >> setting a slew of global variables for every node (yeah, LDAP or >> external nodes would help; they''re on the todo list) -- it''s not very >> DRY. >> >> So, how''re you coping with this? >> >> Cheers, >> >> Mark >> >> PS I know, I should configure my HTTP proxy name to be http-proxy. >> $datacentre.my.domain so "http_proxy=http-proxy" works in all >> locations. I''m heading that way, but it''s not a lot more flexible and >> some services (DNS resolvers) have to be listed by IP anyway. >> >> >> > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
2008/11/13 Mark Drayton <mdrayton@gmail.com>> At the moment I''m using a pretty clumsy-feeling set of custom facts. I > have a $location fact that determines the location from $domain and > then installs a specific /etc/facts.txt file containing the location- > specific settings, which are turned into Facter variables using > another custom fact. This sort of works, but it''s not ideal: what if > the domain name doesn''t match the location? It also falls flat on its > face during the bootstrap run; I need to configure yum to use a proxy > in the first instance, but I don''t know the proxy name until I''ve run > Puppet once to fact sync and then a second time to use the facts. It > all feels very brittle.You could write yourself a custom function that returns the location as a variable. Also, for your bootstrap process you might run puppet multiple times with different sets of tags - I''ve done this in the past to avoid having to have every package dependant on the class that setups of packagemanagment.> I could set global variables in the node definitions: > [... ] > > This doesn''t seem very Puppety to me. >Ya no, you don''t really want to do that...> So, how''re you coping with this? > > Cheers, > > Mark > > PS I know, I should configure my HTTP proxy name to be http-proxy. > $datacentre.my.domain so "http_proxy=http-proxy" works in all > locations. I''m heading that way, but it''s not a lot more flexible and > some services (DNS resolvers) have to be listed by IP anyway. >You could just setup everything like <servicename>.$datacentre.my.domain, and handle the DNS exception by pointing your initial bootstrap''ed DNS servers at your DNS authority (which is probably already reachable from everywhere). Once puppet figures out where it is it can replace /etc/resolv.conf with the local resolvers. .r'' --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---