Puppet users - Mar 2012 - Need advice how to architect solution for /etc/resolv.conf

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.

-- 
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-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.

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?

On 16 March 2012 16:52, chris_snyder@sra.com <chris_snyder@sra.com>
wrote:
> 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.
>
> --
> 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-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.
-- 
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.

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.Mooney@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

-- 
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.

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.

-- 
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/-/McIZy-QPFcEJ.
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.

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

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

Am Freitag, 16. März 2012 19:12:10 UTC+1 schrieb
chris_...@sra.com:
>
>
>
> 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/-/yHPqXaGONFYJ.
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.

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

-- 
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.