Module Description - What the module does and why it is useful
Reference - An under-the-hood peek at what the module is doing and how
This module constructs files from multiple fragments in an ordered way.
This module lets you use many concat::fragment{} resources throughout your modules to construct a single file at the end. It does this through a shell (or ruby) script and a temporary holding space for the fragments.
Installs concatfragments. based on platform.
Adds a concat/ directory into Puppets vardir
.
To start using concat you need to create:
A concat{} resource for the final file.
One or more concat::fragment{}'s.
A minimal example might be:
concat { '/tmp/file': ensure => present, } concat::fragment { 'tmpfile': target => '/tmp/file', content => 'test contents', order => '01' }
Please be aware that there have been a number of API deprecations.
If you wanted a /etc/motd file that listed all the major modules on the machine. And that would be maintained automatically even if you just remove the include lines for other modules you could use code like below, a sample /etc/motd would be:
Puppet modules on this server: -- Apache -- MySQL
Local sysadmins can also append to the file by just editing /etc/motd.local their changes will be incorporated into the puppet managed motd.
class motd { $motd = '/etc/motd' concat { $motd: owner => 'root', group => 'root', mode => '0644' } concat::fragment{ 'motd_header': target => $motd, content => "\nPuppet modules on this server:\n\n", order => '01' } # local users on the machine can append to motd by just creating # /etc/motd.local concat::fragment{ 'motd_local': target => $motd, source => '/etc/motd.local', order => '15' } } # used by other modules to register themselves in the motd define motd::register($content="", $order='10') { if $content == "" { $body = $name } else { $body = $content } concat::fragment{ "motd_fragment_$name": target => '/etc/motd', order => $order, content => " -- $body\n" } }
To use this you'd then do something like:
class apache { include apache::install, apache::config, apache::service motd::register{ 'Apache': } }
concat::setup
: Sets up the concat script/directories.
ensure
¶ ↑Controls if the combined file is present or absent.
ensure => present
ensure => absent
path
¶ ↑Controls the destination of the file to create.
path => '/tmp/filename'
owner
¶ ↑Set the owner of the combined file.
owner => 'root'
group
¶ ↑Set the group of the combined file.
group => 'root'
mode
¶ ↑Set the mode of the combined file.
mode => '0644'
warn
¶ ↑Determine if a warning message should be added at the top of the file to let users know it was autogenerated by Puppet. It should be a boolean or a string containing the contents of the warning message.
warn => true
warn => false
warn => '# This file is autogenerated!'
force
¶ ↑Determine if empty files are allowed when no fragments were added.
force => true
force => false
backup
¶ ↑Controls the filebucket behavior used for the file.
backup => 'puppet'
replace
¶ ↑Controls if Puppet should replace the destination file if it already exists.
replace => true
replace => false
order
¶ ↑Controls the way in which the shell script chooses to sort the files. It's rare you'll need to adjust this.
order => 'alpha'
order => 'numeric'
ensure_newline
¶ ↑Ensure there's a newline at the end of the fragments.
ensure_newline => true
ensure_newline => false
target
¶ ↑Choose the destination file of the fragment.
target => '/tmp/testfile'
content
¶ ↑Create the content of the fragment.
content => 'test file contents'
source
¶ ↑Find the sources within Puppet of the fragment.
source => 'puppet:///modules/test/testfile'
source => ['puppet:///modules/test/1', 'puppet:///modules/test/2']
order
¶ ↑Order the fragments.
order => '01'
Best practice is to pass a string to this parameter but integer values are accepted.
ensure
¶ ↑Control the file of fragment created.
ensure => 'present'
ensure => 'absent'
mode
¶ ↑Set the mode of the fragment.
mode => '0644'
owner
¶ ↑Set the owner of the fragment.
owner => 'root'
group
¶ ↑Set the group of the fragment.
group => 'root'
backup
¶ ↑Control the filebucket behavior for the fragment.
backup => 'puppet'
1.0.0
¶ ↑concat{}
warn
parameter¶ ↑concat { '/tmp/file': ensure => present, warn => 'true', # generates stringified boolean value warning }
Using stringified Boolean values as the warn
parameter to
concat
is deprecated, generates a catalog compile time
warning, and will be silently treated as the concatenated file
header/warning message in a future release.
The following strings are considered a stringified Boolean value:
'true'
'yes'
'on'
'false'
'no'
'off'
Please migrate to using the Puppet DSL's native Boolean data type.
concat{}
gnu
parameter¶ ↑concat { '/tmp/file': ensure => present, gnu => $foo, # generates deprecation warning }
The gnu
parameter to concat
is deprecated,
generates a catalog compile time warning, and has no effect. This parameter
will be removed in a future release.
Note that this parameter was silently ignored in the 1.0.0
release.
concat::fragment{}
ensure
parameter¶ ↑concat::fragment { 'cpuinfo': ensure => '/proc/cpuinfo', # generates deprecation warning target => '/tmp/file', }
Passing a value other than 'present'
or
'absent'
as the ensure
parameter to
concat::fragment
is deprecated and generates a catalog compile
time warning. The warning will become a catalog compilation failure in a
future release.
This type emulates the Puppet core file
type's disfavored
ensure
semantics of treating a file path as a directive to create a symlink.
This feature is problematic in several ways. It copies an API semantic of
another type that is both frowned upon and not generally well known.
It's behavior may be surprising in that the target concatenated file
will not be a symlink nor is there any common file system that has a
concept of a section of a plain file being symbolically linked to another
file. Additionally, the behavior is generally inconsistent with most Puppet
types in that a missing source file will be silently ignored.
If you want to use the content of a file as a fragment please use the
source
parameter.
concat::fragment{}
mode/owner/group
parameters¶ ↑concat::fragment { 'foo': target => '/tmp/file', content => 'foo', mode => $mode, # generates deprecation warning owner => $owner, # generates deprecation warning group => $group, # generates deprecation warning }
The mode
parameter to concat::fragment
is
deprecated, generates a catalog compile time warning, and has no effect.
The owner
parameter to concat::fragment
is
deprecated, generates a catalog compile time warning, and has no effect.
The group
parameter to concat::fragment
is
deprecated, generates a catalog compile time warning, and has no effect.
These parameters had no user visible effect in version 1.0.0
and will be removed in a future release.
concat::fragment{}
backup
parameter¶ ↑concat::fragment { 'foo': target => '/tmp/file', content => 'foo', backup => 'bar', # generates deprecation warning }
The backup
parameter to concat::fragment
is
deprecated, generates a catalog compile time warning, and has no effect. It
will be removed in a future release.
In the 1.0.0
release this parameter controlled file bucketing
of the file fragment. Bucketting the fragment(s) is redundant with
bucketting the final concatenated file and this feature has been removed.
class { 'concat::setup': }
¶ ↑include concat::setup # generates deprecation warning class { 'concat::setup': } # generates deprecation warning
The concat::setup
class is deprecated as a public API of this
module and should no longer be directly included in the manifest. This
class may be removed in a future release.
While not an API depreciation, users should be aware that all public parameters in this module are now validated for at least variable type. This may cause validation errors in a manifest that was previously silently misbehaving.
This module has been tested on:
RedHat Enterprise Linux (and Centos) 5/6
Debian 6/7
Ubuntu 12.04
Testing on other platforms has been light and cannot be guaranteed.
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.
You can read the complete module contribution guide on the Puppet Labs wiki.
The list of contributors can be found at: