While building up complex configs with Puppet you often need to build up one file from many fragments. This is useful for files like older sysctl.conf files and maybe named.conf files.
The basic pattern is you want to manage a file, but want the contents to be very different from node to node. A fragment based system lets you register different contents into a file on different nodes. It’s exactly like the conf.d directory you’d find in Apache but for daemons that does not support this construct on their own.
I’ve had an older version of this floating around but had to clean it up for a client today so thought I might as well do a proper job, release it and get some more eye balls on it. This version is specific to Puppet 0.25.x, I will soon make a >= 0.24.8 version too since that is what my client is on.
An example says more than words, so lets create something to manage sysctl.conf:
# Initial setup
class sysctl {
include concat::setup
exec{"reload-sysctl":
refreshonly => true,
command => "/sbin/sysctl -p"
}
concat{"/etc/sysctl.conf":
notify => Exec["reload-sysctl"],
}
}
# use this to set values
define sysctl::setting($value) {
concat::fragment{"sysctl_${name}":
target => "/etc/sysctl.conf",
content => "${name} = ${value}\n",
}
} |
The above sets up a class that will create an empty sysctl.conf and provides an utility for setting individual values. Whenever the sysctl.conf file gets changed the changes will be made live using the refreshonly exec.
Lets see how we might use it:
node "your.example.com" {
include sysctl
sysctl::setting{"net.ipv4.ip_forward":
value => 1
}
} |
You can see this looks and feels a lot like a native type but without a lot of the hassle it would take to write one, you can really get a lot of mileage out of this pattern. The concat is clever enough to unregister the setting should you remove lines 4 to 6 in the above node block.
A cleaner approach would be to just make classes like sysctl::ipv4_forward that you can include on the nodes that need it.
You can grab the current code here.
