Handling exceptions for modules in Puppet

Question

I have an LDAP module in Puppet that is used by 100 servers and edits about 10 files on all servers, before it runs authconfig --updateall to activate the new LDAP configuration.

Most (98) of these servers needs a standard access-1.conf as their access.conf, but 2 servers need access-2.conf. This is part of a big ldap module, so all 100 servers need 99% of that ldap module, but some servers (more in the future based on their role) need an exception for the access.conf.

[root@puppetmaster modules]# cat /etc/puppet/hieradata/environment/prd/webserver-03.yaml classes: - webserver - webserver-apache-02

# Test variables
role: webserver
cluster: apache-02

I am thinking about using something like this in the manifests/init.pp:

$role = hiera('role');

if($role = 'webserver') {
    file { '/etc/security/access.conf':
            owner => 'root',
            group => 'root',
            mode => '644',
            content => template('ldap/access-2.conf'),
    }
else {
    file { '/etc/security/access.conf':
            owner => 'root',
            group => 'root',
            mode => '644',
            content => template('ldap/access-2.conf'),
    }
}

The DRY (Don't Repeat Yourself) principle is important to me, I would rather not clone an entire module. There will be many cases in the future where I will want to use roles to distribute specific files/configurations based on the role of the server, while still sharing a module with other servers.

What do you think of using this role: webserver and an if/else as a solution for handling this exception in the module?

score 4 · Accepted Answer · answered Jul 29 '13 at 11:59

You can use a custom fact to distinguish between them, and resolve a template using that fact:

class foo (
  $role,
  ){
    file { '/etc/security/access.conf':
        owner => 'root',
        group => 'root',
        mode => '644',
        content => template("$role.ldap/access-2.conf"),
    }
}

Using current facter version, it is easy to provide custom facts on your servers:

# cat /etc/facter/facts.d/datacenter.yaml
---
role: webserver
location: Oz

Then, depending on how you have configured your hierarchy, you can have a default role and roles per domain or host, an example:

---
:backends:
  - yaml
:hierarchy:
  - "%{::hostname}"
  - common
:yaml:
  :datadir: "/etc/puppet/hieradata/%{::domain}/%{::location}"

Here, location is also a custom fact, so it is easy to build custom hierarchies as well. To handle exceptions, write a custom fact, and let the common.yaml file hold the default values.

Handling exceptions for modules in Puppet

1 Answers1