On Friday, March 16, 2012 1:36:23 PM UTC-4, Tim Mooney wrote:
>
> In regard to: [Puppet Users] Need advice how to architect solution for...:
>
> > I'm having difficulty determining the best course of action how to
> > implement /etc/resolv.conf on my RHEL5 hosts.
> >
> > Here's my requirements, IN ORDER OF PRECEDENCE:
> >
> > * All hosts, regardless of function, need /etc/resolv.conf
> > * Dependiing upon which environment the host lives in (i.e. Facture
> > $domain) this changes search paths and nameservers to use in
> > /etc/resolv.conf
> > * Any host defined as a 'DNS Server' should ignore environment specific
> > settings and use nameserver of '127.0.0.1'
> > * There are one or two one-off DNS servers that should have their own
> > per-host settings which shall override all previous definitions.
>
> We're doing something like this, although I need to expand it to be a
> little bit smarter, but wouldn't setting something like
>
> ---
> named_type: client # or 'caching', 'secondary', 'primary'
>
> in your extdata/hiera/ENC and then using a selector in your class to pick
> which template to use for resolv.conf essentially solve all of this?
>
> > The only things that need to change between these rules are the values of
> > the search path and the list of nameservers. So I would like to use a
> > single template for /etc/resolv.conf which simply plug in data available
> in
> > variables accessible by the template
>
> You probably could do that, but I think the template will be more
> complicated this way. Selecting different templates based on what type
> of system it is makes the template simpler.
>
> Tim
>
This template, resolv.conf.erb, which belongs to my 'resolv' class should
all that I ever need.
<% searchpaths.each do |searchpath| -%>
search <%= searchpath %>
<% end -%>
<% nameservers.each do |nameserver| -%>
nameserver <%= nameserver %>
<% end -%>
Duplicating such a template would be an example of un-necessary code reuse.
The determination of what values to pass to my 'resolv' class has to be
done before I declare (or is it define, I'm still confused on terminology)
the class.
How do I do that?
Here's my site.pp file:
# BEGIN SITE.PP
node basenode {
# ----------------------------------------------------------------
# Define per-environment settings
# Eventually this will become hiera lookups or something
# ----------------------------------------------------------------
case $domain {
# Dev/test
'test.example.com' : {
$nameservers = [ 1.1.1.1, 2.2.2.2, 3.3.3.3 ]
}
# Staging
'stage.example.com' : {
$nameservers = [ 4.4.4.4, 5.5.5.5 ]
}
# Production
'example.com' : {
$nameservers = [ 6.6.6.6, 7.7.7.7]
}
}
# ----------------------------------------------------------------
# All 'standard' modules/classes to be applied to all hosts.
# ----------------------------------------------------------------
class { 'basefiles': }
class { 'ntp' : servers => $ntpservers }
class { 'puppet' : puppetserver => $puppetserver }
class { 'resolv' : nameservers => $nameservers, searchpaths =>
$searchpaths }
}
# first match wins, so I list them specific to generic
node /dns-test.test.example.com/ inherits basenode {
# This host should have host specific settings for resolv.conf
independent of all other hosts.
}
node /dns.*example.com/ inherits basenode {
# I should - somehow - be able to overload my nameserver settings here
for ALL my DNS servers
}
node /.*.example.com/ inherits basenode {
# all remaining hosts fall here
}
# END SITE.PP
However, this *DOES NOT WORK* becuase somehow, in my basenode definition, I
need to be able to say 'Box X is a DNS server so it gets general DNS server
settings for resolv.conf' so I can pass the right parameters to my 'resolv'
class declaration. How do I do that with out coding in some 'if/else' that
looks for specific hostnames in that node definition?
thx
Chris.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/BQ2fYD0KauYJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
