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