Ask Your Question

Modifying common configuration files with multiple modules

asked 2016-11-26 13:53:02 -0600

ljkimmel99 gravatar image

All; I'm an intermediate puppeteer (is that a thing?) looking for some magic tricks. I've come across a specific issue and would like some ideas which would hopefully lead to a more general solution.

I'm working in a greenfield environment and my first step is creating a security module which among many other things installs, enables, and starts SSSD. As you may be aware SSSD requires that an sssd.conf file be created. While this is currently my only module I will surely have many more down the road. One that I can foresee is a module to integrate my Linux machines into AD. This will require modification of sssd.conf as well. How can I create modules which do a specific job while still being generic enough to run alongside other modules? From what I know there are basically (3) ways to create/modify a file from a module. Using a file resource with a static 'source', using a file resource with 'content' from a template, and using Augeas. I think using either a source file or template would be overwriting another modules changes upon every refresh cycle. Augeas seems like the obvious answer but I was hoping for a more elegant solution.

edit retag flag offensive close merge delete


You might want to see if there is a SSSD module in puppet forge. Looks like there are quite a few:

Red Cricket gravatar imageRed Cricket ( 2016-11-26 18:32:52 -0600 )edit

Indeed, there are quite a few but, correct me if I'm wrong, but if they are classes I will still only be able to declare that module/class from only one of my other modules, yes?

ljkimmel99 gravatar imageljkimmel99 ( 2016-11-27 11:26:32 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2016-11-27 09:52:15 -0600

apologies if I'm misunderstanding you - I'd be reticent to have multiple modules modify one file - therein lies chaos.

What I would suggest is you have say:

  1. security module - installs high level and general security details
  2. an ssd module
  3. an AD integration module

there would be no overlap in what each of these manages - however you could have dependencies -- e.g. configure ssd module in this way IF AD integration module is present etc.... ssd module would be the only module that alters anything within the ssd package..

edit flag offensive delete link more


You understood correctly. I am actually leaning in a direction similar to that at this point.

ljkimmel99 gravatar imageljkimmel99 ( 2016-11-27 11:21:17 -0600 )edit

This works fine with in-house developed modules but what about if one wanted to download prebuilt modules from the forge. I gather that such resource conflicts are common then. I thought puppet was supposed to be modular but this sort of issue is in direct conflict with that it seems.

ljkimmel99 gravatar imageljkimmel99 ( 2016-11-27 11:22:29 -0600 )edit

I found an issue posted within the puppetlabs system ( which seems to indicate this type of issue is common and the solution seems illusive if not controversial. It seems the discussion has gone on for years and is nowhere near a resolution.

ljkimmel99 gravatar imageljkimmel99 ( 2016-11-27 11:25:59 -0600 )edit

The best approach I've seen in these cases is to have an sssd profile where your other profiles would set/export some data that it would load, possibly with or exported resources

DarylW gravatar imageDarylW ( 2016-11-28 00:40:01 -0600 )edit

Similar to having multiple 'logging' configurations or 'monitoring' configurations, and each of your other profiles can define a resource (concat fragment or datacat piece) and having your other profile pull them together

DarylW gravatar imageDarylW ( 2016-11-28 00:50:28 -0600 )edit

answered 2016-11-29 09:38:26 -0600

scoffland gravatar image

There are several ways to handle the need to manage a single service with multiple modules in puppet. In general it is good to use a conf.d style structure to add separate configuration files to manage a service. I don't know of a way this can be done with sssd and that can be the case with many other services also. If a conf.d setup is not possible then Augueas or templates are the way to go in puppet. I prefer templates. You mention above that templates would be overwriting from another module this does not have to be the case. Templates are created with ruby snippets and because of this have a lot of flexibility. I'll provide an example below of how this can be done.

node /foobar1/ {
  include foo
node /foobar2/ {
  include baz
  include foo

class foo {
  package { 'bar': ensure => installed }
  service { 'bar": ensure => running, require => Package['bar'] }
  $foo1 = 'false' 
  $foo2 ='true'
  file { '/etc/bar.conf': 
    source => "puppet://modules/foo/bar.conf.erb",
    notify Service['bar']

class baz {
  $baz1 = 'true'
  $baz2 = '25'


domains = LOCAL
services = nss
config_file_version = <%= @foo1 %>
<% if @baz1  == 'true' -%>
bez = <%= @baz2 %>
glut = <%= @foo2 %>
<% end %>
edit flag offensive delete link more


How is that possible? bar.conf.erb is part of the 'foo' module and would not have direct access to the variables of the external class 'baz'. You might be able to provide the namespace for the 'baz' class within the template but it is poor practice for a class to depend on the variables of another.

ljkimmel9903 gravatar imageljkimmel9903 ( 2017-05-04 10:10:25 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2016-11-26 13:53:02 -0600

Seen: 153 times

Last updated: Nov 29 '16