Linux – Puppet – exclude file from management for managed directory

linuxpuppet

I have a couple Splunk servers in house which I manage part of the configuration through puppet. These are residing on CentOS 6 boxes.

My definition is set up as

file{ "/opt/splunk/etc/apps":
  recurse => true,
  purge => true,
  force => true,
  source => "puppet:///modules/splunk/$hostname/apps",
  ensure =>  present,
  mode => 755,
  owner =>  splunk,
  group => splunk,
  notify => Service["splunk"]
}

This works well, but I'd like to exclude the saved searches file at /opt/splunk/etc/apps/myapp/local/savedsearches.conf from being overwritten and / or automatically update the copy contained within Puppet with the version kept on the local server.

Is there a ready way to do this? I looked over the documentation and didn't see anything.

Best Answer

You can add ignore => "savedsearches.conf" to the file stanza to exclude it from operations on the managed directory.

file{ "/opt/splunk/etc/apps":
  recurse => true,
  purge => true,
  force => true,
  source => "puppet:///modules/splunk/$hostname/apps",
  ensure =>  present,
  mode => 755,
  owner =>  splunk,
  group => splunk,
  ignore => "savedsearches.conf"
  notify => Service["splunk"]
}

Related Solutions

Global vs local puppet management

There is nothing wrong with either approach you propose. We have three puppetmasters, all located at a single site, and serving nodes all over the world - we separate them based on whether the connecting puppet node is in dev/test/prod. Other people prefer to run a puppetmaster per geographic region. Other folk have lots of puppetmasters, some only managing one node!

The key thing is that it is vital that you store and manage your puppetmaster manifest tree in a version control system - treat it like any other code your company maintains. I'd recommend Git, but Subversion will also do the trick if you are more used to that. The puppetmaster is simply a service that serves up its particular view of your VCS, rather than being a central database itself.

With your content in a VCS, you can then deploy the required manifests/modules to the respective puppetmasters, and keep them in sync easily. The convention seems to be for folk have a git/svn repo/module per puppet module, though there is nothing stopping you from putting the whole tree under one repo/module.

My questions to you would be:

How many nodes are in each deployment? If you're talking about 50+, then it would be worth having a local puppetmaster for sure.
Do the deployments have any 3rd parties that use them in addition to your company? The puppetmaster needs to have very high security - consider it to be the keys to the door of all of your systems, and will contain very sensitive information.
Similarly, for the deployment-based PMs, would you host them on their own server/VM, or would an existing machine need to be given the task? I highly recommend that the puppetmaster server has that role alone, for security.
How do you expect EC2 to provide you with higher availability? From my understanding, EC2 instances are not HA, though it should be possible to run 2+ puppetmasters behind the AWS load balancer service.
Are the deployments very different? Do you want to change them at different times of the day? Multiple puppetmasters gives you a finer level of control.

Linux – puppet exclude module

Try this:

class centos_base {
    define includer($exclude=false) {
        if !$exclude {
            include $name
        }
    }

    includer{ ["chkconfig", "hosts", ...: }

    class no_syslog_base inherits centos_base {
        Includer["syslog::base"] { exclude => true }
    }
    ...
}

For server you want to exclude syslog::base:

node 'special' {
    include centos_base::no_syslog_base
}

and for all other servers:

node 'normal' {
    include centos_base
}

Best Answer

Related Solutions

Global vs local puppet management

Linux – puppet exclude module

Related Topic