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 puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Reply via email to