Need advice how to architect solution for /etc/resolv.conf

[chris_...@sra.com]

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.

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

Here's my problem. At the moment I've defined a module/class called 'resolv' which takes search paths and nameservers as parameters. My simple class applies the correct environment settings which will cover 90% of my hosts.  However, what logic do I use to determine if the box is an actual DNS server? I plan on using a completely independent class ('named') which will cover the DNS server settings.  If I do this I need someway for the 'resolv' class to determine if the host is a DNS server. I don't know how to do that. I don't want the 'named' class to try and modify the variables used for /etc/resolv.conf templates as that belongs to a completely different class. And I don't know how the 'resolv' class can determine if the 'named' has been loaded or not (as I understand it, this would require an order of things which Puppet's DSL doesn't do).

I've figured out how to use Puppet to define classes and sub-classes where the sub-classes can 'disable' a Service, but that's not what I need to do here.  In this case I need to change the values used by the /etc/resolv.conf template.  I suppose Hiera can handle part of my problem, but as I understand Hiera I would need to some some type of structure like this: resolv.conf: environment settings < dns settings < per server settings.    And if so, then I'm back to how do I specify that node X is a generic DNS Server vs all the other non-DNS servers.

I've built my puppet configuration in a hierarchical fashion:  classes for each component (puppet client, ntp client, ssh client), have 'basenode' node define which loads all classes with the 'default' settings for my environments and then I build other nodes which inherit from my basenode and then use the appropriate 'disable' sub-class as needed.  By this logic, I don't see anyway to 'pass' data to a given classes depending on the node definition. 

The fact that I can't overload classes or re-define classes with different parameters is just killing my adoption of Puppet.  I can't break my mind set of programatic inheritance; I *really* want to define a base node with all my defaults and then, as needed, re-define the classes with different class parameters and you can't do that.  I really don't want to define new types (even tho they do allow multiple instances to be defined) as classes are the 'correct' things to use here.

As you can see, I'm have a lot of trouble adapting to Puppet's way of doing things and the DSL.  Any help is appreciated.

thx
Chris.

[Peter Horvath]

So basically you want to avoid node config customization?
You want an ultimate resolv class which will decide everything without
you defining manually something in the node conf?

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

[Tim Mooney]

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
--
Tim Mooney Tim.M...@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

[chris_...@sra.com]

On Friday, March 16, 2012 1:23:16 PM UTC-4, Peter Horvath wrote:

So basically you want to avoid node config customization?
You want an ultimate resolv class which will decide everything without
you defining manually something in the node conf?

What I *want* is this:

node basenode {
    class { resolv: nameservers => [ list based upon environment ], searchpaths => [ list based upon environment ] }
    class { 'ssh' : }
    # other 'standard' classes here
}

node www1 inherits basenode {
    # Generic host, rubberstamped to look like lots of other boxes.
}

node dns inherits basenode {
    class { resolv :nameserver => [ overloaded list for all dns servers], searchpaths => [ overloaded list for all dns servers] }
|

node dns1-test inherits dns {
    class { resolv :nameserver => [ host specific list ], searchpaths => [  host specific list] }
|

However, you can't do that as you are re-defining classes along the way.  What ever the appropriate 'Puppet-way' of solving this problem is, I haven't found it yet.  That's what I need.   I think in terms of 'status quo' vs 'exceptions to status quo' for my environments.  I have the feeling that's the wrong way to work in Puppet, but I'm not sure.

[chris_...@sra.com]

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.

[Florian Koch]

Hi,

this sounds this is a job for hiera:
http://puppetlabs.com/blog/the-problem-with-separating-data-from-puppet-code/
http://puppetlabs.com/blog/first-look-installing-and-using-hiera/

rgds Florian

[jcbollinger]

On Mar 16, 1:32 pm, Florian Koch <florian.koch1...@googlemail.com>
wrote:
> this sounds this is a job for hiera:http://puppetlabs.com/blog/the-problem-with-separating-data-from-pupp...http://puppetlabs.com/blog/first-look-installing-and-using-hiera/


My thought exactly.

Furthermore,

On Mar 16, 11:52 am, "chris_sny...@sra.com" <chris_sny...@sra.com>
wrote:
> [...] However, what logic do I use to determine if the box is an actual
> DNS server?


That's the wrong question. The right one is "how should Puppet tell
whether the box *should be* a DNS server?" Generally the answer boils
down to node identity (e.g. hostname).

Alternatives that involve elements of whether the node already is a
DNS server are more difficult to implement and far less useful --
perhaps even harmful. For instance, suppose a rogue DNS server gets
set up in your network. Do you really want to push out your DNS
server config to it? Or suppose you decide some node should stop
offering DNS. How can you do that if your config is built around DNS
servers remaining DNS servers?


John