1

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?

4

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.