- Overview
- Module Description - What the module does and why it is useful
- Setup - The basics of getting started with inifile module
- Usage - Configuration options and additional functionality
- Reference - An under-the-hood peek at what the module is doing and how
- Limitations - OS compatibility, etc.
- Development - Guide for contributing to the module
The inifile module lets Puppet manage settings stored in INI-style configuration files.
Many applications use INI-style configuration files to store their settings. This module supplies two custom resource types to let you manage those settings through Puppet.
To manage a single setting in an INI file, add the ini_setting
type to a class:
ini_setting { "sample setting":
ensure => present,
path => '/tmp/foo.ini',
section => 'bar',
setting => 'baz',
value => 'quux',
}
The inifile module is used to:
- Support comments starting with either '#' or ';'.
- Support either whitespace or no whitespace around '='.
- Add any missing sections to the INI file.
It does not manipulate your file any more than it needs to. In most cases, it doesn't affect the original whitespace, comments, or ordering. See the common usages below for examples.
Use the ini_subsetting
type:
ini_subsetting {'sample subsetting':
ensure => present,
section => '',
key_val_separator => '=',
path => '/etc/default/pe-puppetdb',
setting => 'JAVA_ARGS',
subsetting => '-Xmx',
value => '512m',
}
Results in managing this -Xmx
subsetting:
JAVA_ARGS="-Xmx512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/pe-puppetdb/puppetdb-oom.hprof"
ini_setting { 'default minage':
ensure => present,
path => '/etc/security/users',
section => 'default',
setting => 'minage',
value => '1',
section_prefix => '',
section_suffix => ':',
}
Results in:
default:
minage = 1
To use a non-standard indent character or string for added settings, set the indent_char
and the indent_width
parameters. The indent_width
parameter controls how many indent_char
appear in the indent.
ini_setting { 'procedure cache size':
ensure => present,
path => '/var/lib/ase/config/ASE-16_0/SYBASE.cfg',
section => 'SQL Server Administration',
setting => 'procedure cache size',
value => '15000',
indent_char => "\t",
indent_width => 2,
}
Results in:
[SQL Server Administration]
procedure cache size = 15000
You might want to create child providers that inherit the ini_setting
provider for one of the following reasons:
- To make a custom resource to manage an application that stores its settings in INI files, without recreating the code to manage the files themselves.
- To purge all unmanaged settings from a managed INI file.
To implement child providers, first specify a custom type. Have it implement a namevar called name
and a property called value
:
#my_module/lib/puppet/type/glance_api_config.rb
Puppet::Type.newtype(:glance_api_config) do
ensurable
newparam(:name, :namevar => true) do
desc 'Section/setting name to manage from glance-api.conf'
# namevar should be of the form section/setting
newvalues(/\S+\/\S+/)
end
newproperty(:value) do
desc 'The value of the setting to define'
munge do |v|
v.to_s.strip
end
end
end
Your type also needs a provider that uses the ini_setting
provider as its parent:
# my_module/lib/puppet/provider/glance_api_config/ini_setting.rb
Puppet::Type.type(:glance_api_config).provide(
:ini_setting,
# set ini_setting as the parent provider
:parent => Puppet::Type.type(:ini_setting).provider(:ruby)
) do
# implement section as the first part of the namevar
def section
resource[:name].split('/', 2).first
end
def setting
# implement setting as the second part of the namevar
resource[:name].split('/', 2).last
end
# hard code the file path (this allows purging)
def self.file_path
'/etc/glance/glance-api.conf'
end
end
Now you can manage the settings in the /etc/glance/glance-api.conf
file as individual resources:
glance_api_config { 'HEADER/important_config':
value => 'secret_value',
}
If you've implemented self.file_path
, you can have Puppet purge the file of the all lines that aren't implemented as Puppet resources:
resources { 'glance_api_config':
purge => true,
}
To manage multiple ini_settings
, use the create_ini_settings
function.
$defaults = { 'path' => '/tmp/foo.ini' }
$example = { 'section1' => { 'setting1' => 'value1' } }
create_ini_settings($example, $defaults)
Results in:
ini_setting { '[section1] setting1':
ensure => present,
section => 'section1',
setting => 'setting1',
value => 'value1',
path => '/tmp/foo.ini',
}
To include special parameters, use the following code:
$defaults = { 'path' => '/tmp/foo.ini' }
$example = {
'section1' => {
'setting1' => 'value1',
'settings2' => {
'ensure' => 'absent'
}
}
}
create_ini_settings($example, $defaults)
Results in:
ini_setting { '[section1] setting1':
ensure => present,
section => 'section1',
setting => 'setting1',
value => 'value1',
path => '/tmp/foo.ini',
}
ini_setting { '[section1] setting2':
ensure => absent,
section => 'section1',
setting => 'setting2',
path => '/tmp/foo.ini',
}
This example requires Puppet 3.x/4.x, as it uses automatic retrieval of Hiera data for class parameters and puppetlabs/stdlib
.
For the profile example
:
class profile::example (
$settings,
) {
validate_hash($settings)
$defaults = { 'path' => '/tmp/foo.ini' }
create_ini_settings($settings, $defaults)
}
Provide this in your Hiera data:
profile::example::settings:
section1:
setting1: value1
setting2: value2
setting3:
ensure: absent
Results in:
ini_setting { '[section1] setting1':
ensure => present,
section => 'section1',
setting => 'setting1',
value => 'value1',
path => '/tmp/foo.ini',
}
ini_setting { '[section1] setting2':
ensure => present,
section => 'section1',
setting => 'setting2',
value => 'value2',
path => '/tmp/foo.ini',
}
ini_setting { '[section1] setting3':
ensure => absent,
section => 'section1',
setting => 'setting3',
path => '/tmp/foo.ini',
}
See REFERENCE.md
Due to (PUP-4709) the create_ini_settings function will cause errors when attempting to create multiple ini_settings in one go when using Puppet 4.0.x or 4.1.x. If needed, the temporary fix for this can be found here: puppetlabs#196.
For an extensive list of supported operating systems, see metadata.json
We are experimenting with a new tool for running acceptance tests. It's name is puppet_litmus this replaces beaker as the test runner. To run the acceptance tests follow the instructions here.
Puppet Labs modules on the Puppet Forge are open projects, and community contributions are essential for keeping them great. We can't access the huge number of platforms and myriad of hardware, software, and deployment configurations that Puppet is intended to serve.
We want to keep it as easy as possible to contribute changes so that our modules work in your environment. There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.
For more information, see our module contribution guide.
To see who's already involved, see the list of contributors.