puppet doc

  • before — Applies a resource before the target resource.
  • require — Applies a resource after the target resource.
  • notify — Applies a resource before the target resource. The target resource refreshes if the notifying resource changes.
  • subscribe — Applies a resource after the target resource. The subscribing resource refreshes if the target resource changes.

# Type Reference

**This page is autogenerated; any changes will get overwritten** *(last generated on 2017-01-11 16:46:04 +0000)*

## Resource Types

– The *namevar* is the parameter used to uniquely identify a type instance.
This is the parameter that gets assigned when a string is provided before
the colon in a type declaration. In general, only developers will need to
worry about which parameter is the `namevar`.

In the following code:

file { “/etc/passwd”:
owner => root,
group => root,
mode => 644
}

`/etc/passwd` is considered the title of the file object (used for things like
dependency handling), and because `path` is the namevar for `file`, that
string is assigned to the `path` parameter.

– *Parameters* determine the specific configuration of the instance. They either
directly modify the system (internally, these are called properties) or they affect
how the instance behaves (e.g., adding a search path for `exec` instances or determining recursion on `file` instances).

– *Providers* provide low-level functionality for a given resource type. This is
usually in the form of calling out to external commands.

When required binaries are specified for providers, fully qualifed paths
indicate that the binary must exist at that specific path and unqualified
binaries indicate that Puppet will search for the binary using the shell
path.

– *Features* are abilities that some providers might not support. You can use the list
of supported features to determine how a given provider can be used.

Resource types define features they can use, and providers can be tested to see
which features they provide.

—————-

### augeas

Apply a change or an array of changes to the filesystem
using the augeas tool.

Requires:

– [Augeas](http://www.augeas.net)
– The ruby-augeas bindings

Sample usage with a string:

augeas{“test1” :
context => “/files/etc/sysconfig/firstboot”,
changes => “set RUN_FIRSTBOOT YES”,
onlyif => “match other_value size > 0”,
}

Sample usage with an array and custom lenses:

augeas{“jboss_conf”:
context => “/files”,
changes => [
“set etc/jbossas/jbossas.conf/JBOSS_IP $ipaddress”,
“set etc/jbossas/jbossas.conf/JAVA_HOME /usr”,
],
load_path => “$/usr/share/jbossas/lenses”,
}

#### Features

– *execute_changes*: Actually make the changes
– *need_to_run?*: If the command should run
– *parse_commands*: Parse the command string
Provider | execute_changes | need_to_run? | parse_commands |
——– | ————— | ———— | ————– |
augeas | *X* | *X* | *X* |

#### Parameters
changes
: The changes which should be applied to the filesystem. This
can be a command or an array of commands. The following commands are supported:

* `set <PATH> <VALUE>` — Sets the value `VALUE` at loction `PATH`
* `setm <PATH> <SUB> <VALUE>` — Sets multiple nodes (matching `SUB` relative to `PATH`) to `VALUE`
* `rm <PATH>` — Removes the node at location `PATH`
* `remove <PATH>` — Synonym for `rm`
* `clear <PATH>` — Sets the node at `PATH` to `NULL`, creating it if needed
* `clearm <PATH> <SUB>` — Sets multiple nodes (matching `SUB` relative to `PATH`) to `NULL`
* `ins <LABEL> (before|after) <PATH>` — Inserts an empty node `LABEL` either before or after `PATH`.
* `insert <LABEL> <WHERE> <PATH>` — Synonym for `ins`
* `mv <PATH> <OTHER PATH>` — Moves a node at `PATH` to the new location `OTHER PATH`
* `move <PATH> <OTHER PATH>` — Synonym for `mv`
* `defvar <NAME> <PATH>` — Sets Augeas variable `$NAME` to `PATH`
* `defnode <NAME> <PATH> <VALUE>` — Sets Augeas variable `$NAME` to `PATH`, creating it with `VALUE` if needed

If the `context` parameter is set, that value is prepended to any relative `PATH`s.

context
: Optional context path. This value is prepended to the paths of all
changes if the path is relative. If the `incl` parameter is set,
defaults to `/files + incl`; otherwise, defaults to the empty string.

force
: Optional command to force the augeas type to execute even if it thinks changes
will not be made. This does not overide the `onlyif` parameter.

incl
: Load only a specific file, e.g. `/etc/hosts`. This can greatly speed
up the execution the resource. When this parameter is set, you must also
set the `lens` parameter to indicate which lens to use.

lens
: Use a specific lens, e.g. `Hosts.lns`. When this parameter is set, you
must also set the `incl` parameter to indicate which file to load.
The Augeas documentation includes [a list of available lenses](http://augeas.net/stock_lenses.html).

load_path
: Optional colon-separated list or array of directories; these directories are searched for schema definitions. The agent’s `$libdir/augeas/lenses` path will always be added to support pluginsync.

name
: The name of this task. Used for uniqueness.

onlyif
: Optional augeas command and comparisons to control the execution of this type.
Supported onlyif syntax:

* `get <AUGEAS_PATH> <COMPARATOR> <STRING>`
* `match <MATCH_PATH> size <COMPARATOR> <INT>`
* `match <MATCH_PATH> include <STRING>`
* `match <MATCH_PATH> not_include <STRING>`
* `match <MATCH_PATH> == <AN_ARRAY>`
* `match <MATCH_PATH> != <AN_ARRAY>`

where:

* `AUGEAS_PATH` is a valid path scoped by the context
* `MATCH_PATH` is a valid match syntax scoped by the context
* `COMPARATOR` is one of `>, >=, !=, ==, <=,` or `<`
* `STRING` is a string
* `INT` is a number
* `AN_ARRAY` is in the form `[‘a string’, ‘another’]`

provider
: The specific backend to use for this `augeas`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

augeas
: * Supported features: `execute_changes`, `need_to_run?`, `parse_commands`.

returns
: The expected return code from the augeas command. Should not be set.

root
: A file system path; all files loaded by Augeas are loaded underneath `root`.

show_diff
: Whether to display differences when the file changes, defaulting to
true. This parameter is useful for files that may contain passwords or
other secret data, which might otherwise be included in Puppet reports or
other insecure outputs. If the global `show_diff` setting
is false, then no diffs will be shown even if this parameter is true.

Valid values are `true`, `false`, `yes`, `no`.

type_check
: Whether augeas should perform typechecking. Defaults to false.

Valid values are `true`, `false`.
—————-

### computer

Computer object management using DirectoryService
on OS X.

Note that these are distinctly different kinds of objects to ‘hosts’,
as they require a MAC address and can have all sorts of policy attached to
them.

This provider only manages Computer objects in the local directory service
domain, not in remote directories.

If you wish to manage `/etc/hosts` file on Mac OS X, then simply use the host
type as per other platforms.

This type primarily exists to create localhost Computer objects that MCX
policy can then be attached to.

**Autorequires:** If Puppet is managing the plist file representing a
Computer object (located at `/var/db/dslocal/nodes/Default/computers/{name}.plist`),
the Computer resource will autorequire it.

#### Parameters
en_address
: The MAC address of the primary network interface. Must match en0.

ensure
: Control the existences of this computer record. Set this attribute to
`present` to ensure the computer record exists. Set it to `absent`
to delete any computer records with this name

Valid values are `present`, `absent`.

ip_address
: The IP Address of the Computer object.

name
: The authoritative ‘short’ name of the computer record.

provider
: The specific backend to use for this `computer`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

directoryservice
: Computer object management using DirectoryService on OS X.
Note that these are distinctly different kinds of objects to ‘hosts’,
as they require a MAC address and can have all sorts of policy attached to
them.

This provider only manages Computer objects in the local directory service
domain, not in remote directories.

If you wish to manage /etc/hosts on Mac OS X, then simply use the host
type as per other platforms.

* Default for `operatingsystem` == `darwin`.

realname
: The ‘long’ name of the computer record.
—————-

### cron

Installs and manages cron jobs. Every cron resource created by Puppet
requires a command and at least one periodic attribute (hour, minute,
month, monthday, weekday, or special). While the name of the cron job is
not part of the actual job, the name is stored in a comment beginning with
`# Puppet Name: `. These comments are used to match crontab entries created
by Puppet with cron resources.

If an existing crontab entry happens to match the scheduling and command of a
cron resource that has never been synched, Puppet will defer to the existing
crontab entry and will not create a new entry tagged with the `# Puppet Name: `
comment.

Example:

cron { logrotate:
command => “/usr/sbin/logrotate”,
user => root,
hour => 2,
minute => 0
}

Note that all periodic attributes can be specified as an array of values:

cron { logrotate:
command => “/usr/sbin/logrotate”,
user => root,
hour => [2, 4]
}

…or using ranges or the step syntax `*/2` (although there’s no guarantee
that your `cron` daemon supports these):

cron { logrotate:
command => “/usr/sbin/logrotate”,
user => root,
hour => [‘2-4’],
minute => ‘*/10’
}

An important note: _the Cron type will not reset parameters that are
removed from a manifest_. For example, removing a `minute => 10` parameter
will not reset the minute component of the associated cronjob to `*`.
These changes must be expressed by setting the parameter to
`minute => absent` because Puppet only manages parameters that are out of
sync with manifest entries.

**Autorequires:** If Puppet is managing the user account specified by the
`user` property of a cron resource, then the cron resource will autorequire
that user.

#### Parameters
command
: The command to execute in the cron job. The environment
provided to the command varies by local system rules, and it is
best to always provide a fully qualified command. The user’s
profile is not sourced when the command is run, so if the
user’s environment is desired it should be sourced manually.

All cron parameters support `absent` as a value; this will
remove any existing values for that field.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

environment
: Any environment settings associated with this cron job. They
will be stored between the header and the job in the crontab. There
can be no guarantees that other, earlier settings will not also
affect a given cron job.
Also, Puppet cannot automatically determine whether an existing,
unmanaged environment setting is associated with a given cron
job. If you already have cron jobs with environment settings,
then Puppet will keep those settings in the same place in the file,
but will not associate them with a specific job.

Settings should be specified exactly as they should appear in
the crontab, e.g., `PATH=/bin:/usr/bin:/usr/sbin`.

hour
: The hour at which to run the cron job. Optional;
if specified, must be between 0 and 23, inclusive.

minute
: The minute at which to run the cron job.
Optional; if specified, must be between 0 and 59, inclusive.

month
: The month of the year. Optional; if specified
must be between 1 and 12 or the month name (e.g., December).

monthday
: The day of the month on which to run the
command. Optional; if specified, must be between 1 and 31.

name
: The symbolic name of the cron job. This name
is used for human reference only and is generated automatically
for cron jobs found on the system. This generally won’t
matter, as Puppet will do its best to match existing cron jobs
against specified jobs (and Puppet adds a comment to cron jobs it adds),
but it is at least possible that converting from unmanaged jobs to
managed jobs might require manual intervention.

provider
: The specific backend to use for this `cron`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

crontab
: * Required binaries: `crontab`.

special
: A special value such as ‘reboot’ or ‘annually’.
Only available on supported systems such as Vixie Cron.
Overrides more specific time of day/week settings.
Set to ‘absent’ to make puppet revert to a plain numeric schedule.

target
: The name of the crontab file in which the cron job should be stored.

This property defaults to the value of the `user` property if set, the
user running Puppet or `root`.

For the default crontab provider, this property is functionally
equivalent to the `user` property and should be avoided. In particular,
setting both `user` and `target` to different values will result in
undefined behavior.

user
: The user who owns the cron job. This user must
be allowed to run cron jobs, which is not currently checked by
Puppet.

This property defaults to the user running Puppet or `root`.

The default crontab provider executes the system `crontab` using
the user account specified by this property.

weekday
: The weekday on which to run the command.
Optional; if specified, must be between 0 and 7, inclusive, with
0 (or 7) being Sunday, or must be the name of the day (e.g., Tuesday).
—————-

### exec

Executes external commands.

Any command in an `exec` resource **must** be able to run multiple times
without causing harm — that is, it must be *idempotent*. There are three
main ways for an exec to be idempotent:

* The command itself is already idempotent. (For example, `apt-get update`.)
* The exec has an `onlyif`, `unless`, or `creates` attribute, which prevents
Puppet from running the command unless some condition is met.
* The exec has `refreshonly => true`, which only allows Puppet to run the
command when some other resource is changed. (See the notes on refreshing
below.)

A caution: There’s a widespread tendency to use collections of execs to
manage resources that aren’t covered by an existing resource type. This
works fine for simple tasks, but once your exec pile gets complex enough
that you really have to think to understand what’s happening, you should
consider developing a custom resource type instead, as it will be much
more predictable and maintainable.

**Refresh:** `exec` resources can respond to refresh events (via
`notify`, `subscribe`, or the `~>` arrow). The refresh behavior of execs
is non-standard, and can be affected by the `refresh` and
`refreshonly` attributes:

* If `refreshonly` is set to true, the exec will _only_ run when it receives an
event. This is the most reliable way to use refresh with execs.
* If the exec already would have run and receives an event, it will run its
command **up to two times.** (If an `onlyif`, `unless`, or `creates` condition
is no longer met after the first run, the second run will not occur.)
* If the exec already would have run, has a `refresh` command, and receives an
event, it will run its normal command, then run its `refresh` command
(as long as any `onlyif`, `unless`, or `creates` conditions are still met
after the normal command finishes).
* If the exec would **not** have run (due to an `onlyif`, `unless`, or `creates`
attribute) and receives an event, it still will not run.
* If the exec has `noop => true`, would otherwise have run, and receives
an event from a non-noop resource, it will run once (or run its `refresh`
command instead, if it has one).

In short: If there’s a possibility of your exec receiving refresh events,
it becomes doubly important to make sure the run conditions are restricted.

**Autorequires:** If Puppet is managing an exec’s cwd or the executable
file used in an exec’s command, the exec resource will autorequire those
files. If Puppet is managing the user that an exec should run as, the
exec resource will autorequire that user.

#### Parameters
command
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The actual command to execute. Must either be fully qualified
or a search path for the command must be provided. If the command
succeeds, any output produced will be logged at the instance’s
normal log level (usually `notice`), but if the command fails
(meaning its return code does not match the specified code) then
any output is logged at the `err` log level.

creates
: A file to look for before running the command. The command will
only run if the file **doesn’t exist.**

This parameter doesn’t cause Puppet to create a file; it is only
useful if **the command itself** creates a file.

exec { “tar -xf /Volumes/nfs02/important.tar”:
cwd => “/var/tmp”,
creates => “/var/tmp/myfile”,
path => [“/usr/bin”, “/usr/sbin”]
}

In this example, `myfile` is assumed to be a file inside
`important.tar`. If it is ever deleted, the exec will bring it
back by re-extracting the tarball. If `important.tar` does **not**
actually contain `myfile`, the exec will keep running every time
Puppet runs.

cwd
: The directory from which to run the command. If
this directory does not exist, the command will fail.

environment
: Any additional environment variables you want to set for a
command. Note that if you use this to set PATH, it will override
the `path` attribute. Multiple environment variables should be
specified as an array.

group
: The group to run the command as. This seems to work quite
haphazardly on different platforms — it is a platform issue
not a Ruby or Puppet one, since the same variety exists when
running commands as different users in the shell.

logoutput
: Whether to log command output in addition to logging the
exit code. Defaults to `on_failure`, which only logs the output
when the command has an exit code that does not match any value
specified by the `returns` attribute. As with any resource type,
the log level can be controlled with the `loglevel` metaparameter.

Valid values are `true`, `false`, `on_failure`.

onlyif
: If this parameter is set, then this `exec` will only run if
the command has an exit code of 0. For example:

exec { “logrotate”:
path => “/usr/bin:/usr/sbin:/bin”,
onlyif => “test `du /var/log/messages | cut -f1` -gt 100000”
}

This would run `logrotate` only if that test returned true.

Note that this command follows the same rules as the main command,
which is to say that it must be fully qualified if the path is not set.
It also uses the same provider as the main command, so any behavior
that differs by provider will match.

Also note that onlyif can take an array as its value, e.g.:

onlyif => [“test -f /tmp/file1”, “test -f /tmp/file2”]

This will only run the exec if _all_ conditions in the array return true.

path
: The search path used for command execution.
Commands must be fully qualified if no path is specified. Paths
can be specified as an array or as a ‘:’ separated list.

provider
: The specific backend to use for this `exec`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

posix
: Executes external binaries directly, without passing through a shell or
performing any interpolation. This is a safer and more predictable way
to execute most commands, but prevents the use of globbing and shell
built-ins (including control logic like “for” and “if” statements).

* Default for `feature` == `posix`.

shell
: Passes the provided command through `/bin/sh`; only available on
POSIX systems. This allows the use of shell globbing and built-ins, and
does not require that the path to a command be fully-qualified. Although
this can be more convenient than the `posix` provider, it also means that
you need to be more careful with escaping; as ever, with great power comes
etc. etc.

This provider closely resembles the behavior of the `exec` type
in Puppet 0.25.x.

windows
: Execute external binaries on Windows systems. As with the `posix`
provider, this provider directly calls the command with the arguments
given, without passing it through a shell or performing any interpolation.
To use shell built-ins — that is, to emulate the `shell` provider on
Windows — a command must explicitly invoke the shell:

exec {‘echo foo’:
command => ‘cmd.exe /c echo “foo”‘,
}

If no extension is specified for a command, Windows will use the `PATHEXT`
environment variable to locate the executable.

**Note on PowerShell scripts:** PowerShell’s default `restricted`
execution policy doesn’t allow it to run saved scripts. To run PowerShell
scripts, specify the `remotesigned` execution policy as part of the
command:

exec { ‘test’:
path => ‘C:/Windows/System32/WindowsPowerShell/v1.0’,
command => ‘powershell -executionpolicy remotesigned -file C:/test.ps1’,
}

* Default for `operatingsystem` == `windows`.

refresh
: How to refresh this command. By default, the exec is just
called again when it receives an event from another resource,
but this parameter allows you to define a different command
for refreshing.

refreshonly
: The command should only be run as a
refresh mechanism for when a dependent object is changed. It only
makes sense to use this option when this command depends on some
other object; it is useful for triggering an action:

# Pull down the main aliases file
file { “/etc/aliases”:
source => “puppet://server/module/aliases”
}

# Rebuild the database, but only when the file changes
exec { newaliases:
path => [“/usr/bin”, “/usr/sbin”],
subscribe => File[“/etc/aliases”],
refreshonly => true
}

Note that only `subscribe` and `notify` can trigger actions, not `require`,
so it only makes sense to use `refreshonly` with `subscribe` or `notify`.

Valid values are `true`, `false`.

returns
: The expected exit code(s). An error will be returned if the
executed command has some other exit code. Defaults to 0. Can be
specified as an array of acceptable exit codes or a single value.

On POSIX systems, exit codes are always integers between 0 and 255.

On Windows, **most** exit codes should be integers between 0
and 2147483647.

Larger exit codes on Windows can behave inconsistently across different
tools. The Win32 APIs define exit codes as 32-bit unsigned integers, but
both the cmd.exe shell and the .NET runtime cast them to signed
integers. This means some tools will report negative numbers for exit
codes above 2147483647. (For example, cmd.exe reports 4294967295 as -1.)
Since Puppet uses the plain Win32 APIs, it will report the very large
number instead of the negative number, which might not be what you
expect if you got the exit code from a cmd.exe session.

Microsoft recommends against using negative/very large exit codes, and
you should avoid them when possible. To convert a negative exit code to
the positive one Puppet will use, add it to 4294967296.

timeout
: The maximum time the command should take. If the command takes
longer than the timeout, the command is considered to have failed
and will be stopped. The timeout is specified in seconds. The default
timeout is 300 seconds and you can set it to 0 to disable the timeout.

tries
: The number of times execution of the command should be tried.
Defaults to ‘1’. This many attempts will be made to execute
the command until an acceptable return code is returned.
Note that the timeout paramater applies to each try rather than
to the complete set of tries.

try_sleep
: The time to sleep in seconds between ‘tries’.

umask
: Sets the umask to be used while executing this command

unless
: If this parameter is set, then this `exec` will run unless
the command has an exit code of 0. For example:

exec { “/bin/echo root >> /usr/lib/cron/cron.allow”:
path => “/usr/bin:/usr/sbin:/bin”,
unless => “grep root /usr/lib/cron/cron.allow 2>/dev/null”
}

This would add `root` to the cron.allow file (on Solaris) unless
`grep` determines it’s already there.

Note that this command follows the same rules as the main command,
which is to say that it must be fully qualified if the path is not set.
It also uses the same provider as the main command, so any behavior
that differs by provider will match.

user
: The user to run the command as. Note that if you
use this then any error output is not currently captured. This
is because of a bug within Ruby. If you are using Puppet to
create this user, the exec will automatically require the user,
as long as it is specified by name.

Please note that the $HOME environment variable is not automatically set
when using this attribute.
—————-

### file

Manages files, including their content, ownership, and permissions.

The `file` type can manage normal files, directories, and symlinks; the
type should be specified in the `ensure` attribute.

File contents can be managed directly with the `content` attribute, or
downloaded from a remote source using the `source` attribute; the latter
can also be used to recursively serve directories (when the `recurse`
attribute is set to `true` or `local`). On Windows, note that file
contents are managed in binary mode; Puppet never automatically translates
line endings.

**Autorequires:** If Puppet is managing the user or group that owns a
file, the file resource will autorequire them. If Puppet is managing any
parent directories of a file, the file resource will autorequire them.

#### Features

– *manages_symlinks*: The provider can manage symbolic links.
Provider | manages_symlinks |
——– | —————- |
posix | *X* |
windows | *X* |

#### Parameters
backup
: Whether (and how) file content should be backed up before being replaced.
This attribute works best as a resource default in the site manifest
(`File { backup => main }`), so it can affect all file resources.

* If set to `false`, file content won’t be backed up.
* If set to a string beginning with `.` (e.g., `.puppet-bak`), Puppet will
use copy the file in the same directory with that value as the extension
of the backup. (A value of `true` is a synonym for `.puppet-bak`.)
* If set to any other string, Puppet will try to back up to a filebucket
with that title. See the `filebucket` resource type for more details.
(This is the preferred method for backup, since it can be centralized
and queried.)

Default value: `puppet`, which backs up to a filebucket of the same name.
(Puppet automatically creates a **local** filebucket named `puppet` if one
doesn’t already exist.)

Backing up to a local filebucket isn’t particularly useful. If you want
to make organized use of backups, you will generally want to use the
puppet master server’s filebucket service. This requires declaring a
filebucket resource and a resource default for the `backup` attribute
in site.pp:

# /etc/puppet/manifests/site.pp
filebucket { ‘main’:
path => false, # This is required for remote filebuckets.
server => ‘puppet.example.com’, # Optional; defaults to the configured puppet master.
}

File { backup => main, }

If you are using multiple puppet master servers, you will want to
centralize the contents of the filebucket. Either configure your load
balancer to direct all filebucket traffic to a single master, or use
something like an out-of-band rsync task to synchronize the content on all
masters.

checksum
: The checksum type to use when determining whether to replace a file’s contents.

The default checksum type is md5.

Valid values are `md5`, `md5lite`, `sha256`, `sha256lite`, `mtime`, `ctime`, `none`.

content
: The desired contents of a file, as a string. This attribute is mutually
exclusive with `source` and `target`.

Newlines and tabs can be specified in double-quoted strings using
standard escaped syntax — \n for a newline, and \t for a tab.

With very small files, you can construct content strings directly in
the manifest…

define resolve(nameserver1, nameserver2, domain, search) {
$str = “search $search
domain $domain
nameserver $nameserver1
nameserver $nameserver2

file { “/etc/resolv.conf”:
content => “$str”,
}
}

…but for larger files, this attribute is more useful when combined with the
[template](http://docs.puppetlabs.com/references/latest/function.html#template)
or [file](http://docs.puppetlabs.com/references/latest/function.html#file)
function.

ctime
: A read-only state to check the file ctime. On most modern \*nix-like
systems, this is the time of the most recent change to the owner, group,
permissions, or content of the file.

ensure
: Whether the file should exist, and if so what kind of file it should be.
Possible values are `present`, `absent`, `file`, `directory`, and `link`.

* `present` will accept any form of file existence, and will create a
normal file if the file is missing. (The file will have no content
unless the `content` or `source` attribute is used.)
* `absent` will make sure the file doesn’t exist, deleting it
if necessary.
* `file` will make sure it’s a normal file, and enables use of the
`content` or `source` attribute.
* `directory` will make sure it’s a directory, and enables use of the
`source`, `recurse`, `recurselimit`, `ignore`, and `purge` attributes.
* `link` will make sure the file is a symlink, and **requires** that you
also set the `target` attribute. Symlinks are supported on all Posix
systems and on Windows Vista / 2008 and higher. On Windows, managing
symlinks requires puppet agent’s user account to have the “Create
Symbolic Links” privilege; this can be configured in the “User Rights
Assignment” section in the Windows policy editor. By default, puppet
agent runs as the Administrator account, which does have this privilege.

Puppet avoids destroying directories unless the `force` attribute is set
to `true`. This means that if a file is currently a directory, setting
`ensure` to anything but `directory` or `present` will cause Puppet to
skip managing the resource and log either a notice or an error.

There is one other non-standard value for `ensure`. If you specify the
path to another file as the ensure value, it is equivalent to specifying
`link` and using that path as the `target`:

# Equivalent resources:

file { “/etc/inetd.conf”:
ensure => “/etc/inet/inetd.conf”,
}

file { “/etc/inetd.conf”:
ensure => link,
target => “/etc/inet/inetd.conf”,
}

However, we recommend using `link` and `target` explicitly, since this
behavior can be harder to read.

Valid values are `absent` (also called `false`), `file`, `present`, `directory`, `link`. Values can match `/./`.

force
: Perform the file operation even if it will destroy one or more directories.
You must use `force` in order to:

* `purge` subdirectories
* Replace directories with files or links
* Remove a directory when `ensure => absent`

Valid values are `true`, `false`, `yes`, `no`.

group
: Which group should own the file. Argument can be either a group
name or a group ID.

On Windows, a user (such as “Administrator”) can be set as a file’s group
and a group (such as “Administrators”) can be set as a file’s owner;
however, a file’s owner and group shouldn’t be the same. (If the owner
is also the group, files with modes like `0640` will cause log churn, as
they will always appear out of sync.)

ignore
: A parameter which omits action on files matching
specified patterns during recursion. Uses Ruby’s builtin globbing
engine, so shell metacharacters are fully supported, e.g. `[a-z]*`.
Matches that would descend into the directory structure are ignored,
e.g., `*/*`.

links
: How to handle links during file actions. During file copying,
`follow` will copy the target file instead of the link, `manage`
will copy the link itself, and `ignore` will just pass it by.
When not copying, `manage` and `ignore` behave equivalently
(because you cannot really ignore links entirely during local
recursion), and `follow` will manage the file to which the link points.

Valid values are `follow`, `manage`.

mode
: The desired permissions mode for the file, in symbolic or numeric
notation. This value should be specified as a quoted string; do not use
un-quoted numbers to represent file modes.

The `file` type uses traditional Unix permission schemes and translates
them to equivalent permissions for systems which represent permissions
differently, including Windows. For detailed ACL controls on Windows,
you can leave `mode` unmanaged and use
[the puppetlabs/acl module.](https://forge.puppetlabs.com/puppetlabs/acl)

Numeric modes should use the standard four-digit octal notation of
`<setuid/setgid/sticky><owner><group><other>` (e.g. 0644). Each of the
“owner,” “group,” and “other” digits should be a sum of the
permissions for that class of users, where read = 4, write = 2, and
execute/search = 1. When setting numeric permissions for
directories, Puppet sets the search permission wherever the read
permission is set.

Symbolic modes should be represented as a string of comma-separated
permission clauses, in the form `<who><op><perm>`:

* “Who” should be u (user), g (group), o (other), and/or a (all)
* “Op” should be = (set exact permissions), + (add select permissions),
or – (remove select permissions)
* “Perm” should be one or more of:
* r (read)
* w (write)
* x (execute/search)
* t (sticky)
* s (setuid/setgid)
* X (execute/search if directory or if any one user can execute)
* u (user’s current permissions)
* g (group’s current permissions)
* o (other’s current permissions)

Thus, mode `0664` could be represented symbolically as either `a=r,ug+w`
or `ug=rw,o=r`. However, symbolic modes are more expressive than numeric
modes: a mode only affects the specified bits, so `mode => ‘ug+w’` will
set the user and group write bits, without affecting any other bits.

See the manual page for GNU or BSD `chmod` for more details
on numeric and symbolic modes.

On Windows, permissions are translated as follows:

* Owner and group names are mapped to Windows SIDs
* The “other” class of users maps to the “Everyone” SID
* The read/write/execute permissions map to the `FILE_GENERIC_READ`,
`FILE_GENERIC_WRITE`, and `FILE_GENERIC_EXECUTE` access rights; a
file’s owner always has the `FULL_CONTROL` right
* “Other” users can’t have any permissions a file’s group lacks,
and its group can’t have any permissions its owner lacks; that is, 0644
is an acceptable mode, but 0464 is not.

mtime
: A read-only state to check the file mtime. On \*nix-like systems, this
is the time of the most recent change to the content of the file.

owner
: The user to whom the file should belong. Argument can be a user name or a
user ID.

On Windows, a group (such as “Administrators”) can be set as a file’s owner
and a user (such as “Administrator”) can be set as a file’s group; however,
a file’s owner and group shouldn’t be the same. (If the owner is also
the group, files with modes like `0640` will cause log churn, as they
will always appear out of sync.)

path
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The path to the file to manage. Must be fully qualified.

On Windows, the path should include the drive letter and should use `/` as
the separator character (rather than `\\`).

provider
: The specific backend to use for this `file`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

posix
: Uses POSIX functionality to manage file ownership and permissions.

* Supported features: `manages_symlinks`.

windows
: Uses Microsoft Windows functionality to manage file ownership and permissions.

* Supported features: `manages_symlinks`.

purge
: Whether unmanaged files should be purged. This option only makes
sense when `ensure => directory` and `recurse => true`.

* When recursively duplicating an entire directory with the `source`
attribute, `purge => true` will automatically purge any files
that are not in the source directory.
* When managing files in a directory as individual resources,
setting `purge => true` will purge any files that aren’t being
specifically managed.

If you have a filebucket configured, the purged files will be uploaded,
but if you do not, this will destroy data.

Unless `force => true` is set, purging will **not** delete directories,
although it will delete the files they contain.

If `recurselimit` is set and you aren’t using `force => true`, purging
will obey the recursion limit; files in any subdirectories deeper than the
limit will be treated as unmanaged and left alone.

Valid values are `true`, `false`, `yes`, `no`.

recurse
: Whether to recursively manage the _contents_ of a directory. This attribute
is only used when `ensure => directory` is set. The allowed values are:

* `false` — The default behavior. The contents of the directory will not be
automatically managed.
* `remote` — If the `source` attribute is set, Puppet will automatically
manage the contents of the source directory (or directories), ensuring
that equivalent files and directories exist on the target system and
that their contents match.

Using `remote` will disable the `purge` attribute, but results in faster
catalog application than `recurse => true`.

The `source` attribute is mandatory when `recurse => remote`.
* `true` — If the `source` attribute is set, this behaves similarly to
`recurse => remote`, automatically managing files from the source directory.

This also enables the `purge` attribute, which can delete unmanaged
files from a directory. See the description of `purge` for more details.

The `source` attribute is not mandatory when using `recurse => true`, so you
can enable purging in directories where all files are managed individually.

(Note: `inf` is a deprecated synonym for `true`.)

By default, setting recurse to `remote` or `true` will manage _all_
subdirectories. You can use the `recurselimit` attribute to limit the
recursion depth.

Valid values are `true`, `false`, `inf`, `remote`.

recurselimit
: How far Puppet should descend into subdirectories, when using
`ensure => directory` and either `recurse => true` or `recurse => remote`.
The recursion limit affects which files will be copied from the `source`
directory, as well as which files can be purged when `purge => true`.

Setting `recurselimit => 0` is the same as setting `recurse => false` —
Puppet will manage the directory, but all of its contents will be treated
as unmanaged.

Setting `recurselimit => 1` will manage files and directories that are
directly inside the directory, but will not manage the contents of any
subdirectories.

Setting `recurselimit => 2` will manage the direct contents of the
directory, as well as the contents of the _first_ level of subdirectories.

And so on — 3 will manage the contents of the second level of
subdirectories, etc.

Values can match `/^[0-9]+$/`.

replace
: Whether to replace a file or symlink that already exists on the local system but
whose content doesn’t match what the `source` or `content` attribute
specifies. Setting this to false allows file resources to initialize files
without overwriting future changes. Note that this only affects content;
Puppet will still manage ownership and permissions. Defaults to `true`.

Valid values are `true`, `false`, `yes`, `no`.

selinux_ignore_defaults
: If this is set then Puppet will not ask SELinux (via matchpathcon) to
supply defaults for the SELinux attributes (seluser, selrole,
seltype, and selrange). In general, you should leave this set at its
default and only set it to true when you need Puppet to not try to fix
SELinux labels automatically.

Valid values are `true`, `false`.

selrange
: What the SELinux range component of the context of the file should be.
Any valid SELinux range component is accepted. For example `s0` or
`SystemHigh`. If not specified it defaults to the value returned by
matchpathcon for the file, if any exists. Only valid on systems with
SELinux support enabled and that have support for MCS (Multi-Category
Security).

selrole
: What the SELinux role component of the context of the file should be.
Any valid SELinux role component is accepted. For example `role_r`.
If not specified it defaults to the value returned by matchpathcon for
the file, if any exists. Only valid on systems with SELinux support
enabled.

seltype
: What the SELinux type component of the context of the file should be.
Any valid SELinux type component is accepted. For example `tmp_t`.
If not specified it defaults to the value returned by matchpathcon for
the file, if any exists. Only valid on systems with SELinux support
enabled.

seluser
: What the SELinux user component of the context of the file should be.
Any valid SELinux user component is accepted. For example `user_u`.
If not specified it defaults to the value returned by matchpathcon for
the file, if any exists. Only valid on systems with SELinux support
enabled.

show_diff
: Whether to display differences when the file changes, defaulting to
true. This parameter is useful for files that may contain passwords or
other secret data, which might otherwise be included in Puppet reports or
other insecure outputs. If the global `show_diff` setting
is false, then no diffs will be shown even if this parameter is true.

Valid values are `true`, `false`, `yes`, `no`.

source
: A source file, which will be copied into place on the local system.
Values can be URIs pointing to remote files, or fully qualified paths to
files available on the local system (including files on NFS shares or
Windows mapped drives). This attribute is mutually exclusive with
`content` and `target`.

The available URI schemes are *puppet* and *file*. *Puppet*
URIs will retrieve files from Puppet’s built-in file server, and are
usually formatted as:

`puppet:///modules/name_of_module/filename`

This will fetch a file from a module on the puppet master (or from a
local module when using puppet apply). Given a `modulepath` of
`/etc/puppetlabs/puppet/modules`, the example above would resolve to
`/etc/puppetlabs/puppet/modules/name_of_module/files/filename`.

Unlike `content`, the `source` attribute can be used to recursively copy
directories if the `recurse` attribute is set to `true` or `remote`. If
a source directory contains symlinks, use the `links` attribute to
specify whether to recreate links or follow them.

Multiple `source` values can be specified as an array, and Puppet will
use the first source that exists. This can be used to serve different
files to different system types:

file { “/etc/nfs.conf”:
source => [
“puppet:///modules/nfs/conf.$host”,
“puppet:///modules/nfs/conf.$operatingsystem”,
“puppet:///modules/nfs/conf”
]
}

Alternately, when serving directories recursively, multiple sources can
be combined by setting the `sourceselect` attribute to `all`.

source_permissions
: Whether (and how) Puppet should copy owner, group, and mode permissions from
the `source` to `file` resources when the permissions are not explicitly
specified. (In all cases, explicit permissions will take precedence.)
Valid values are `use`, `use_when_creating`, and `ignore`:

* `use` (the default) will cause Puppet to apply the owner, group,
and mode from the `source` to any files it is managing.
* `use_when_creating` will only apply the owner, group, and mode from the
`source` when creating a file; existing files will not have their permissions
overwritten.
* `ignore` will never apply the owner, group, or mode from the `source` when
managing a file. When creating new files without explicit permissions,
the permissions they receive will depend on platform-specific behavior.
On POSIX, Puppet will use the umask of the user it is running as. On
Windows, Puppet will use the default DACL associated with the user it is
running as.

Valid values are `use`, `use_when_creating`, `ignore`.

sourceselect
: Whether to copy all valid sources, or just the first one. This parameter
only affects recursive directory copies; by default, the first valid
source is the only one used, but if this parameter is set to `all`, then
all valid sources will have all of their contents copied to the local
system. If a given file exists in more than one source, the version from
the earliest source in the list will be used.

Valid values are `first`, `all`.

target
: The target for creating a link. Currently, symlinks are the
only type supported. This attribute is mutually exclusive with `source`
and `content`.

Symlink targets can be relative, as well as absolute:

# (Useful on Solaris)
file { “/etc/inetd.conf”:
ensure => link,
target => “inet/inetd.conf”,
}

Directories of symlinks can be served recursively by instead using the
`source` attribute, setting `ensure` to `directory`, and setting the
`links` attribute to `manage`.

Valid values are `notlink`. Values can match `/./`.

type
: A read-only state to check the file type.

validate_cmd
: A command for validating the file’s syntax before replacing it. If
Puppet would need to rewrite a file due to new `source` or `content`, it
will check the new content’s validity first. If validation fails, the file
resource will fail.

This command must have a fully qualified path, and should contain a
percent (`%`) token where it would expect an input file. It must exit `0`
if the syntax is correct, and non-zero otherwise. The command will be
run on the target system while applying the catalog, not on the puppet master.

Example:

file { ‘/etc/apache2/apache2.conf’:
content => ‘example’,
validate_cmd => ‘/usr/sbin/apache2 -t -f %’,
}

This would replace apache2.conf only if the test returned true.

Note that if a validation command requires a `%` as part of its text,
you can specify a different placeholder token with the
`validate_replacement` attribute.

validate_replacement
: The replacement string in a `validate_cmd` that will be replaced
with an input file name. Defaults to: `%`
—————-

### filebucket

A repository for storing and retrieving file content by MD5 checksum. Can
be local to each agent node, or centralized on a puppet master server. All
puppet masters provide a filebucket service that agent nodes can access
via HTTP, but you must declare a filebucket resource before any agents
will do so.

Filebuckets are used for the following features:

– **Content backups.** If the `file` type’s `backup` attribute is set to
the name of a filebucket, Puppet will back up the _old_ content whenever
it rewrites a file; see the documentation for the `file` type for more
details. These backups can be used for manual recovery of content, but
are more commonly used to display changes and differences in a tool like
Puppet Dashboard.
– **Content distribution.** The optional static compiler populates the
puppet master’s filebucket with the _desired_ content for each file,
then instructs the agent to retrieve the content for a specific
checksum. For more details,
[see the `static_compiler` section in the catalog indirection docs](http://docs.puppetlabs.com/references/latest/indirection.html#catalog).

To use a central filebucket for backups, you will usually want to declare
a filebucket resource and a resource default for the `backup` attribute
in site.pp:

# /etc/puppet/manifests/site.pp
filebucket { ‘main’:
path => false, # This is required for remote filebuckets.
server => ‘puppet.example.com’, # Optional; defaults to the configured puppet master.
}

File { backup => main, }

Puppet master servers automatically provide the filebucket service, so
this will work in a default configuration. If you have a heavily
restricted `auth.conf` file, you may need to allow access to the
`file_bucket_file` endpoint.

#### Parameters
name
: The name of the filebucket.

path
: The path to the _local_ filebucket; defaults to the value of the
`clientbucketdir` setting. To use a remote filebucket, you _must_ set
this attribute to `false`.

port
: The port on which the remote server is listening. Defaults to the
value of the `masterport` setting, which is usually 8140.

server
: The server providing the remote filebucket service. Defaults to the
value of the `server` setting (that is, the currently configured
puppet master server).

This setting is _only_ consulted if the `path` attribute is set to `false`.
—————-

### group

Manage groups. On most platforms this can only create groups.
Group membership must be managed on individual users.

On some platforms such as OS X, group membership is managed as an
attribute of the group, not the user record. Providers must have
the feature ‘manages_members’ to manage the ‘members’ property of
a group record.

#### Features

– *libuser*: Allows local groups to be managed on systems that also use some other remote NSS method of managing accounts.
– *manages_aix_lam*: The provider can manage AIX Loadable Authentication Module (LAM) system.
– *manages_members*: For directories where membership is an attribute of groups not users.
– *system_groups*: The provider allows you to create system groups with lower GIDs.
Provider | libuser | manages_aix_lam | manages_members | system_groups |
—————- | ——- | ————— | ————— | ————- |
aix | | *X* | *X* | |
directoryservice | | | *X* | |
groupadd | *X* | | | *X* |
ldap | | | | |
pw | | | *X* | |
windows_adsi | | | *X* | |

#### Parameters
allowdupe
: Whether to allow duplicate GIDs. Defaults to `false`.

Valid values are `true`, `false`, `yes`, `no`.

attribute_membership
: Whether specified attribute value pairs should be treated as the only attributes
of the user or whether they should merely
be treated as the minimum list.

Valid values are `inclusive`, `minimum`.

attributes
: Specify group AIX attributes in an array of `key=value` pairs.

Requires features manages_aix_lam.

auth_membership
: Whether the provider is authoritative for group membership. This
must be set to true to allow setting the group to no members with
`members => [],`.

Valid values are `true`, `false`, `yes`, `no`.

ensure
: Create or remove the group.

Valid values are `present`, `absent`.

forcelocal
: Forces the management of local accounts when accounts are also
being managed by some other NSS

Valid values are `true`, `false`, `yes`, `no`.

Requires features libuser.

gid
: The group ID. Must be specified numerically. If no group ID is
specified when creating a new group, then one will be chosen
automatically according to local system standards. This will likely
result in the same group having different GIDs on different systems,
which is not recommended.

On Windows, this property is read-only and will return the group’s security
identifier (SID).

ia_load_module
: The name of the I&A module to use to manage this user

Requires features manages_aix_lam.

members
: The members of the group. For directory services where group
membership is stored in the group objects, not the users. Use
with auth_membership to determine whether the specified members
are inclusive or the minimum.

Requires features manages_members.

name
: The group name. While naming limitations vary by operating system,
it is advisable to restrict names to the lowest common denominator,
which is a maximum of 8 characters beginning with a letter.

Note that Puppet considers group names to be case-sensitive, regardless
of the platform’s own rules; be sure to always use the same case when
referring to a given group.

provider
: The specific backend to use for this `group`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

aix
: Group management for AIX.

* Required binaries: `/usr/bin/chgroup`, `/usr/bin/mkgroup`, `/usr/sbin/lsgroup`, `/usr/sbin/rmgroup`.
* Default for `operatingsystem` == `aix`.
* Supported features: `manages_aix_lam`, `manages_members`.

directoryservice
: Group management using DirectoryService on OS X.

* Required binaries: `/usr/bin/dscl`.
* Default for `operatingsystem` == `darwin`.
* Supported features: `manages_members`.

groupadd
: Group management via `groupadd` and its ilk. The default for most platforms.

* Required binaries: `groupadd`, `groupdel`, `groupmod`, `lgroupadd`.
* Supported features: `libuser`, `system_groups`.

ldap
: Group management via LDAP.

This provider requires that you have valid values for all of the
LDAP-related settings in `puppet.conf`, including `ldapbase`. You will
almost definitely need settings for `ldapuser` and `ldappassword` in order
for your clients to write to LDAP.

Note that this provider will automatically generate a GID for you if you do
not specify one, but it is a potentially expensive operation, as it
iterates across all existing groups to pick the appropriate next one.

pw
: Group management via `pw` on FreeBSD and DragonFly BSD.

* Required binaries: `pw`.
* Default for `operatingsystem` == `freebsd, dragonfly`.
* Supported features: `manages_members`.

windows_adsi
: Local group management for Windows. Group members can be both users and groups.
Additionally, local groups can contain domain users.

* Default for `operatingsystem` == `windows`.
* Supported features: `manages_members`.

system
: Whether the group is a system group with lower GID.

Valid values are `true`, `false`, `yes`, `no`.
—————-

### host

Installs and manages host entries. For most systems, these
entries will just be in `/etc/hosts`, but some systems (notably OS X)
will have different solutions.

#### Parameters
comment
: A comment that will be attached to the line with a # character.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

host_aliases
: Any aliases the host might have. Multiple values must be
specified as an array.

ip
: The host’s IP address, IPv4 or IPv6.

name
: The host name.

provider
: The specific backend to use for this `host`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

parsed
:

target
: The file in which to store service information. Only used by
those providers that write to disk. On most systems this defaults to `/etc/hosts`.
—————-

### interface

This represents a router or switch interface. It is possible to manage
interface mode (access or trunking, native vlan and encapsulation) and
switchport characteristics (speed, duplex).

#### Parameters
allowed_trunk_vlans
: Allowed list of Vlans that this trunk can forward.

Valid values are `all`. Values can match `/./`.

description
: Interface description.

device_url
: The URL at which the router or switch can be reached.

duplex
: Interface duplex.

Valid values are `auto`, `full`, `half`.

encapsulation
: Interface switchport encapsulation.

Valid values are `none`, `dot1q`, `isl`.

ensure
: The basic property that the resource should be in.

Valid values are `present` (also called `no_shutdown`), `absent` (also called `shutdown`).

etherchannel
: Channel group this interface is part of.

Values can match `/^\d+/`.

ipaddress
: IP Address of this interface. Note that it might not be possible to set
an interface IP address; it depends on the interface type and device type.

Valid format of ip addresses are:

* IPV4, like 127.0.0.1
* IPV4/prefixlength like 127.0.1.1/24
* IPV6/prefixlength like FE80::21A:2FFF:FE30:ECF0/128
* an optional suffix for IPV6 addresses from this list: `eui-64`, `link-local`

It is also possible to supply an array of values.

mode
: Interface switchport mode.

Valid values are `access`, `trunk`.

name
: The interface’s name.

native_vlan
: Interface native vlan (for access mode only).

Values can match `/^\d+/`.

provider
: The specific backend to use for this `interface`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

cisco
: Cisco switch/router provider for interface.

speed
: Interface speed.

Valid values are `auto`. Values can match `/^\d+/`.
—————-

### k5login

Manage the `.k5login` file for a user. Specify the full path to
the `.k5login` file as the name, and an array of principals as the
`principals` attribute.

#### Parameters
ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

mode
: The desired permissions mode of the `.k5login` file. Defaults to `644`.

path
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The path to the `.k5login` file to manage. Must be fully qualified.

principals
: The principals present in the `.k5login` file. This should be specified as an array.

provider
: The specific backend to use for this `k5login`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

k5login
: The k5login provider is the only provider for the k5login
type.
—————-

### macauthorization

Manage the Mac OS X authorization database. See the
[Apple developer site](http://developer.apple.com/documentation/Security/Conceptual/Security_Overview/Security_Services/chapter_4_section_5.html)
for more information.

Note that authorization store directives with hyphens in their names have
been renamed to use underscores, as Puppet does not react well to hyphens
in identifiers.

**Autorequires:** If Puppet is managing the `/etc/authorization` file, each
macauthorization resource will autorequire it.

#### Parameters
allow_root
: Corresponds to `allow-root` in the authorization store. Specifies
whether a right should be allowed automatically if the requesting process
is running with `uid == 0`. AuthorizationServices defaults this attribute
to false if not specified.

Valid values are `true`, `false`.

auth_class
: Corresponds to `class` in the authorization store; renamed due
to ‘class’ being a reserved word in Puppet.

Valid values are `user`, `evaluate-mechanisms`, `allow`, `deny`, `rule`.

auth_type
: Type — this can be a `right` or a `rule`. The `comment` type has
not yet been implemented.

Valid values are `right`, `rule`.

authenticate_user
: Corresponds to `authenticate-user` in the authorization store.

Valid values are `true`, `false`.

comment
: The `comment` attribute for authorization resources.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

group
: A group which the user must authenticate as a member of. This
must be a single group.

k_of_n
: How large a subset of rule mechanisms must succeed for successful
authentication. If there are ‘n’ mechanisms, then ‘k’ (the integer value
of this parameter) mechanisms must succeed. The most common setting for
this parameter is `1`. If `k-of-n` is not set, then every mechanism —
that is, ‘n-of-n’ — must succeed.

mechanisms
: An array of suitable mechanisms.

name
: The name of the right or rule to be managed.
Corresponds to `key` in Authorization Services. The key is the name
of a rule. A key uses the same naming conventions as a right. The
Security Server uses a rule’s key to match the rule with a right.
Wildcard keys end with a ‘.’. The generic rule has an empty key value.
Any rights that do not match a specific rule use the generic rule.

provider
: The specific backend to use for this `macauthorization`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

macauthorization
: Manage Mac OS X authorization database rules and rights.

* Required binaries: `/usr/bin/security`, `/usr/bin/sw_vers`.
* Default for `operatingsystem` == `darwin`.

rule
: The rule(s) that this right refers to.

session_owner
: Whether the session owner automatically matches this rule or right.
Corresponds to `session-owner` in the authorization store.

Valid values are `true`, `false`.

shared
: Whether the Security Server should mark the credentials used to gain
this right as shared. The Security Server may use any shared credentials
to authorize this right. For maximum security, set sharing to false so
credentials stored by the Security Server for one application may not be
used by another application.

Valid values are `true`, `false`.

timeout
: The number of seconds in which the credential used by this rule will
expire. For maximum security where the user must authenticate every time,
set the timeout to 0. For minimum security, remove the timeout attribute
so the user authenticates only once per session.

tries
: The number of tries allowed.
—————-

### mailalias

Creates an email alias in the local alias database.

#### Parameters
ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

name
: The alias name.

provider
: The specific backend to use for this `mailalias`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

aliases
:

recipient
: Where email should be sent. Multiple values
should be specified as an array.

target
: The file in which to store the aliases. Only used by
those providers that write to disk.
—————-

### maillist

Manage email lists. This resource type can only create
and remove lists; it cannot currently reconfigure them.

#### Parameters
admin
: The email address of the administrator.

description
: The description of the mailing list.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`, `purged`.

mailserver
: The name of the host handling email for the list.

name
: The name of the email list.

password
: The admin password.

provider
: The specific backend to use for this `maillist`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

mailman
: * Required binaries: `/usr/lib/mailman/bin/list_lists`, `/usr/lib/mailman/bin/newlist`, `/usr/lib/mailman/bin/rmlist`, `/usr/lib/mailman/mail/mailman`.

webserver
: The name of the host providing web archives and the administrative interface.
—————-

### mcx

MCX object management using DirectoryService on OS X.

The default provider of this type merely manages the XML plist as
reported by the `dscl -mcxexport` command. This is similar to the
content property of the file type in Puppet.

The recommended method of using this type is to use Work Group Manager
to manage users and groups on the local computer, record the resulting
puppet manifest using the command `puppet resource mcx`, then deploy it
to other machines.

**Autorequires:** If Puppet is managing the user, group, or computer that these
MCX settings refer to, the MCX resource will autorequire that user, group, or computer.

#### Features

– *manages_content*: The provider can manage MCXSettings as a string.
Provider | manages_content |
———- | ————— |
mcxcontent | *X* |

#### Parameters
content
: The XML Plist used as the value of MCXSettings in DirectoryService.
This is the standard output from the system command:

dscl localhost -mcxexport /Local/Default/<ds_type>/ds_name

Note that `ds_type` is capitalized and plural in the dscl command.

Requires features manages_content.

ds_name
: The name to attach the MCX Setting to. (For example, `localhost`
when `ds_type => computer`.) This setting is not required, as it can be
automatically discovered when the resource name is parseable. (For
example, in `/Groups/admin`, `group` will be used as the dstype.)

ds_type
: The DirectoryService type this MCX setting attaches to.

Valid values are `user`, `group`, `computer`, `computerlist`.

ensure
: Create or remove the MCX setting.

Valid values are `present`, `absent`.

name
: The name of the resource being managed.
The default naming convention follows Directory Service paths:

/Computers/localhost
/Groups/admin
/Users/localadmin

The `ds_type` and `ds_name` type parameters are not necessary if the
default naming convention is followed.

provider
: The specific backend to use for this `mcx`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

mcxcontent
: MCX Settings management using DirectoryService on OS X.

This provider manages the entire MCXSettings attribute available
to some directory services nodes. This management is ‘all or nothing’
in that discrete application domain key value pairs are not managed
by this provider.

It is recommended to use WorkGroup Manager to configure Users, Groups,
Computers, or ComputerLists, then use ‘ralsh mcx’ to generate a puppet
manifest from the resulting configuration.

Original Author: Jeff McCune (mccune.jeff@gmail.com)

* Required binaries: `/usr/bin/dscl`.
* Default for `operatingsystem` == `darwin`.
* Supported features: `manages_content`.
—————-

### mount

Manages mounted filesystems, including putting mount
information into the mount table. The actual behavior depends
on the value of the ‘ensure’ parameter.

**Refresh:** `mount` resources can respond to refresh events (via
`notify`, `subscribe`, or the `~>` arrow). If a `mount` receives an event
from another resource **and** its `ensure` attribute is set to `mounted`,
Puppet will try to unmount then remount that filesystem.

**Autorequires:** If Puppet is managing any parents of a mount resource —
that is, other mount points higher up in the filesystem — the child
mount will autorequire them.

#### Features

– *refreshable*: The provider can remount the filesystem.
Provider | refreshable |
——– | ———– |
parsed | *X* |

#### Parameters
atboot
: Whether to mount the mount at boot. Not all platforms
support this.

blockdevice
: The device to fsck. This is property is only valid
on Solaris, and in most cases will default to the correct
value.

device
: The device providing the mount. This can be whatever
device is supporting by the mount, including network
devices or devices specified by UUID rather than device
path, depending on the operating system.

dump
: Whether to dump the mount. Not all platform support this.
Valid values are `1` or `0` (or `2` on FreeBSD). Default is `0`.

Values can match `/(0|1)/`.

ensure
: Control what to do with this mount. Set this attribute to
`unmounted` to make sure the filesystem is in the filesystem table
but not mounted (if the filesystem is currently mounted, it will be
unmounted). Set it to `absent` to unmount (if necessary) and remove
the filesystem from the fstab. Set to `mounted` to add it to the
fstab and mount it. Set to `present` to add to fstab but not change
mount/unmount status.

Valid values are `defined` (also called `present`), `unmounted`, `absent`, `mounted`.

fstype
: The mount type. Valid values depend on the
operating system. This is a required option.

name
: The mount path for the mount.

options
: Mount options for the mounts, comma-separated as they would appear
in the fstab on Linux. AIX options other than dev, nodename, or vfs may
be defined here. If specified, AIX options of account, boot, check, free,
mount, size, type, vol, log, and quota must be alphabetically sorted at
the end of the list.

pass
: The pass in which the mount is checked.

provider
: The specific backend to use for this `mount`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

parsed
: * Required binaries: `mount`, `umount`.
* Supported features: `refreshable`.

remounts
: Whether the mount can be remounted `mount -o remount`. If
this is false, then the filesystem will be unmounted and remounted
manually, which is prone to failure.

Valid values are `true`, `false`.

target
: The file in which to store the mount table. Only used by
those providers that write to disk.
—————-

### nagios_command

The Nagios type command. This resource type is autogenerated using the
model developed in Naginator, and all of the Nagios types are generated using the
same code and the same library.

This type generates Nagios configuration statements in Nagios-parseable configuration
files. By default, the statements will be added to `/etc/nagios/nagios_command.cfg`, but
you can send them to a different file by setting their `target` attribute.

You can purge Nagios resources using the `resources` type, but *only*
in the default file locations. This is an architectural limitation.

#### Parameters
command_line
: Nagios configuration file parameter.

command_name
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name of this nagios_command resource.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

group
: The desired group of the config file for this nagios_command resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

mode
: The desired mode of the config file for this nagios_command resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

owner
: The desired owner of the config file for this nagios_command resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

poller_tag
: Nagios configuration file parameter.

provider
: The specific backend to use for this `nagios_command`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

naginator
:

target
: The target.

use
: Nagios configuration file parameter.
—————-

### nagios_contact

The Nagios type contact. This resource type is autogenerated using the
model developed in Naginator, and all of the Nagios types are generated using the
same code and the same library.

This type generates Nagios configuration statements in Nagios-parseable configuration
files. By default, the statements will be added to `/etc/nagios/nagios_contact.cfg`, but
you can send them to a different file by setting their `target` attribute.

You can purge Nagios resources using the `resources` type, but *only*
in the default file locations. This is an architectural limitation.

#### Parameters
address1
: Nagios configuration file parameter.

address2
: Nagios configuration file parameter.

address3
: Nagios configuration file parameter.

address4
: Nagios configuration file parameter.

address5
: Nagios configuration file parameter.

address6
: Nagios configuration file parameter.

alias
: Nagios configuration file parameter.

can_submit_commands
: Nagios configuration file parameter.

contact_name
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name of this nagios_contact resource.

contactgroups
: Nagios configuration file parameter.

email
: Nagios configuration file parameter.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

group
: The desired group of the config file for this nagios_contact resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

host_notification_commands
: Nagios configuration file parameter.

host_notification_options
: Nagios configuration file parameter.

host_notification_period
: Nagios configuration file parameter.

host_notifications_enabled
: Nagios configuration file parameter.

mode
: The desired mode of the config file for this nagios_contact resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

owner
: The desired owner of the config file for this nagios_contact resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

pager
: Nagios configuration file parameter.

provider
: The specific backend to use for this `nagios_contact`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

naginator
:

register
: Nagios configuration file parameter.

retain_nonstatus_information
: Nagios configuration file parameter.

retain_status_information
: Nagios configuration file parameter.

service_notification_commands
: Nagios configuration file parameter.

service_notification_options
: Nagios configuration file parameter.

service_notification_period
: Nagios configuration file parameter.

service_notifications_enabled
: Nagios configuration file parameter.

target
: The target.

use
: Nagios configuration file parameter.
—————-

### nagios_contactgroup

The Nagios type contactgroup. This resource type is autogenerated using the
model developed in Naginator, and all of the Nagios types are generated using the
same code and the same library.

This type generates Nagios configuration statements in Nagios-parseable configuration
files. By default, the statements will be added to `/etc/nagios/nagios_contactgroup.cfg`, but
you can send them to a different file by setting their `target` attribute.

You can purge Nagios resources using the `resources` type, but *only*
in the default file locations. This is an architectural limitation.

#### Parameters
alias
: Nagios configuration file parameter.

contactgroup_members
: Nagios configuration file parameter.

contactgroup_name
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name of this nagios_contactgroup resource.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

group
: The desired group of the config file for this nagios_contactgroup resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

members
: Nagios configuration file parameter.

mode
: The desired mode of the config file for this nagios_contactgroup resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

owner
: The desired owner of the config file for this nagios_contactgroup resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

provider
: The specific backend to use for this `nagios_contactgroup`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

naginator
:

register
: Nagios configuration file parameter.

target
: The target.

use
: Nagios configuration file parameter.
—————-

### nagios_host

The Nagios type host. This resource type is autogenerated using the
model developed in Naginator, and all of the Nagios types are generated using the
same code and the same library.

This type generates Nagios configuration statements in Nagios-parseable configuration
files. By default, the statements will be added to `/etc/nagios/nagios_host.cfg`, but
you can send them to a different file by setting their `target` attribute.

You can purge Nagios resources using the `resources` type, but *only*
in the default file locations. This is an architectural limitation.

#### Parameters
action_url
: Nagios configuration file parameter.

active_checks_enabled
: Nagios configuration file parameter.

address
: Nagios configuration file parameter.

alias
: Nagios configuration file parameter.

business_impact
: Nagios configuration file parameter.

check_command
: Nagios configuration file parameter.

check_freshness
: Nagios configuration file parameter.

check_interval
: Nagios configuration file parameter.

check_period
: Nagios configuration file parameter.

contact_groups
: Nagios configuration file parameter.

contacts
: Nagios configuration file parameter.

display_name
: Nagios configuration file parameter.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

event_handler
: Nagios configuration file parameter.

event_handler_enabled
: Nagios configuration file parameter.

failure_prediction_enabled
: Nagios configuration file parameter.

first_notification_delay
: Nagios configuration file parameter.

flap_detection_enabled
: Nagios configuration file parameter.

flap_detection_options
: Nagios configuration file parameter.

freshness_threshold
: Nagios configuration file parameter.

group
: The desired group of the config file for this nagios_host resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

high_flap_threshold
: Nagios configuration file parameter.

host_name
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name of this nagios_host resource.

hostgroups
: Nagios configuration file parameter.

icon_image
: Nagios configuration file parameter.

icon_image_alt
: Nagios configuration file parameter.

initial_state
: Nagios configuration file parameter.

low_flap_threshold
: Nagios configuration file parameter.

max_check_attempts
: Nagios configuration file parameter.

mode
: The desired mode of the config file for this nagios_host resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

notes
: Nagios configuration file parameter.

notes_url
: Nagios configuration file parameter.

notification_interval
: Nagios configuration file parameter.

notification_options
: Nagios configuration file parameter.

notification_period
: Nagios configuration file parameter.

notifications_enabled
: Nagios configuration file parameter.

obsess_over_host
: Nagios configuration file parameter.

owner
: The desired owner of the config file for this nagios_host resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

parents
: Nagios configuration file parameter.

passive_checks_enabled
: Nagios configuration file parameter.

poller_tag
: Nagios configuration file parameter.

process_perf_data
: Nagios configuration file parameter.

provider
: The specific backend to use for this `nagios_host`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

naginator
:

realm
: Nagios configuration file parameter.

register
: Nagios configuration file parameter.

retain_nonstatus_information
: Nagios configuration file parameter.

retain_status_information
: Nagios configuration file parameter.

retry_interval
: Nagios configuration file parameter.

stalking_options
: Nagios configuration file parameter.

statusmap_image
: Nagios configuration file parameter.

target
: The target.

use
: Nagios configuration file parameter.

vrml_image
: Nagios configuration file parameter.
—————-

### nagios_hostdependency

The Nagios type hostdependency. This resource type is autogenerated using the
model developed in Naginator, and all of the Nagios types are generated using the
same code and the same library.

This type generates Nagios configuration statements in Nagios-parseable configuration
files. By default, the statements will be added to `/etc/nagios/nagios_hostdependency.cfg`, but
you can send them to a different file by setting their `target` attribute.

You can purge Nagios resources using the `resources` type, but *only*
in the default file locations. This is an architectural limitation.

#### Parameters
_naginator_name
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name of this nagios_hostdependency resource.

dependency_period
: Nagios configuration file parameter.

dependent_host_name
: Nagios configuration file parameter.

dependent_hostgroup_name
: Nagios configuration file parameter.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

execution_failure_criteria
: Nagios configuration file parameter.

group
: The desired group of the config file for this nagios_hostdependency resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

host_name
: Nagios configuration file parameter.

hostgroup_name
: Nagios configuration file parameter.

inherits_parent
: Nagios configuration file parameter.

mode
: The desired mode of the config file for this nagios_hostdependency resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

notification_failure_criteria
: Nagios configuration file parameter.

owner
: The desired owner of the config file for this nagios_hostdependency resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

provider
: The specific backend to use for this `nagios_hostdependency`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

naginator
:

register
: Nagios configuration file parameter.

target
: The target.

use
: Nagios configuration file parameter.
—————-

### nagios_hostescalation

The Nagios type hostescalation. This resource type is autogenerated using the
model developed in Naginator, and all of the Nagios types are generated using the
same code and the same library.

This type generates Nagios configuration statements in Nagios-parseable configuration
files. By default, the statements will be added to `/etc/nagios/nagios_hostescalation.cfg`, but
you can send them to a different file by setting their `target` attribute.

You can purge Nagios resources using the `resources` type, but *only*
in the default file locations. This is an architectural limitation.

#### Parameters
_naginator_name
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name of this nagios_hostescalation resource.

contact_groups
: Nagios configuration file parameter.

contacts
: Nagios configuration file parameter.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

escalation_options
: Nagios configuration file parameter.

escalation_period
: Nagios configuration file parameter.

first_notification
: Nagios configuration file parameter.

group
: The desired group of the config file for this nagios_hostescalation resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

host_name
: Nagios configuration file parameter.

hostgroup_name
: Nagios configuration file parameter.

last_notification
: Nagios configuration file parameter.

mode
: The desired mode of the config file for this nagios_hostescalation resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

notification_interval
: Nagios configuration file parameter.

owner
: The desired owner of the config file for this nagios_hostescalation resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

provider
: The specific backend to use for this `nagios_hostescalation`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

naginator
:

register
: Nagios configuration file parameter.

target
: The target.

use
: Nagios configuration file parameter.
—————-

### nagios_hostextinfo

The Nagios type hostextinfo. This resource type is autogenerated using the
model developed in Naginator, and all of the Nagios types are generated using the
same code and the same library.

This type generates Nagios configuration statements in Nagios-parseable configuration
files. By default, the statements will be added to `/etc/nagios/nagios_hostextinfo.cfg`, but
you can send them to a different file by setting their `target` attribute.

You can purge Nagios resources using the `resources` type, but *only*
in the default file locations. This is an architectural limitation.

#### Parameters
ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

group
: The desired group of the config file for this nagios_hostextinfo resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

host_name
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name of this nagios_hostextinfo resource.

icon_image
: Nagios configuration file parameter.

icon_image_alt
: Nagios configuration file parameter.

mode
: The desired mode of the config file for this nagios_hostextinfo resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

notes
: Nagios configuration file parameter.

notes_url
: Nagios configuration file parameter.

owner
: The desired owner of the config file for this nagios_hostextinfo resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

provider
: The specific backend to use for this `nagios_hostextinfo`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

naginator
:

register
: Nagios configuration file parameter.

statusmap_image
: Nagios configuration file parameter.

target
: The target.

use
: Nagios configuration file parameter.

vrml_image
: Nagios configuration file parameter.
—————-

### nagios_hostgroup

The Nagios type hostgroup. This resource type is autogenerated using the
model developed in Naginator, and all of the Nagios types are generated using the
same code and the same library.

This type generates Nagios configuration statements in Nagios-parseable configuration
files. By default, the statements will be added to `/etc/nagios/nagios_hostgroup.cfg`, but
you can send them to a different file by setting their `target` attribute.

You can purge Nagios resources using the `resources` type, but *only*
in the default file locations. This is an architectural limitation.

#### Parameters
action_url
: Nagios configuration file parameter.

alias
: Nagios configuration file parameter.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

group
: The desired group of the config file for this nagios_hostgroup resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

hostgroup_members
: Nagios configuration file parameter.

hostgroup_name
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name of this nagios_hostgroup resource.

members
: Nagios configuration file parameter.

mode
: The desired mode of the config file for this nagios_hostgroup resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

notes
: Nagios configuration file parameter.

notes_url
: Nagios configuration file parameter.

owner
: The desired owner of the config file for this nagios_hostgroup resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

provider
: The specific backend to use for this `nagios_hostgroup`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

naginator
:

realm
: Nagios configuration file parameter.

register
: Nagios configuration file parameter.

target
: The target.

use
: Nagios configuration file parameter.
—————-

### nagios_service

The Nagios type service. This resource type is autogenerated using the
model developed in Naginator, and all of the Nagios types are generated using the
same code and the same library.

This type generates Nagios configuration statements in Nagios-parseable configuration
files. By default, the statements will be added to `/etc/nagios/nagios_service.cfg`, but
you can send them to a different file by setting their `target` attribute.

You can purge Nagios resources using the `resources` type, but *only*
in the default file locations. This is an architectural limitation.

#### Parameters
_naginator_name
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name of this nagios_service resource.

action_url
: Nagios configuration file parameter.

active_checks_enabled
: Nagios configuration file parameter.

business_impact
: Nagios configuration file parameter.

check_command
: Nagios configuration file parameter.

check_freshness
: Nagios configuration file parameter.

check_interval
: Nagios configuration file parameter.

check_period
: Nagios configuration file parameter.

contact_groups
: Nagios configuration file parameter.

contacts
: Nagios configuration file parameter.

display_name
: Nagios configuration file parameter.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

event_handler
: Nagios configuration file parameter.

event_handler_enabled
: Nagios configuration file parameter.

failure_prediction_enabled
: Nagios configuration file parameter.

first_notification_delay
: Nagios configuration file parameter.

flap_detection_enabled
: Nagios configuration file parameter.

flap_detection_options
: Nagios configuration file parameter.

freshness_threshold
: Nagios configuration file parameter.

group
: The desired group of the config file for this nagios_service resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

high_flap_threshold
: Nagios configuration file parameter.

host_name
: Nagios configuration file parameter.

hostgroup_name
: Nagios configuration file parameter.

icon_image
: Nagios configuration file parameter.

icon_image_alt
: Nagios configuration file parameter.

initial_state
: Nagios configuration file parameter.

is_volatile
: Nagios configuration file parameter.

low_flap_threshold
: Nagios configuration file parameter.

max_check_attempts
: Nagios configuration file parameter.

mode
: The desired mode of the config file for this nagios_service resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

normal_check_interval
: Nagios configuration file parameter.

notes
: Nagios configuration file parameter.

notes_url
: Nagios configuration file parameter.

notification_interval
: Nagios configuration file parameter.

notification_options
: Nagios configuration file parameter.

notification_period
: Nagios configuration file parameter.

notifications_enabled
: Nagios configuration file parameter.

obsess_over_service
: Nagios configuration file parameter.

owner
: The desired owner of the config file for this nagios_service resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

parallelize_check
: Nagios configuration file parameter.

passive_checks_enabled
: Nagios configuration file parameter.

poller_tag
: Nagios configuration file parameter.

process_perf_data
: Nagios configuration file parameter.

provider
: The specific backend to use for this `nagios_service`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

naginator
:

register
: Nagios configuration file parameter.

retain_nonstatus_information
: Nagios configuration file parameter.

retain_status_information
: Nagios configuration file parameter.

retry_check_interval
: Nagios configuration file parameter.

retry_interval
: Nagios configuration file parameter.

service_description
: Nagios configuration file parameter.

servicegroups
: Nagios configuration file parameter.

stalking_options
: Nagios configuration file parameter.

target
: The target.

use
: Nagios configuration file parameter.
—————-

### nagios_servicedependency

The Nagios type servicedependency. This resource type is autogenerated using the
model developed in Naginator, and all of the Nagios types are generated using the
same code and the same library.

This type generates Nagios configuration statements in Nagios-parseable configuration
files. By default, the statements will be added to `/etc/nagios/nagios_servicedependency.cfg`, but
you can send them to a different file by setting their `target` attribute.

You can purge Nagios resources using the `resources` type, but *only*
in the default file locations. This is an architectural limitation.

#### Parameters
_naginator_name
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name of this nagios_servicedependency resource.

dependency_period
: Nagios configuration file parameter.

dependent_host_name
: Nagios configuration file parameter.

dependent_hostgroup_name
: Nagios configuration file parameter.

dependent_service_description
: Nagios configuration file parameter.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

execution_failure_criteria
: Nagios configuration file parameter.

group
: The desired group of the config file for this nagios_servicedependency resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

host_name
: Nagios configuration file parameter.

hostgroup_name
: Nagios configuration file parameter.

inherits_parent
: Nagios configuration file parameter.

mode
: The desired mode of the config file for this nagios_servicedependency resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

notification_failure_criteria
: Nagios configuration file parameter.

owner
: The desired owner of the config file for this nagios_servicedependency resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

provider
: The specific backend to use for this `nagios_servicedependency`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

naginator
:

register
: Nagios configuration file parameter.

service_description
: Nagios configuration file parameter.

target
: The target.

use
: Nagios configuration file parameter.
—————-

### nagios_serviceescalation

The Nagios type serviceescalation. This resource type is autogenerated using the
model developed in Naginator, and all of the Nagios types are generated using the
same code and the same library.

This type generates Nagios configuration statements in Nagios-parseable configuration
files. By default, the statements will be added to `/etc/nagios/nagios_serviceescalation.cfg`, but
you can send them to a different file by setting their `target` attribute.

You can purge Nagios resources using the `resources` type, but *only*
in the default file locations. This is an architectural limitation.

#### Parameters
_naginator_name
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name of this nagios_serviceescalation resource.

contact_groups
: Nagios configuration file parameter.

contacts
: Nagios configuration file parameter.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

escalation_options
: Nagios configuration file parameter.

escalation_period
: Nagios configuration file parameter.

first_notification
: Nagios configuration file parameter.

group
: The desired group of the config file for this nagios_serviceescalation resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

host_name
: Nagios configuration file parameter.

hostgroup_name
: Nagios configuration file parameter.

last_notification
: Nagios configuration file parameter.

mode
: The desired mode of the config file for this nagios_serviceescalation resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

notification_interval
: Nagios configuration file parameter.

owner
: The desired owner of the config file for this nagios_serviceescalation resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

provider
: The specific backend to use for this `nagios_serviceescalation`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

naginator
:

register
: Nagios configuration file parameter.

service_description
: Nagios configuration file parameter.

servicegroup_name
: Nagios configuration file parameter.

target
: The target.

use
: Nagios configuration file parameter.
—————-

### nagios_serviceextinfo

The Nagios type serviceextinfo. This resource type is autogenerated using the
model developed in Naginator, and all of the Nagios types are generated using the
same code and the same library.

This type generates Nagios configuration statements in Nagios-parseable configuration
files. By default, the statements will be added to `/etc/nagios/nagios_serviceextinfo.cfg`, but
you can send them to a different file by setting their `target` attribute.

You can purge Nagios resources using the `resources` type, but *only*
in the default file locations. This is an architectural limitation.

#### Parameters
_naginator_name
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name of this nagios_serviceextinfo resource.

action_url
: Nagios configuration file parameter.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

group
: The desired group of the config file for this nagios_serviceextinfo resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

host_name
: Nagios configuration file parameter.

icon_image
: Nagios configuration file parameter.

icon_image_alt
: Nagios configuration file parameter.

mode
: The desired mode of the config file for this nagios_serviceextinfo resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

notes
: Nagios configuration file parameter.

notes_url
: Nagios configuration file parameter.

owner
: The desired owner of the config file for this nagios_serviceextinfo resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

provider
: The specific backend to use for this `nagios_serviceextinfo`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

naginator
:

register
: Nagios configuration file parameter.

service_description
: Nagios configuration file parameter.

target
: The target.

use
: Nagios configuration file parameter.
—————-

### nagios_servicegroup

The Nagios type servicegroup. This resource type is autogenerated using the
model developed in Naginator, and all of the Nagios types are generated using the
same code and the same library.

This type generates Nagios configuration statements in Nagios-parseable configuration
files. By default, the statements will be added to `/etc/nagios/nagios_servicegroup.cfg`, but
you can send them to a different file by setting their `target` attribute.

You can purge Nagios resources using the `resources` type, but *only*
in the default file locations. This is an architectural limitation.

#### Parameters
action_url
: Nagios configuration file parameter.

alias
: Nagios configuration file parameter.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

group
: The desired group of the config file for this nagios_servicegroup resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

members
: Nagios configuration file parameter.

mode
: The desired mode of the config file for this nagios_servicegroup resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

notes
: Nagios configuration file parameter.

notes_url
: Nagios configuration file parameter.

owner
: The desired owner of the config file for this nagios_servicegroup resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

provider
: The specific backend to use for this `nagios_servicegroup`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

naginator
:

register
: Nagios configuration file parameter.

servicegroup_members
: Nagios configuration file parameter.

servicegroup_name
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name of this nagios_servicegroup resource.

target
: The target.

use
: Nagios configuration file parameter.
—————-

### nagios_timeperiod

The Nagios type timeperiod. This resource type is autogenerated using the
model developed in Naginator, and all of the Nagios types are generated using the
same code and the same library.

This type generates Nagios configuration statements in Nagios-parseable configuration
files. By default, the statements will be added to `/etc/nagios/nagios_timeperiod.cfg`, but
you can send them to a different file by setting their `target` attribute.

You can purge Nagios resources using the `resources` type, but *only*
in the default file locations. This is an architectural limitation.

#### Parameters
alias
: Nagios configuration file parameter.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

exclude
: Nagios configuration file parameter.

friday
: Nagios configuration file parameter.

group
: The desired group of the config file for this nagios_timeperiod resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

mode
: The desired mode of the config file for this nagios_timeperiod resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

monday
: Nagios configuration file parameter.

owner
: The desired owner of the config file for this nagios_timeperiod resource.

NOTE: If the target file is explicitly managed by a file resource in your manifest,
this parameter has no effect. If a parent directory of the target is managed by
a recursive file resource, this limitation does not apply (i.e., this parameter
takes precedence, and if purge is used, the target file is exempt).

provider
: The specific backend to use for this `nagios_timeperiod`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

naginator
:

register
: Nagios configuration file parameter.

saturday
: Nagios configuration file parameter.

sunday
: Nagios configuration file parameter.

target
: The target.

thursday
: Nagios configuration file parameter.

timeperiod_name
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name of this nagios_timeperiod resource.

tuesday
: Nagios configuration file parameter.

use
: Nagios configuration file parameter.

wednesday
: Nagios configuration file parameter.
—————-

### notify

Sends an arbitrary message to the agent run-time log.

#### Parameters
message
: The message to be sent to the log.

name
: An arbitrary tag for your own reference; the name of the message.

withpath
: Whether to show the full object path. Defaults to false.

Valid values are `true`, `false`.
—————-

### package

Manage packages. There is a basic dichotomy in package
support right now: Some package types (e.g., yum and apt) can
retrieve their own package files, while others (e.g., rpm and sun)
cannot. For those package formats that cannot retrieve their own files,
you can use the `source` parameter to point to the correct file.

Puppet will automatically guess the packaging format that you are
using based on the platform you are on, but you can override it
using the `provider` parameter; each provider defines what it
requires in order to function, and you must meet those requirements
to use a given provider.

**Autorequires:** If Puppet is managing the files specified as a
package’s `adminfile`, `responsefile`, or `source`, the package
resource will autorequire those files.

#### Features

– *holdable*: The provider is capable of placing packages on hold such that they are not automatically upgraded as a result of other package dependencies unless explicit action is taken by a user or another package. Held is considered a superset of installed.
– *install_options*: The provider accepts options to be passed to the installer command.
– *installable*: The provider can install packages.
– *package_settings*: The provider accepts package_settings to be ensured for the given package. The meaning and format of these settings is provider-specific.
– *purgeable*: The provider can purge packages. This generally means that all traces of the package are removed, including existing configuration files. This feature is thus destructive and should be used with the utmost care.
– *uninstall_options*: The provider accepts options to be passed to the uninstaller command.
– *uninstallable*: The provider can uninstall packages.
– *upgradeable*: The provider can upgrade to the latest version of a package. This feature is used by specifying `latest` as the desired value for the package.
– *versionable*: The provider is capable of interrogating the package database for installed version(s), and can select which out of a set of available versions of a package to install if asked.
– *virtual_packages*: The provider accepts virtual package names for install and uninstall.
Provider | holdable | install_options | installable | package_settings | purgeable | uninstall_options | uninstallable | upgradeable | versionable | virtual_packages |
———– | ——– | ————— | ———– | —————- | ——— | —————– | ————- | ———– | ———– | —————- |
aix | | | *X* | | | | *X* | *X* | *X* | |
appdmg | | | *X* | | | | | | | |
apple | | | *X* | | | | | | | |
apt | *X* | *X* | *X* | | *X* | | *X* | *X* | *X* | |
aptitude | *X* | | *X* | | *X* | | *X* | *X* | *X* | |
aptrpm | | | *X* | | *X* | | *X* | *X* | *X* | |
blastwave | | | *X* | | | | *X* | *X* | | |
dpkg | *X* | | *X* | | *X* | | *X* | *X* | | |
fink | *X* | | *X* | | *X* | | *X* | *X* | *X* | |
freebsd | | | *X* | | *X* | | *X* | *X* | | |
gem | | *X* | *X* | | | | *X* | *X* | *X* | |
hpux | | | *X* | | | | *X* | | | |
macports | | | *X* | | | | *X* | *X* | *X* | |
msi | | *X* | *X* | | | *X* | *X* | | | |
nim | | | *X* | | | | *X* | *X* | *X* | |
openbsd | | *X* | *X* | | *X* | *X* | *X* | *X* | *X* | |
opkg | | | *X* | | | | *X* | *X* | | |
pacman | | *X* | *X* | | | *X* | *X* | *X* | | |
pip | | | *X* | | | | *X* | *X* | *X* | |
pkg | *X* | | *X* | | | | *X* | *X* | *X* | |
pkgdmg | | | *X* | | | | | | | |
pkgin | | | *X* | | | | *X* | *X* | *X* | |
pkgutil | | | *X* | | | | *X* | *X* | | |
portage | | | *X* | | | | *X* | *X* | *X* | |
ports | | | *X* | | *X* | | *X* | *X* | | |
portupgrade | | | *X* | | | | *X* | *X* | | |
rpm | | *X* | *X* | | | *X* | *X* | *X* | *X* | *X* |
rug | | | *X* | | | | *X* | *X* | *X* | |
sun | | *X* | *X* | | | | *X* | *X* | | |
sunfreeware | | | *X* | | | | *X* | *X* | | |
up2date | | | *X* | | | | *X* | *X* | | |
urpmi | | | *X* | | *X* | | *X* | *X* | *X* | |
windows | | *X* | *X* | | | *X* | *X* | | *X* | |
yum | | *X* | *X* | | *X* | | *X* | *X* | *X* | *X* |
zypper | | *X* | *X* | | | | *X* | *X* | *X* | *X* |

#### Parameters
adminfile
: A file containing package defaults for installing packages.

This attribute is only used on Solaris. Its value should be a path to a
local file stored on the target system. Solaris’s package tools expect
either an absolute file path or a relative path to a file in
`/var/sadm/install/admin`.

The value of `adminfile` will be passed directly to the `pkgadd` or
`pkgrm` command with the `-a <ADMINFILE>` option.

allow_virtual
: Specifies if virtual package names are allowed for install and uninstall.

Valid values are `true`, `false`, `yes`, `no`.

Requires features virtual_packages.

allowcdrom
: Tells apt to allow cdrom sources in the sources.list file.
Normally apt will bail if you try this.

Valid values are `true`, `false`.

category
: A read-only parameter set by the package.

configfiles
: Whether configfiles should be kept or replaced. Most packages
types do not support this parameter. Defaults to `keep`.

Valid values are `keep`, `replace`.

description
: A read-only parameter set by the package.

ensure
: What state the package should be in. On packaging systems that can
retrieve new packages on their own, you can choose which package to
retrieve by specifying a version number or `latest` as the ensure
value. On packaging systems that manage configuration files separately
from “normal” system files, you can uninstall config files by
specifying `purged` as the ensure value. This defaults to `installed`.

Valid values are `present` (also called `installed`), `absent`, `purged`, `held`, `latest`. Values can match `/./`.

flavor
: OpenBSD supports ‘flavors’, which are further specifications for
which type of package you want.

install_options
: An array of additional options to pass when installing a package. These
options are package-specific, and should be documented by the software
vendor. One commonly implemented option is `INSTALLDIR`:

package { ‘mysql’:
ensure => installed,
source => ‘N:/packages/mysql-5.5.16-winx64.msi’,
install_options => [ ‘/S’, { ‘INSTALLDIR’ => ‘C:\mysql-5.5’ } ],
}

Each option in the array can either be a string or a hash, where each
key and value pair are interpreted in a provider specific way. Each
option will automatically be quoted when passed to the install command.

On Windows, this is the **only** place in Puppet where backslash
separators should be used. Note that backslashes in double-quoted
strings _must_ be double-escaped and backslashes in single-quoted
strings _may_ be double-escaped.

Requires features install_options.

instance
: A read-only parameter set by the package.

name
: The package name. This is the name that the packaging
system uses internally, which is sometimes (especially on Solaris)
a name that is basically useless to humans. If you want to
abstract package installation, then you can use aliases to provide
a common name to packages:

# In the ‘openssl’ class
$ssl = $operatingsystem ? {
solaris => SMCossl,
default => openssl
}

# It is not an error to set an alias to the same value as the
# object name.
package { $ssl:
ensure => installed,
alias => openssl
}

. etc. .

$ssh = $operatingsystem ? {
solaris => SMCossh,
default => openssh
}

# Use the alias to specify a dependency, rather than
# having another selector to figure it out again.
package { $ssh:
ensure => installed,
alias => openssh,
require => Package[openssl]
}

package_settings
: Settings that can change the contents or configuration of a package.

The formatting and effects of package_settings are provider-specific; any
provider that implements them must explain how to use them in its
documentation. (Our general expectation is that if a package is
installed but its settings are out of sync, the provider should
re-install that package with the desired settings.)

An example of how package_settings could be used is FreeBSD’s port build
options — a future version of the provider could accept a hash of options,
and would reinstall the port if the installed version lacked the correct
settings.

package { ‘www/apache22’:
package_settings => { ‘SUEXEC’ => false }
}

Again, check the documentation of your platform’s package provider to see
the actual usage.

Requires features package_settings.

platform
: A read-only parameter set by the package.

provider
: The specific backend to use for this `package`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

aix
: Installation from an AIX software directory, using the AIX `installp`
command. The `source` parameter is required for this provider, and should
be set to the absolute path (on the puppet agent machine) of a directory
containing one or more BFF package files.

The `installp` command will generate a table of contents file (named `.toc`)
in this directory, and the `name` parameter (or resource title) that you
specify for your `package` resource must match a package name that exists
in the `.toc` file.

Note that package downgrades are *not* supported; if your resource specifies
a specific version number and there is already a newer version of the package
installed on the machine, the resource will fail with an error message.

* Required binaries: `/usr/bin/lslpp`, `/usr/sbin/installp`.
* Default for `operatingsystem` == `aix`.
* Supported features: `installable`, `uninstallable`, `upgradeable`, `versionable`.

appdmg
: Package management which copies application bundles to a target.

* Required binaries: `/usr/bin/curl`, `/usr/bin/ditto`, `/usr/bin/hdiutil`.
* Supported features: `installable`.

apple
: Package management based on OS X’s builtin packaging system. This is
essentially the simplest and least functional package system in existence —
it only supports installation; no deletion or upgrades. The provider will
automatically add the `.pkg` extension, so leave that off when specifying
the package name.

* Required binaries: `/usr/sbin/installer`.
* Supported features: `installable`.

apt
: Package management via `apt-get`.

This provider supports the `install_options` attribute, which allows command-line flags to be passed to apt-get.
These options should be specified as a string (e.g. ‘–flag’), a hash (e.g. {‘–flag’ => ‘value’}),
or an array where each element is either a string or a hash.

* Required binaries: `/usr/bin/apt-cache`, `/usr/bin/apt-get`, `/usr/bin/debconf-set-selections`.
* Default for `operatingsystem` == `debian, ubuntu`.
* Supported features: `holdable`, `install_options`, `installable`, `purgeable`, `uninstallable`, `upgradeable`, `versionable`.

aptitude
: Package management via `aptitude`.

* Required binaries: `/usr/bin/apt-cache`, `/usr/bin/aptitude`.
* Supported features: `holdable`, `installable`, `purgeable`, `uninstallable`, `upgradeable`, `versionable`.

aptrpm
: Package management via `apt-get` ported to `rpm`.

* Required binaries: `apt-cache`, `apt-get`, `rpm`.
* Supported features: `installable`, `purgeable`, `uninstallable`, `upgradeable`, `versionable`.

blastwave
: Package management using Blastwave.org’s `pkg-get` command on Solaris.

* Required binaries: `pkg-get`.
* Supported features: `installable`, `uninstallable`, `upgradeable`.

dpkg
: Package management via `dpkg`. Because this only uses `dpkg`
and not `apt`, you must specify the source of any packages you want
to manage.

* Required binaries: `/usr/bin/dpkg-deb`, `/usr/bin/dpkg-query`, `/usr/bin/dpkg`.
* Supported features: `holdable`, `installable`, `purgeable`, `uninstallable`, `upgradeable`.

fink
: Package management via `fink`.

* Required binaries: `/sw/bin/apt-cache`, `/sw/bin/apt-get`, `/sw/bin/dpkg-query`, `/sw/bin/fink`.
* Supported features: `holdable`, `installable`, `purgeable`, `uninstallable`, `upgradeable`, `versionable`.

freebsd
: The specific form of package management on FreeBSD. This is an
extremely quirky packaging system, in that it freely mixes between
ports and packages. Apparently all of the tools are written in Ruby,
so there are plans to rewrite this support to directly use those
libraries.

* Required binaries: `/usr/sbin/pkg_add`, `/usr/sbin/pkg_delete`, `/usr/sbin/pkg_info`.
* Supported features: `installable`, `purgeable`, `uninstallable`, `upgradeable`.

gem
: Ruby Gem support. If a URL is passed via `source`, then that URL is used as the
remote gem repository; if a source is present but is not a valid URL, it will be
interpreted as the path to a local gem file. If source is not present at all,
the gem will be installed from the default gem repositories.

This provider supports the `install_options` attribute, which allows command-line flags to be passed to the gem command.
These options should be specified as a string (e.g. ‘–flag’), a hash (e.g. {‘–flag’ => ‘value’}),
or an array where each element is either a string or a hash.

* Required binaries: `gem`.
* Supported features: `install_options`, `installable`, `uninstallable`, `upgradeable`, `versionable`.

hpux
: HP-UX’s packaging system.

* Required binaries: `/usr/sbin/swinstall`, `/usr/sbin/swlist`, `/usr/sbin/swremove`.
* Default for `operatingsystem` == `hp-ux`.
* Supported features: `installable`, `uninstallable`.

macports
: Package management using MacPorts on OS X.

Supports MacPorts versions and revisions, but not variants.
Variant preferences may be specified using
[the MacPorts variants.conf file](http://guide.macports.org/chunked/internals.configuration-files.html#internals.configuration-files.variants-conf).

When specifying a version in the Puppet DSL, only specify the version, not the revision.
Revisions are only used internally for ensuring the latest version/revision of a port.

* Required binaries: `/opt/local/bin/port`.
* Supported features: `installable`, `uninstallable`, `upgradeable`, `versionable`.

msi
: Windows package management by installing and removing MSIs.

The `msi` provider is deprecated. Use the `windows` provider instead.

* Supported features: `install_options`, `installable`, `uninstall_options`, `uninstallable`.

nim
: Installation from an AIX NIM LPP source. The `source` parameter is required
for this provider, and should specify the name of a NIM `lpp_source` resource
that is visible to the puppet agent machine. This provider supports the
management of both BFF/installp and RPM packages.

Note that package downgrades are *not* supported; if your resource specifies
a specific version number and there is already a newer version of the package
installed on the machine, the resource will fail with an error message.

* Required binaries: `/usr/bin/lslpp`, `/usr/sbin/nimclient`, `rpm`.
* Supported features: `installable`, `uninstallable`, `upgradeable`, `versionable`.

openbsd
: OpenBSD’s form of `pkg_add` support.

This provider supports the `install_options` and `uninstall_options`
attributes, which allow command-line flags to be passed to pkg_add and pkg_delete.
These options should be specified as a string (e.g. ‘–flag’), a hash (e.g. {‘–flag’ => ‘value’}),
or an array where each element is either a string or a hash.

* Required binaries: `pkg_add`, `pkg_delete`, `pkg_info`.
* Default for `operatingsystem` == `openbsd`.
* Supported features: `install_options`, `installable`, `purgeable`, `uninstall_options`, `uninstallable`, `upgradeable`, `versionable`.

opkg
: Opkg packaging support. Common on OpenWrt and OpenEmbedded platforms

* Required binaries: `opkg`.
* Default for `operatingsystem` == `openwrt`.
* Supported features: `installable`, `uninstallable`, `upgradeable`.

pacman
: Support for the Package Manager Utility (pacman) used in Archlinux.

This provider supports the `install_options` attribute, which allows command-line flags to be passed to pacman.
These options should be specified as a string (e.g. ‘–flag’), a hash (e.g. {‘–flag’ => ‘value’}),
or an array where each element is either a string or a hash.

* Required binaries: `/usr/bin/pacman`.
* Default for `operatingsystem` == `archlinux`.
* Supported features: `install_options`, `installable`, `uninstall_options`, `uninstallable`, `upgradeable`.

pip
: Python packages via `pip`.

* Supported features: `installable`, `uninstallable`, `upgradeable`, `versionable`.

pkg
: OpenSolaris image packaging system. See pkg(5) for more information

* Required binaries: `/usr/bin/pkg`.
* Default for `kernelrelease` == `5.11` and `osfamily` == `solaris`.
* Supported features: `holdable`, `installable`, `uninstallable`, `upgradeable`, `versionable`.

pkgdmg
: Package management based on Apple’s Installer.app and DiskUtility.app.

This provider works by checking the contents of a DMG image for Apple pkg or
mpkg files. Any number of pkg or mpkg files may exist in the root directory
of the DMG file system, and Puppet will install all of them. Subdirectories
are not checked for packages.

This provider can also accept plain .pkg (but not .mpkg) files in addition
to .dmg files.

Notes:

* The `source` attribute is mandatory. It must be either a local disk path
or an HTTP, HTTPS, or FTP URL to the package.
* The `name` of the resource must be the filename (without path) of the DMG file.
* When installing the packages from a DMG, this provider writes a file to
disk at `/var/db/.puppet_pkgdmg_installed_NAME`. If that file is present,
Puppet assumes all packages from that DMG are already installed.
* This provider is not versionable and uses DMG filenames to determine
whether a package has been installed. Thus, to install new a version of a
package, you must create a new DMG with a different filename.

* Required binaries: `/usr/bin/curl`, `/usr/bin/hdiutil`, `/usr/sbin/installer`.
* Default for `operatingsystem` == `darwin`.
* Supported features: `installable`.

pkgin
: Package management using pkgin, a binary package manager for pkgsrc.

* Required binaries: `pkgin`.
* Default for `operatingsystem` == `dragonfly, smartos`.
* Supported features: `installable`, `uninstallable`, `upgradeable`, `versionable`.

pkgutil
: Package management using Peter Bonivart’s “pkgutil“ command on Solaris.

* Required binaries: `pkgutil`.
* Supported features: `installable`, `uninstallable`, `upgradeable`.

portage
: Provides packaging support for Gentoo’s portage system.

* Required binaries: `/usr/bin/eix-update`, `/usr/bin/eix`, `/usr/bin/emerge`.
* Default for `operatingsystem` == `gentoo`.
* Supported features: `installable`, `uninstallable`, `upgradeable`, `versionable`.

ports
: Support for FreeBSD’s ports. Note that this, too, mixes packages and ports.

* Required binaries: `/usr/local/sbin/pkg_deinstall`, `/usr/local/sbin/portupgrade`, `/usr/local/sbin/portversion`, `/usr/sbin/pkg_info`.
* Default for `operatingsystem` == `freebsd`.
* Supported features: `installable`, `purgeable`, `uninstallable`, `upgradeable`.

portupgrade
: Support for FreeBSD’s ports using the portupgrade ports management software.
Use the port’s full origin as the resource name. eg (ports-mgmt/portupgrade)
for the portupgrade port.

* Required binaries: `/usr/local/sbin/pkg_deinstall`, `/usr/local/sbin/portinstall`, `/usr/local/sbin/portupgrade`, `/usr/local/sbin/portversion`, `/usr/sbin/pkg_info`.
* Supported features: `installable`, `uninstallable`, `upgradeable`.

rpm
: RPM packaging support; should work anywhere with a working `rpm`
binary.

This provider supports the `install_options` and `uninstall_options`
attributes, which allow command-line flags to be passed to rpm.
These options should be specified as a string (e.g. ‘–flag’), a hash (e.g. {‘–flag’ => ‘value’}),
or an array where each element is either a string or a hash.

* Required binaries: `rpm`.
* Supported features: `install_options`, `installable`, `uninstall_options`, `uninstallable`, `upgradeable`, `versionable`, `virtual_packages`.

rug
: Support for suse `rug` package manager.

* Required binaries: `/usr/bin/rug`, `rpm`.
* Default for `operatingsystem` == `suse, sles`.
* Supported features: `installable`, `uninstallable`, `upgradeable`, `versionable`.

sun
: Sun’s packaging system. Requires that you specify the source for
the packages you’re managing.

This provider supports the `install_options` attribute, which allows command-line flags to be passed to pkgadd.
These options should be specified as a string (e.g. ‘–flag’), a hash (e.g. {‘–flag’ => ‘value’}),
or an array where each element is either a string or a hash.

* Required binaries: `/usr/bin/pkginfo`, `/usr/sbin/pkgadd`, `/usr/sbin/pkgrm`.
* Default for `osfamily` == `solaris`.
* Supported features: `install_options`, `installable`, `uninstallable`, `upgradeable`.

sunfreeware
: Package management using sunfreeware.com’s `pkg-get` command on Solaris.
At this point, support is exactly the same as `blastwave` support and
has not actually been tested.

* Required binaries: `pkg-get`.
* Supported features: `installable`, `uninstallable`, `upgradeable`.

up2date
: Support for Red Hat’s proprietary `up2date` package update
mechanism.

* Required binaries: `/usr/sbin/up2date-nox`.
* Default for `lsbdistrelease` == `2.1, 3, 4` and `osfamily` == `redhat`.
* Supported features: `installable`, `uninstallable`, `upgradeable`.

urpmi
: Support via `urpmi`.

* Required binaries: `rpm`, `urpme`, `urpmi`, `urpmq`.
* Default for `operatingsystem` == `mandriva, mandrake`.
* Supported features: `installable`, `purgeable`, `uninstallable`, `upgradeable`, `versionable`.

windows
: Windows package management.

This provider supports either MSI or self-extracting executable installers.

This provider requires a `source` attribute when installing the package.
It accepts paths to local files, mapped drives, or UNC paths.

This provider supports the `install_options` and `uninstall_options`
attributes, which allow command-line flags to be passed to the installer.
These options should be specified as a string (e.g. ‘–flag’), a hash (e.g. {‘–flag’ => ‘value’}),
or an array where each element is either a string or a hash.

If the executable requires special arguments to perform a silent install or
uninstall, then the appropriate arguments should be specified using the
`install_options` or `uninstall_options` attributes, respectively. Puppet
will automatically quote any option that contains spaces.

* Default for `operatingsystem` == `windows`.
* Supported features: `install_options`, `installable`, `uninstall_options`, `uninstallable`, `versionable`.

yum
: Support via `yum`.

Using this provider’s `uninstallable` feature will not remove dependent packages. To
remove dependent packages with this provider use the `purgeable` feature, but note this
feature is destructive and should be used with the utmost care.

This provider supports the `install_options` attribute, which allows command-line flags to be passed to yum.
These options should be specified as a string (e.g. ‘–flag’), a hash (e.g. {‘–flag’ => ‘value’}),
or an array where each element is either a string or a hash.

* Required binaries: `python`, `rpm`, `yum`.
* Default for `osfamily` == `redhat`.
* Supported features: `install_options`, `installable`, `purgeable`, `uninstallable`, `upgradeable`, `versionable`, `virtual_packages`.

zypper
: Support for SuSE `zypper` package manager. Found in SLES10sp2+ and SLES11.

This provider supports the `install_options` attribute, which allows command-line flags to be passed to zypper.
These options should be specified as a string (e.g. ‘–flag’), a hash (e.g. {‘–flag’ => ‘value’}),
or an array where each element is either a string or a hash.

* Required binaries: `/usr/bin/zypper`.
* Supported features: `install_options`, `installable`, `uninstallable`, `upgradeable`, `versionable`, `virtual_packages`.

responsefile
: A file containing any necessary answers to questions asked by
the package. This is currently used on Solaris and Debian. The
value will be validated according to system rules, but it should
generally be a fully qualified path.

root
: A read-only parameter set by the package.

source
: Where to find the package file. This is only used by providers that don’t
automatically download packages from a central repository. (For example:
the `yum` and `apt` providers ignore this attribute, but the `rpm` and
`dpkg` providers require it.)

Different providers accept different values for `source`. Most providers
accept paths to local files stored on the target system. Some providers
may also accept URLs or network drive paths. Puppet will not
automatically retrieve source files for you, and usually just passes the
value of `source` to the package installation command.

You can use a `file` resource if you need to manually copy package files
to the target system.

status
: A read-only parameter set by the package.

uninstall_options
: An array of additional options to pass when uninstalling a package. These
options are package-specific, and should be documented by the software
vendor. For example:

package { ‘VMware Tools’:
ensure => absent,
uninstall_options => [ { ‘REMOVE’ => ‘Sync,VSS’ } ],
}

Each option in the array can either be a string or a hash, where each
key and value pair are interpreted in a provider specific way. Each
option will automatically be quoted when passed to the uninstall
command.

On Windows, this is the **only** place in Puppet where backslash
separators should be used. Note that backslashes in double-quoted
strings _must_ be double-escaped and backslashes in single-quoted
strings _may_ be double-escaped.

Requires features uninstall_options.

vendor
: A read-only parameter set by the package.
—————-

### resources

This is a metatype that can manage other resource types. Any
metaparams specified here will be passed on to any generated resources,
so you can purge umanaged resources but set `noop` to true so the
purging is only logged and does not actually happen.

#### Parameters
name
: The name of the type to be managed.

purge
: Whether to purge unmanaged resources. When set to `true`, this will
delete any resource that is not specified in your configuration and is not
autorequired by any managed resources. **Note:** The `ssh_authorized_key`
resource type can’t be purged this way; instead, see the `purge_ssh_keys`
attribute of the `user` type.

Valid values are `true`, `false`, `yes`, `no`.

unless_system_user
: This keeps system users from being purged. By default, it
does not purge users whose UIDs are less than the minimum UID for the system (typically 500 or 1000), but you can specify
a different UID as the inclusive limit.

Valid values are `true`, `false`. Values can match `/^\d+$/`.

unless_uid
: This keeps specific uids or ranges of uids from being purged when purge is true.
Accepts integers, integer strings, and arrays of integers or integer strings.
To specify a range of uids, consider using the range() function from stdlib.
—————-

### router

Manages connected router.

#### Parameters
url
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

An SSH or telnet URL at which to access the router, in the form
`ssh://user:pass:enable@host/` or `telnet://user:pass:enable@host/`.
—————-

### schedule

Define schedules for Puppet. Resources can be limited to a schedule by using the
[`schedule`](http://docs.puppetlabs.com/references/latest/metaparameter.html#schedule)
metaparameter.

Currently, **schedules can only be used to stop a resource from being
applied;** they cannot cause a resource to be applied when it otherwise
wouldn’t be, and they cannot accurately specify a time when a resource
should run.

Every time Puppet applies its configuration, it will apply the
set of resources whose schedule does not eliminate them from
running right then, but there is currently no system in place to
guarantee that a given resource runs at a given time. If you
specify a very restrictive schedule and Puppet happens to run at a
time within that schedule, then the resources will get applied;
otherwise, that work may never get done.

Thus, it is advisable to use wider scheduling (e.g., over a couple of
hours) combined with periods and repetitions. For instance, if you
wanted to restrict certain resources to only running once, between
the hours of two and 4 AM, then you would use this schedule:

schedule { ‘maint’:
range => “2 – 4”,
period => daily,
repeat => 1,
}

With this schedule, the first time that Puppet runs between 2 and 4 AM,
all resources with this schedule will get applied, but they won’t
get applied again between 2 and 4 because they will have already
run once that day, and they won’t get applied outside that schedule
because they will be outside the scheduled range.

Puppet automatically creates a schedule for each of the valid periods
with the same name as that period (e.g., hourly and daily).
Additionally, a schedule named `puppet` is created and used as the
default, with the following attributes:

schedule { ‘puppet’:
period => hourly,
repeat => 2,
}

This will cause resources to be applied every 30 minutes by default.

#### Parameters
name
: The name of the schedule. This name is used when assigning the schedule
to a resource with the `schedule` metaparameter:

schedule { ‘everyday’:
period => daily,
range => “2 – 4”,
}

exec { “/usr/bin/apt-get update”:
schedule => ‘everyday’,
}

period
: The period of repetition for resources on this schedule. The default is
for resources to get applied every time Puppet runs.

Note that the period defines how often a given resource will get
applied but not when; if you would like to restrict the hours
that a given resource can be applied (e.g., only at night during
a maintenance window), then use the `range` attribute.

If the provided periods are not sufficient, you can provide a
value to the *repeat* attribute, which will cause Puppet to
schedule the affected resources evenly in the period the
specified number of times. Take this schedule:

schedule { ‘veryoften’:
period => hourly,
repeat => 6,
}

This can cause Puppet to apply that resource up to every 10 minutes.

At the moment, Puppet cannot guarantee that level of repetition; that
is, the resource can applied _up to_ every 10 minutes, but internal
factors might prevent it from actually running that often (e.g. if a
Puppet run is still in progress when the next run is scheduled to start,
that next run will be suppressed).

See the `periodmatch` attribute for tuning whether to match
times by their distance apart or by their specific value.

Valid values are `hourly`, `daily`, `weekly`, `monthly`, `never`.

periodmatch
: Whether periods should be matched by number (e.g., the two times
are in the same hour) or by distance (e.g., the two times are
60 minutes apart).

Valid values are `number`, `distance`.

range
: The earliest and latest that a resource can be applied. This is
always a hyphen-separated range within a 24 hour period, and hours
must be specified in numbers between 0 and 23, inclusive. Minutes and
seconds can optionally be provided, using the normal colon as a
separator. For instance:

schedule { ‘maintenance’:
range => “1:30 – 4:30”,
}

This is mostly useful for restricting certain resources to being
applied in maintenance windows or during off-peak hours. Multiple
ranges can be applied in array context. As a convenience when specifying
ranges, you may cross midnight (e.g.: range => “22:00 – 04:00”).

repeat
: How often a given resource may be applied in this schedule’s `period`.
Defaults to 1; must be an integer.

weekday
: The days of the week in which the schedule should be valid.
You may specify the full day name (Tuesday), the three character
abbreviation (Tue), or a number corresponding to the day of the
week where 0 is Sunday, 1 is Monday, etc. Multiple days can be specified
as an array. If not specified, the day of the week will not be
considered in the schedule.

If you are also using a range match that spans across midnight
then this parameter will match the day that it was at the start
of the range, not necessarily the day that it is when it matches.
For example, consider this schedule:

schedule { ‘maintenance_window’:
range => ’22:00 – 04:00′,
weekday => ‘Saturday’,
}

This will match at 11 PM on Saturday and 2 AM on Sunday, but not
at 2 AM on Saturday.
—————-

### scheduled_task

Installs and manages Windows Scheduled Tasks. All attributes
except `name`, `command`, and `trigger` are optional; see the description
of the `trigger` attribute for details on setting schedules.

#### Parameters
arguments
: Any arguments or flags that should be passed to the command. Multiple arguments
should be specified as a space-separated string.

command
: The full path to the application to run, without any arguments.

enabled
: Whether the triggers for this task should be enabled. This attribute
affects every trigger for the task; triggers cannot be enabled or
disabled individually.

Valid values are `true`, `false`.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

name
: The name assigned to the scheduled task. This will uniquely
identify the task on the system.

password
: The password for the user specified in the ‘user’ attribute.
This is only used if specifying a user other than ‘SYSTEM’.
Since there is no way to retrieve the password used to set the
account information for a task, this parameter will not be used
to determine if a scheduled task is in sync or not.

provider
: The specific backend to use for this `scheduled_task`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

win32_taskscheduler
: This provider manages scheduled tasks on Windows.

* Default for `operatingsystem` == `windows`.

trigger
: One or more triggers defining when the task should run. A single trigger is
represented as a hash, and multiple triggers can be specified with an array of
hashes.

A trigger can contain the following keys:

* For all triggers:
* `schedule` **(Required)** — What kind of trigger this is.
Valid values are `daily`, `weekly`, `monthly`, or `once`. Each kind
of trigger is configured with a different set of keys; see the
sections below. (`once` triggers only need a start time/date.)
* `start_time` **(Required)** — The time of day when the trigger should
first become active. Several time formats will work, but we
suggest 24-hour time formatted as HH:MM.
* `start_date` — The date when the trigger should first become active.
Defaults to the current date. You should format dates as YYYY-MM-DD,
although other date formats may work. (Under the hood, this uses `Date.parse`.)
* `minutes_interval` — The repeat interval in minutes.
* `minutes_duration` — The duration in minutes, needs to be greater than the
minutes_interval.
* For `daily` triggers:
* `every` — How often the task should run, as a number of days. Defaults
to 1. (“2” means every other day, “3” means every three days, etc.)
* For `weekly` triggers:
* `every` — How often the task should run, as a number of weeks. Defaults
to 1. (“2” means every other week, “3” means every three weeks, etc.)
* `day_of_week` — Which days of the week the task should run, as an array.
Defaults to all days. Each day must be one of `mon`, `tues`,
`wed`, `thurs`, `fri`, `sat`, `sun`, or `all`.
* For `monthly` (by date) triggers:
* `months` — Which months the task should run, as an array. Defaults to
all months. Each month must be an integer between 1 and 12.
* `on` **(Required)** — Which days of the month the task should run,
as an array. Each day must beeither an integer between 1 and 31,
or the special value `last,` which is always the last day of the month.
* For `monthly` (by weekday) triggers:
* `months` — Which months the task should run, as an array. Defaults to
all months. Each month must be an integer between 1 and 12.
* `day_of_week` **(Required)** — Which day of the week the task should
run, as an array with only one element. Each day must be one of `mon`,
`tues`, `wed`, `thurs`, `fri`, `sat`, `sun`, or `all`.
* `which_occurrence` **(Required)** — The occurrence of the chosen weekday
when the task should run. Must be one of `first`, `second`, `third`,
`fourth`, `fifth`, or `last`.
Examples:

# Run at 8am on the 1st, 15th, and last day of the month in January, March,
# May, July, September, and November, starting after August 31st, 2011.
trigger => {
schedule => monthly,
start_date => ‘2011-08-31′, # Defaults to current date
start_time => ’08:00’, # Must be specified
months => [1,3,5,7,9,11], # Defaults to all
on => [1, 15, last], # Must be specified
}

# Run at 8am on the first Monday of the month for January, March, and May,
# starting after August 31st, 2011.
trigger => {
schedule => monthly,
start_date => ‘2011-08-31′, # Defaults to current date
start_time => ’08:00’, # Must be specified
months => [1,3,5], # Defaults to all
which_occurrence => first, # Must be specified
day_of_week => [mon], # Must be specified
}

# Run daily repeating every 30 minutes between 9am and 5pm (480 minutes) starting after August 31st, 2011.
trigger => {
schedule => daily,
start_date => ‘2011-08-31’, # Defaults to current date
start_time => ‘8:00’, # Must be specified
minutes_interval => 30,
minutes_duration => 480,
}

user
: The user to run the scheduled task as. Please note that not
all security configurations will allow running a scheduled task
as ‘SYSTEM’, and saving the scheduled task under these
conditions will fail with a reported error of ‘The operation
completed successfully’. It is recommended that you either
choose another user to run the scheduled task, or alter the
security policy to allow v1 scheduled tasks to run as the
‘SYSTEM’ account. Defaults to ‘SYSTEM’.

Please also note that Puppet must be running as a privileged user
in order to manage `scheduled_task` resources. Running as an
unprivileged user will result in ‘access denied’ errors.

working_dir
: The full path of the directory in which to start the command.
—————-

### selboolean

Manages SELinux booleans on systems with SELinux support. The supported booleans
are any of the ones found in `/selinux/booleans/`.

#### Parameters
name
: The name of the SELinux boolean to be managed.

persistent
: If set true, SELinux booleans will be written to disk and persist accross reboots.
The default is `false`.

Valid values are `true`, `false`.

provider
: The specific backend to use for this `selboolean`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

getsetsebool
: Manage SELinux booleans using the getsebool and setsebool binaries.

* Required binaries: `/usr/sbin/getsebool`, `/usr/sbin/setsebool`.

value
: Whether the SELinux boolean should be enabled or disabled.

Valid values are `on`, `off`.
—————-

### selmodule

Manages loading and unloading of SELinux policy modules
on the system. Requires SELinux support. See man semodule(8)
for more information on SELinux policy modules.

**Autorequires:** If Puppet is managing the file containing this SELinux
policy module (which is either explicitly specified in the `selmodulepath`
attribute or will be found at {`selmoduledir`}/{`name`}.pp), the selmodule
resource will autorequire that file.

#### Parameters
ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

name
: The name of the SELinux policy to be managed. You should not
include the customary trailing .pp extension.

provider
: The specific backend to use for this `selmodule`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

semodule
: Manage SELinux policy modules using the semodule binary.

* Required binaries: `/usr/sbin/semodule`.

selmoduledir
: The directory to look for the compiled pp module file in.
Currently defaults to `/usr/share/selinux/targeted`. If the
`selmodulepath` attribute is not specified, Puppet will expect to find
the module in `<selmoduledir>/<name>.pp`, where `name` is the value of the
`name` parameter.

selmodulepath
: The full path to the compiled .pp policy module. You only need to use
this if the module file is not in the `selmoduledir` directory.

syncversion
: If set to `true`, the policy will be reloaded if the
version found in the on-disk file differs from the loaded
version. If set to `false` (the default) the only check
that will be made is if the policy is loaded at all or not.

Valid values are `true`, `false`.
—————-

### service

Manage running services. Service support unfortunately varies
widely by platform — some platforms have very little if any concept of a
running service, and some have a very codified and powerful concept.
Puppet’s service support is usually capable of doing the right thing, but
the more information you can provide, the better behaviour you will get.

Puppet 2.7 and newer expect init scripts to have a working status command.
If this isn’t the case for any of your services’ init scripts, you will
need to set `hasstatus` to false and possibly specify a custom status
command in the `status` attribute. As a last resort, Puppet will attempt to
search the process table by calling whatever command is listed in the `ps`
fact. The default search pattern is the name of the service, but you can
specify it with the `pattern` attribute.

**Refresh:** `service` resources can respond to refresh events (via
`notify`, `subscribe`, or the `~>` arrow). If a `service` receives an
event from another resource, Puppet will restart the service it manages.
The actual command used to restart the service depends on the platform and
can be configured:

* If you set `hasrestart` to true, Puppet will use the init script’s restart command.
* You can provide an explicit command for restarting with the `restart` attribute.
* If you do neither, the service’s stop and start commands will be used.

#### Features

– *controllable*: The provider uses a control variable.
– *enableable*: The provider can enable and disable the service
– *flaggable*: The provider can pass flags to the service.
– *refreshable*: The provider can restart the service.
Provider | controllable | enableable | flaggable | refreshable |
———– | ———— | ———- | ——— | ———– |
base | | | | *X* |
bsd | | *X* | | *X* |
daemontools | | *X* | | *X* |
debian | | *X* | | *X* |
freebsd | | *X* | | *X* |
gentoo | | *X* | | *X* |
init | | | | *X* |
launchd | | *X* | | *X* |
openbsd | | *X* | *X* | *X* |
openrc | | *X* | | *X* |
openwrt | | *X* | | *X* |
redhat | | *X* | | *X* |
runit | | *X* | | *X* |
service | | | | *X* |
smf | | *X* | | *X* |
src | | *X* | | *X* |
systemd | | *X* | | *X* |
upstart | | *X* | | *X* |
windows | | *X* | | *X* |

#### Parameters
binary
: The path to the daemon. This is only used for
systems that do not support init scripts. This binary will be
used to start the service if no `start` parameter is
provided.

control
: The control variable used to manage services (originally for HP-UX).
Defaults to the upcased service name plus `START` replacing dots with
underscores, for those providers that support the `controllable` feature.

enable
: Whether a service should be enabled to start at boot.
This property behaves quite differently depending on the platform;
wherever possible, it relies on local tools to enable or disable
a given service.

Valid values are `true`, `false`, `manual`.

Requires features enableable.

ensure
: Whether a service should be running.

Valid values are `stopped` (also called `false`), `running` (also called `true`).

flags
: Specify a string of flags to pass to the startup script.

Requires features flaggable.

hasrestart
: Specify that an init script has a `restart` command. If this is
false and you do not specify a command in the `restart` attribute,
the init script’s `stop` and `start` commands will be used.

Defaults to false.

Valid values are `true`, `false`.

hasstatus
: Declare whether the service’s init script has a functional status
command; defaults to `true`. This attribute’s default value changed in
Puppet 2.7.0.

The init script’s status command must return 0 if the service is
running and a nonzero value otherwise. Ideally, these exit codes
should conform to [the LSB’s specification][lsb-exit-codes] for init
script status actions, but Puppet only considers the difference
between 0 and nonzero to be relevant.

If a service’s init script does not support any kind of status command,
you should set `hasstatus` to false and either provide a specific
command using the `status` attribute or expect that Puppet will look for
the service name in the process table. Be aware that ‘virtual’ init
scripts (like ‘network’ under Red Hat systems) will respond poorly to
refresh events from other resources if you override the default behavior
without providing a status command.

Valid values are `true`, `false`.

manifest
: Specify a command to config a service, or a path to a manifest to do so.

name
: The name of the service to run.

This name is used to find the service; on platforms where services
have short system names and long display names, this should be the
short name. (To take an example from Windows, you would use “wuauserv”
rather than “Automatic Updates.”)

path
: The search path for finding init scripts. Multiple values should
be separated by colons or provided as an array.

pattern
: The pattern to search for in the process table.
This is used for stopping services on platforms that do not
support init scripts, and is also used for determining service
status on those service whose init scripts do not include a status
command.

Defaults to the name of the service. The pattern can be a simple string
or any legal Ruby pattern, including regular expressions (which should
be quoted without enclosing slashes).

provider
: The specific backend to use for this `service`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

base
: The simplest form of Unix service support.

You have to specify enough about your service for this to work; the
minimum you can specify is a binary for starting the process, and this
same binary will be searched for in the process table to stop the
service. As with `init`-style services, it is preferable to specify start,
stop, and status commands.

* Required binaries: `kill`.
* Supported features: `refreshable`.

bsd
: FreeBSD’s (and probably NetBSD’s?) form of `init`-style service management.

Uses `rc.conf.d` for service enabling and disabling.

* Supported features: `enableable`, `refreshable`.

daemontools
: Daemontools service management.

This provider manages daemons supervised by D.J. Bernstein daemontools.
When detecting the service directory it will check, in order of preference:

* `/service`
* `/etc/service`
* `/var/lib/svscan`

The daemon directory should be in one of the following locations:

* `/var/lib/service`
* `/etc`

…or this can be overriden in the resource’s attributes:

service { “myservice”:
provider => “daemontools”,
path => “/path/to/daemons”,
}

This provider supports out of the box:

* start/stop (mapped to enable/disable)
* enable/disable
* restart
* status

If a service has `ensure => “running”`, it will link /path/to/daemon to
/path/to/service, which will automatically enable the service.

If a service has `ensure => “stopped”`, it will only shut down the service, not
remove the `/path/to/service` link.

* Required binaries: `/usr/bin/svc`, `/usr/bin/svstat`.
* Supported features: `enableable`, `refreshable`.

debian
: Debian’s form of `init`-style management.

The only differences from `init` are support for enabling and disabling
services via `update-rc.d` and the ability to determine enabled status via
`invoke-rc.d`.

* Required binaries: `/usr/sbin/invoke-rc.d`, `/usr/sbin/update-rc.d`.
* Default for `operatingsystem` == `debian`.
* Supported features: `enableable`, `refreshable`.

freebsd
: Provider for FreeBSD and DragonFly BSD. Uses the `rcvar` argument of init scripts and parses/edits rc files.

* Default for `operatingsystem` == `freebsd, dragonfly`.
* Supported features: `enableable`, `refreshable`.

gentoo
: Gentoo’s form of `init`-style service management.

Uses `rc-update` for service enabling and disabling.

* Required binaries: `/sbin/rc-update`.
* Supported features: `enableable`, `refreshable`.

init
: Standard `init`-style service management.

* Supported features: `refreshable`.

launchd
: This provider manages jobs with `launchd`, which is the default service
framework for Mac OS X (and may be available for use on other platforms).

For `launchd` documentation, see:

* <http://developer.apple.com/macosx/launchd.html&gt;
* <http://launchd.macosforge.org/&gt;

This provider reads plists out of the following directories:

* `/System/Library/LaunchDaemons`
* `/System/Library/LaunchAgents`
* `/Library/LaunchDaemons`
* `/Library/LaunchAgents`

…and builds up a list of services based upon each plist’s “Label” entry.

This provider supports:

* ensure => running/stopped,
* enable => true/false
* status
* restart

Here is how the Puppet states correspond to `launchd` states:

* stopped — job unloaded
* started — job loaded
* enabled — ‘Disable’ removed from job plist file
* disabled — ‘Disable’ added to job plist file

Note that this allows you to do something `launchctl` can’t do, which is to
be in a state of “stopped/enabled” or “running/disabled”.

Note that this provider does not support overriding ‘restart’ or ‘status’.

* Required binaries: `/bin/launchctl`, `/usr/bin/plutil`, `/usr/bin/sw_vers`.
* Default for `operatingsystem` == `darwin`.
* Supported features: `enableable`, `refreshable`.

openbsd
: Provider for OpenBSD’s rc.d daemon control scripts

* Default for `operatingsystem` == `openbsd`.
* Supported features: `enableable`, `flaggable`, `refreshable`.

openrc
: Support for Gentoo’s OpenRC initskripts

Uses rc-update, rc-status and rc-service to manage services.

* Required binaries: `/bin/rc-status`, `/sbin/rc-service`, `/sbin/rc-update`.
* Default for `operatingsystem` == `gentoo`. Default for `operatingsystem` == `funtoo`.
* Supported features: `enableable`, `refreshable`.

openwrt
: Support for OpenWrt flavored init scripts.

Uses /etc/init.d/service_name enable, disable, and enabled.

* Default for `operatingsystem` == `openwrt`.
* Supported features: `enableable`, `refreshable`.

redhat
: Red Hat’s (and probably many others’) form of `init`-style service
management. Uses `chkconfig` for service enabling and disabling.

* Required binaries: `/sbin/chkconfig`, `/sbin/service`.
* Default for `osfamily` == `redhat, suse`.
* Supported features: `enableable`, `refreshable`.

runit
: Runit service management.

This provider manages daemons running supervised by Runit.
When detecting the service directory it will check, in order of preference:

* `/service`
* `/etc/service`
* `/var/service`

The daemon directory should be in one of the following locations:

* `/etc/sv`
* `/var/lib/service`

or this can be overriden in the service resource parameters::

service { “myservice”:
provider => “runit”,
path => “/path/to/daemons”,
}

This provider supports out of the box:

* start/stop
* enable/disable
* restart
* status

* Required binaries: `/usr/bin/sv`.
* Supported features: `enableable`, `refreshable`.

service
: The simplest form of service support.

* Supported features: `refreshable`.

smf
: Support for Sun’s new Service Management Framework.

Starting a service is effectively equivalent to enabling it, so there is
only support for starting and stopping services, which also enables and
disables them, respectively.

By specifying `manifest => “/path/to/service.xml”`, the SMF manifest will
be imported if it does not exist.

* Required binaries: `/usr/bin/svcs`, `/usr/sbin/svcadm`, `/usr/sbin/svccfg`.
* Default for `osfamily` == `solaris`.
* Supported features: `enableable`, `refreshable`.

src
: Support for AIX’s System Resource controller.

Services are started/stopped based on the `stopsrc` and `startsrc`
commands, and some services can be refreshed with `refresh` command.

Enabling and disabling services is not supported, as it requires
modifications to `/etc/inittab`. Starting and stopping groups of subsystems
is not yet supported.

* Required binaries: `/usr/bin/lssrc`, `/usr/bin/refresh`, `/usr/bin/startsrc`, `/usr/bin/stopsrc`, `/usr/sbin/chitab`, `/usr/sbin/lsitab`, `/usr/sbin/mkitab`, `/usr/sbin/rmitab`.
* Default for `operatingsystem` == `aix`.
* Supported features: `enableable`, `refreshable`.

systemd
: Manages `systemd` services using `systemctl`.

* Required binaries: `systemctl`.
* Default for `osfamily` == `archlinux`. Default for `operatingsystemmajrelease` == `7` and `osfamily` == `redhat`. Default for `operatingsystem` == `fedora` and `operatingsystemmajrelease` == `17, 18, 19, 20, 21` and `osfamily` == `redhat`.
* Supported features: `enableable`, `refreshable`.

upstart
: Ubuntu service management with `upstart`.

This provider manages `upstart` jobs on Ubuntu. For `upstart` documentation,
see <http://upstart.ubuntu.com/&gt;.

* Required binaries: `/sbin/initctl`, `/sbin/restart`, `/sbin/start`, `/sbin/status`, `/sbin/stop`.
* Default for `operatingsystem` == `ubuntu`.
* Supported features: `enableable`, `refreshable`.

windows
: Support for Windows Service Control Manager (SCM). This provider can
start, stop, enable, and disable services, and the SCM provides working
status methods for all services.

Control of service groups (dependencies) is not yet supported, nor is running
services as a specific user.

* Required binaries: `net.exe`.
* Default for `operatingsystem` == `windows`.
* Supported features: `enableable`, `refreshable`.

restart
: Specify a *restart* command manually. If left
unspecified, the service will be stopped and then started.

start
: Specify a *start* command manually. Most service subsystems
support a `start` command, so this will not need to be
specified.

status
: Specify a *status* command manually. This command must
return 0 if the service is running and a nonzero value otherwise.
Ideally, these exit codes should conform to [the LSB’s
specification][lsb-exit-codes] for init script status actions, but
Puppet only considers the difference between 0 and nonzero to be
relevant.

If left unspecified, the status of the service will be determined
automatically, usually by looking for the service in the process
table.

[lsb-exit-codes]: http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

stop
: Specify a *stop* command manually.
—————-

### ssh_authorized_key

Manages SSH authorized keys. Currently only type 2 keys are supported.

In their native habitat, SSH keys usually appear as a single long line. This
resource type requires you to split that line into several attributes. Thus, a
key that appears in your `~/.ssh/id_rsa.pub` file like this…

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAy5mtOAMHwA2ZAIfW6Ap70r+I4EclYHEec5xIN59ROUjss23Skb1OtjzYpVPaPH8mSdSmsN0JHaBLiRcu7stl4O8D8zA4mz/vw32yyQ/Kqaxw8l0K76k6t2hKOGqLTY4aFbFISV6GDh7MYLn8KU7cGp96J+caO5R5TqtsStytsUhSyqH+iIDh4e4+BrwTc6V4Y0hgFxaZV5d18mLA4EPYKeG5+zyBCVu+jueYwFqM55E0tHbfiaIN9IzdLV+7NEEfdLkp6w2baLKPqWUBmuvPF1Mn3FwaFLjVsMT3GQeMue6b3FtUdTDeyAYoTxrsRo/WnDkS6Pa3YhrFwjtUqXfdaQ== nick@magpie.puppetlabs.lan

…would translate to the following resource:

ssh_authorized_key { ‘nick@magpie.puppetlabs.lan’:
user => ‘nick’,
type => ‘ssh-rsa’,
key => ‘AAAAB3NzaC1yc2EAAAABIwAAAQEAy5mtOAMHwA2ZAIfW6Ap70r+I4EclYHEec5xIN59ROUjss23Skb1OtjzYpVPaPH8mSdSmsN0JHaBLiRcu7stl4O8D8zA4mz/vw32yyQ/Kqaxw8l0K76k6t2hKOGqLTY4aFbFISV6GDh7MYLn8KU7cGp96J+caO5R5TqtsStytsUhSyqH+iIDh4e4+BrwTc6V4Y0hgFxaZV5d18mLA4EPYKeG5+zyBCVu+jueYwFqM55E0tHbfiaIN9IzdLV+7NEEfdLkp6w2baLKPqWUBmuvPF1Mn3FwaFLjVsMT3GQeMue6b3FtUdTDeyAYoTxrsRo/WnDkS6Pa3YhrFwjtUqXfdaQ==’,
}

To ensure that only the currently approved keys are present, you can purge
unmanaged SSH keys on a per-user basis. Do this with the `user` resource
type’s `purge_ssh_keys` attribute:

user { ‘nick’:
ensure => present,
purge_ssh_keys => true,
}

This will remove any keys in `~/.ssh/authorized_keys` that aren’t being
managed with `ssh_authorized_key` resources. See the documentation of the
`user` type for more details.

**Autorequires:** If Puppet is managing the user account in which this
SSH key should be installed, the `ssh_authorized_key` resource will autorequire
that user.

#### Parameters
ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

key
: The public key itself; generally a long string of hex characters. The `key`
attribute may not contain whitespace.

Make sure to omit the following in this attribute (and specify them in
other attributes):

* Key headers (e.g. ‘ssh-rsa’) — put these in the `type` attribute.
* Key identifiers / comments (e.g. ‘joe@joescomputer.local’) — put these in
the `name` attribute/resource title.

name
: The SSH key comment. This attribute is currently used as a
system-wide primary key and therefore has to be unique.

options
: Key options; see sshd(8) for possible values. Multiple values
should be specified as an array.

provider
: The specific backend to use for this `ssh_authorized_key`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

parsed
: Parse and generate authorized_keys files for SSH.

target
: The absolute filename in which to store the SSH key. This
property is optional and should only be used in cases where keys
are stored in a non-standard location (i.e.` not in
`~user/.ssh/authorized_keys`).

type
: The encryption type used.

Valid values are `ssh-dss` (also called `dsa`), `ssh-rsa` (also called `rsa`), `ecdsa-sha2-nistp256`, `ecdsa-sha2-nistp384`, `ecdsa-sha2-nistp521`, `ssh-ed25519` (also called `ed25519`).

user
: The user account in which the SSH key should be installed. The resource
will autorequire this user if it is being managed as a `user` resource.
—————-

### sshkey

Installs and manages ssh host keys. At this point, this type
only knows how to install keys into `/etc/ssh/ssh_known_hosts`. See
the `ssh_authorized_key` type to manage authorized keys.

#### Parameters
ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

host_aliases
: Any aliases the host might have. Multiple values must be
specified as an array.

key
: The key itself; generally a long string of uuencoded characters.

name
: The host name that the key is associated with.

provider
: The specific backend to use for this `sshkey`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

parsed
: Parse and generate host-wide known hosts files for SSH.

target
: The file in which to store the ssh key. Only used by
the `parsed` provider.

type
: The encryption type used. Probably ssh-dss or ssh-rsa.

Valid values are `ssh-dss` (also called `dsa`), `ssh-ed25519` (also called `ed25519`), `ssh-rsa` (also called `rsa`), `ecdsa-sha2-nistp256`, `ecdsa-sha2-nistp384`, `ecdsa-sha2-nistp521`.
—————-

### stage

A resource type for creating new run stages. Once a stage is available,
classes can be assigned to it by declaring them with the resource-like syntax
and using
[the `stage` metaparameter](http://docs.puppetlabs.com/references/latest/metaparameter.html#stage).

Note that new stages are not useful unless you also declare their order
in relation to the default `main` stage.

A complete run stage example:

stage { ‘pre’:
before => Stage[‘main’],
}

class { ‘apt-updates’:
stage => ‘pre’,
}

Individual resources cannot be assigned to run stages; you can only set stages
for classes.

#### Parameters
name
: The name of the stage. Use this as the value for the `stage` metaparameter
when assigning classes to this stage.
—————-

### tidy

Remove unwanted files based on specific criteria. Multiple
criteria are OR’d together, so a file that is too large but is not
old enough will still get tidied.

If you don’t specify either `age` or `size`, then all files will
be removed.

This resource type works by generating a file resource for every file
that should be deleted and then letting that resource perform the
actual deletion.

#### Parameters
age
: Tidy files whose age is equal to or greater than
the specified time. You can choose seconds, minutes,
hours, days, or weeks by specifying the first letter of any
of those words (e.g., ‘1w’).

Specifying 0 will remove all files.

backup
: Whether tidied files should be backed up. Any values are passed
directly to the file resources used for actual file deletion, so consult
the `file` type’s backup documentation to determine valid values.

matches
: One or more (shell type) file glob patterns, which restrict
the list of files to be tidied to those whose basenames match
at least one of the patterns specified. Multiple patterns can
be specified using an array.

Example:

tidy { “/tmp”:
age => “1w”,
recurse => 1,
matches => [ “[0-9]pub*.tmp”, “*.temp”, “tmpfile?” ]
}

This removes files from `/tmp` if they are one week old or older,
are not in a subdirectory and match one of the shell globs given.

Note that the patterns are matched against the basename of each
file — that is, your glob patterns should not have any ‘/’
characters in them, since you are only specifying against the last
bit of the file.

Finally, note that you must now specify a non-zero/non-false value
for recurse if matches is used, as matches only apply to files found
by recursion (there’s no reason to use static patterns match against
a statically determined path). Requiering explicit recursion clears
up a common source of confusion.

path
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The path to the file or directory to manage. Must be fully
qualified.

recurse
: If target is a directory, recursively descend
into the directory looking for files to tidy.

Valid values are `true`, `false`, `inf`. Values can match `/^[0-9]+$/`.

rmdirs
: Tidy directories in addition to files; that is, remove
directories whose age is older than the specified criteria.
This will only remove empty directories, so all contained
files must also be tidied before a directory gets removed.

Valid values are `true`, `false`, `yes`, `no`.

size
: Tidy files whose size is equal to or greater than
the specified size. Unqualified values are in kilobytes, but
*b*, *k*, *m*, *g*, and *t* can be appended to specify *bytes*,
*kilobytes*, *megabytes*, *gigabytes*, and *terabytes*, respectively.
Only the first character is significant, so the full word can also
be used.

type
: Set the mechanism for determining age. Default: atime.

Valid values are `atime`, `mtime`, `ctime`.
—————-

### user

Manage users. This type is mostly built to manage system
users, so it is lacking some features useful for managing normal
users.

This resource type uses the prescribed native tools for creating
groups and generally uses POSIX APIs for retrieving information
about them. It does not directly modify `/etc/passwd` or anything.

**Autorequires:** If Puppet is managing the user’s primary group (as
provided in the `gid` attribute), the user resource will autorequire
that group. If Puppet is managing any role accounts corresponding to the
user’s roles, the user resource will autorequire those role accounts.

#### Features

– *allows_duplicates*: The provider supports duplicate users with the same UID.
– *libuser*: Allows local users to be managed on systems that also use some other remote NSS method of managing accounts.
– *manages_aix_lam*: The provider can manage AIX Loadable Authentication Module (LAM) system.
– *manages_expiry*: The provider can manage the expiry date for a user.
– *manages_homedir*: The provider can create and remove home directories.
– *manages_password_age*: The provider can set age requirements and restrictions for passwords.
– *manages_password_salt*: The provider can set a password salt. This is for providers that implement PBKDF2 passwords with salt properties.
– *manages_passwords*: The provider can modify user passwords, by accepting a password hash.
– *manages_shell*: The provider allows for setting shell and validates if possible
– *manages_solaris_rbac*: The provider can manage roles and normal users
– *system_users*: The provider allows you to create system users with lower UIDs.
Provider | allows_duplicates | libuser | manages_aix_lam | manages_expiry | manages_homedir | manages_password_age | manages_password_salt | manages_passwords | manages_shell | manages_solaris_rbac | system_users |
—————- | —————– | ——- | ————— | ————– | ————— | ——————– | ——————— | —————– | ————- | ——————– | ———— |
aix | | | *X* | *X* | *X* | *X* | | *X* | *X* | | |
directoryservice | | | | | | | *X* | *X* | *X* | | |
hpuxuseradd | *X* | | | | *X* | | | *X* | | | |
ldap | | | | | | | | *X* | *X* | | |
pw | *X* | | | *X* | *X* | | | *X* | *X* | | |
user_role_add | *X* | | | | *X* | *X* | | *X* | *X* | *X* | |
useradd | *X* | *X* | | *X* | *X* | *X* | | *X* | *X* | | *X* |
windows_adsi | | | | | *X* | | | *X* | | | |

#### Parameters
allowdupe
: Whether to allow duplicate UIDs. Defaults to `false`.

Valid values are `true`, `false`, `yes`, `no`.

attribute_membership
: Whether specified attribute value pairs should be treated as the
**complete list** (`inclusive`) or the **minimum list** (`minimum`) of
attribute/value pairs for the user. Defaults to `minimum`.

Valid values are `inclusive`, `minimum`.

attributes
: Specify AIX attributes for the user in an array of attribute = value pairs.

Requires features manages_aix_lam.

auth_membership
: Whether specified auths should be considered the **complete list**
(`inclusive`) or the **minimum list** (`minimum`) of auths the user
has. Defaults to `minimum`.

Valid values are `inclusive`, `minimum`.

auths
: The auths the user has. Multiple auths should be
specified as an array.

Requires features manages_solaris_rbac.

comment
: A description of the user. Generally the user’s full name.

ensure
: The basic state that the object should be in.

Valid values are `present`, `absent`, `role`.

expiry
: The expiry date for this user. Must be provided in
a zero-padded YYYY-MM-DD format — e.g. 2010-02-19.
If you want to make sure the user account does never
expire, you can pass the special value `absent`.

Valid values are `absent`. Values can match `/^\d{4}-\d{2}-\d{2}$/`.

Requires features manages_expiry.

forcelocal
: Forces the management of local accounts when accounts are also
being managed by some other NSS

Valid values are `true`, `false`, `yes`, `no`.

Requires features libuser.

gid
: The user’s primary group. Can be specified numerically or by name.

This attribute is not supported on Windows systems; use the `groups`
attribute instead. (On Windows, designating a primary group is only
meaningful for domain accounts, which Puppet does not currently manage.)

groups
: The groups to which the user belongs. The primary group should
not be listed, and groups should be identified by name rather than by
GID. Multiple groups should be specified as an array.

home
: The home directory of the user. The directory must be created
separately and is not currently checked for existence.

ia_load_module
: The name of the I&A module to use to manage this user.

Requires features manages_aix_lam.

iterations
: This is the number of iterations of a chained computation of the
password hash (http://en.wikipedia.org/wiki/PBKDF2). This parameter
is used in OS X. This field is required for managing passwords on OS X >= 10.8.

Requires features manages_password_salt.

key_membership
: Whether specified key/value pairs should be considered the
**complete list** (`inclusive`) or the **minimum list** (`minimum`) of
the user’s attributes. Defaults to `minimum`.

Valid values are `inclusive`, `minimum`.

keys
: Specify user attributes in an array of key = value pairs.

Requires features manages_solaris_rbac.

managehome
: Whether to manage the home directory when managing the user.
This will create the home directory when `ensure => present`, and
delete the home directory when `ensure => absent`. Defaults to `false`.

Valid values are `true`, `false`, `yes`, `no`.

membership
: Whether specified groups should be considered the **complete list**
(`inclusive`) or the **minimum list** (`minimum`) of groups to which
the user belongs. Defaults to `minimum`.

Valid values are `inclusive`, `minimum`.

name
: The user name. While naming limitations vary by operating system,
it is advisable to restrict names to the lowest common denominator,
which is a maximum of 8 characters beginning with a letter.

Note that Puppet considers user names to be case-sensitive, regardless
of the platform’s own rules; be sure to always use the same case when
referring to a given user.

password
: The user’s password, in whatever encrypted format the local
system requires.

* Most modern Unix-like systems use salted SHA1 password hashes. You can use
Puppet’s built-in `sha1` function to generate a hash from a password.
* Mac OS X 10.5 and 10.6 also use salted SHA1 hashes.
* Mac OS X 10.7 (Lion) uses salted SHA512 hashes. The Puppet Labs [stdlib][]
module contains a `str2saltedsha512` function which can generate password
hashes for Lion.
* Mac OS X 10.8 and higher use salted SHA512 PBKDF2 hashes. When
managing passwords on these systems the salt and iterations properties
need to be specified as well as the password.
* Windows passwords can only be managed in cleartext, as there is no Windows API
for setting the password hash.

[stdlib]: https://github.com/puppetlabs/puppetlabs-stdlib/

Be sure to enclose any value that includes a dollar sign ($) in single
quotes (‘) to avoid accidental variable interpolation.

Requires features manages_passwords.

password_max_age
: The maximum number of days a password may be used before it must be changed.

Requires features manages_password_age.

password_min_age
: The minimum number of days a password must be used before it may be changed.

Requires features manages_password_age.

profile_membership
: Whether specified roles should be treated as the **complete list**
(`inclusive`) or the **minimum list** (`minimum`) of roles
of which the user is a member. Defaults to `minimum`.

Valid values are `inclusive`, `minimum`.

profiles
: The profiles the user has. Multiple profiles should be
specified as an array.

Requires features manages_solaris_rbac.

project
: The name of the project associated with a user.

Requires features manages_solaris_rbac.

provider
: The specific backend to use for this `user`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

aix
: User management for AIX.

* Required binaries: `/bin/chpasswd`, `/usr/bin/chuser`, `/usr/bin/mkuser`, `/usr/sbin/lsgroup`, `/usr/sbin/lsuser`, `/usr/sbin/rmuser`.
* Default for `operatingsystem` == `aix`.
* Supported features: `manages_aix_lam`, `manages_expiry`, `manages_homedir`, `manages_password_age`, `manages_passwords`, `manages_shell`.

directoryservice
: User management on OS X.

* Required binaries: `/usr/bin/dscacheutil`, `/usr/bin/dscl`, `/usr/bin/dsimport`, `/usr/bin/plutil`, `/usr/bin/uuidgen`.
* Default for `operatingsystem` == `darwin`.
* Supported features: `manages_password_salt`, `manages_passwords`, `manages_shell`.

hpuxuseradd
: User management for HP-UX. This provider uses the undocumented `-F`
switch to HP-UX’s special `usermod` binary to work around the fact that
its standard `usermod` cannot make changes while the user is logged in.

* Required binaries: `/usr/sam/lbin/useradd.sam`, `/usr/sam/lbin/userdel.sam`, `/usr/sam/lbin/usermod.sam`.
* Default for `operatingsystem` == `hp-ux`.
* Supported features: `allows_duplicates`, `manages_homedir`, `manages_passwords`.

ldap
: User management via LDAP.

This provider requires that you have valid values for all of the
LDAP-related settings in `puppet.conf`, including `ldapbase`. You will
almost definitely need settings for `ldapuser` and `ldappassword` in order
for your clients to write to LDAP.

Note that this provider will automatically generate a UID for you if
you do not specify one, but it is a potentially expensive operation,
as it iterates across all existing users to pick the appropriate next one.

* Supported features: `manages_passwords`, `manages_shell`.

pw
: User management via `pw` on FreeBSD and DragonFly BSD.

* Required binaries: `pw`.
* Default for `operatingsystem` == `freebsd, dragonfly`.
* Supported features: `allows_duplicates`, `manages_expiry`, `manages_homedir`, `manages_passwords`, `manages_shell`.

user_role_add
: User and role management on Solaris, via `useradd` and `roleadd`.

* Required binaries: `passwd`, `roleadd`, `roledel`, `rolemod`, `useradd`, `userdel`, `usermod`.
* Default for `osfamily` == `solaris`.
* Supported features: `allows_duplicates`, `manages_homedir`, `manages_password_age`, `manages_passwords`, `manages_shell`, `manages_solaris_rbac`.

useradd
: User management via `useradd` and its ilk. Note that you will need to
install Ruby’s shadow password library (often known as `ruby-libshadow`)
if you wish to manage user passwords.

* Required binaries: `chage`, `luseradd`, `useradd`, `userdel`, `usermod`.
* Supported features: `allows_duplicates`, `libuser`, `manages_expiry`, `manages_homedir`, `manages_password_age`, `manages_passwords`, `manages_shell`, `system_users`.

windows_adsi
: Local user management for Windows.

* Default for `operatingsystem` == `windows`.
* Supported features: `manages_homedir`, `manages_passwords`.

purge_ssh_keys
: Whether to purge authorized SSH keys for this user if they are not managed
with the `ssh_authorized_key` resource type. Allowed values are:

* `false` (default) — don’t purge SSH keys for this user.
* `true` — look for keys in the `.ssh/authorized_keys` file in the user’s
home directory. Purge any keys that aren’t managed as `ssh_authorized_key`
resources.
* An array of file paths — look for keys in all of the files listed. Purge
any keys that aren’t managed as `ssh_authorized_key` resources. If any of
these paths starts with `~` or `%h`, that token will be replaced with
the user’s home directory.

Valid values are `true`, `false`.

role_membership
: Whether specified roles should be considered the **complete list**
(`inclusive`) or the **minimum list** (`minimum`) of roles the user
has. Defaults to `minimum`.

Valid values are `inclusive`, `minimum`.

roles
: The roles the user has. Multiple roles should be
specified as an array.

Requires features manages_solaris_rbac.

salt
: This is the 32 byte salt used to generate the PBKDF2 password used in
OS X. This field is required for managing passwords on OS X >= 10.8.

Requires features manages_password_salt.

shell
: The user’s login shell. The shell must exist and be
executable.

This attribute cannot be managed on Windows systems.

Requires features manages_shell.

system
: Whether the user is a system user, according to the OS’s criteria;
on most platforms, a UID less than or equal to 500 indicates a system
user. This parameter is only used when the resource is created and will
not affect the UID when the user is present. Defaults to `false`.

Valid values are `true`, `false`, `yes`, `no`.

uid
: The user ID; must be specified numerically. If no user ID is
specified when creating a new user, then one will be chosen
automatically. This will likely result in the same user having
different UIDs on different systems, which is not recommended. This is
especially noteworthy when managing the same user on both Darwin and
other platforms, since Puppet does UID generation on Darwin, but
the underlying tools do so on other platforms.

On Windows, this property is read-only and will return the user’s
security identifier (SID).
—————-

### vlan

Manages a VLAN on a router or switch.

#### Parameters
description
: The VLAN’s name.

device_url
: The URL of the router or switch maintaining this VLAN.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

name
: The numeric VLAN ID.

Values can match `/^\d+/`.

provider
: The specific backend to use for this `vlan`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

cisco
: Cisco switch/router provider for vlans.
—————-

### yumrepo

The client-side description of a yum repository. Repository
configurations are found by parsing `/etc/yum.conf` and
the files indicated by the `reposdir` option in that file
(see `yum.conf(5)` for details).

Most parameters are identical to the ones documented
in the `yum.conf(5)` man page.

Continuation lines that yum supports (for the `baseurl`, for example)
are not supported. This type does not attempt to read or verify the
exinstence of files listed in the `include` attribute.

#### Parameters
bandwidth
: Use to specify the maximum available network bandwidth
in bytes/second. Used with the `throttle` option. If `throttle`
is a percentage and `bandwidth` is `0` then bandwidth throttling
will be disabled. If `throttle` is expressed as a data rate then
this option is ignored.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^\d+[kMG]?$/`.

baseurl
: The URL for this repository. Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

cost
: Cost of this repository. Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^\d+$/`.

descr
: A human-readable description of the repository.
This corresponds to the name parameter in `yum.conf(5)`.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

enabled
: Whether this repository is enabled.
Valid values are: False/0/No or True/1/Yes.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^(True|False|0|1|No|Yes)$/i`.

enablegroups
: Whether yum will allow the use of package groups for this
repository.
Valid values are: False/0/No or True/1/Yes.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^(True|False|0|1|No|Yes)$/i`.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

exclude
: List of shell globs. Matching packages will never be
considered in updates or installs for this repo.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

failovermethod
: The failover method for this repository; should be either
`roundrobin` or `priority`. Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^roundrobin|priority$/`.

gpgcakey
: The URL for the GPG CA key for this repository. Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

gpgcheck
: Whether to check the GPG signature on packages installed
from this repository.
Valid values are: False/0/No or True/1/Yes.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^(True|False|0|1|No|Yes)$/i`.

gpgkey
: The URL for the GPG key with which packages from this
repository are signed. Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

http_caching
: What to cache from this repository. Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^(packages|all|none)$/`.

include
: The URL of a remote file containing additional yum configuration
settings. Puppet does not check for this file’s existence or validity.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

includepkgs
: List of shell globs. If this is set, only packages
matching one of the globs will be considered for
update or install from this repo. Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

keepalive
: Whether HTTP/1.1 keepalive should be used with this repository.
Valid values are: False/0/No or True/1/Yes.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^(True|False|0|1|No|Yes)$/i`.

metadata_expire
: Number of seconds after which the metadata will expire.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^([0-9]+[dhm]?|never)$/`.

metalink
: Metalink for mirrors. Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

mirrorlist
: The URL that holds the list of mirrors for this repository.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

mirrorlist_expire
: Time (in seconds) after which the mirrorlist locally cached
will expire.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^[0-9]+$/`.

name
: The name of the repository. This corresponds to the
`repositoryid` parameter in `yum.conf(5)`.

priority
: Priority of this repository from 1-99. Requires that
the `priorities` plugin is installed and enabled.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

protect
: Enable or disable protection for this repository. Requires
that the `protectbase` plugin is installed and enabled.
Valid values are: False/0/No or True/1/Yes.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^(True|False|0|1|No|Yes)$/i`.

provider
: The specific backend to use for this `yumrepo`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

inifile
: Manage yum repo configurations by parsing yum INI configuration files.

## Fetching instances

When fetching repo instances, directory entries in ‘/etc/yum/repos.d’,
‘/etc/yum.repos.d’, and the directory optionally specified by the reposdir
key in ‘/etc/yum.conf’ will be checked. If a given directory does not exist it
will be ignored. In addition, all sections in ‘/etc/yum.conf’ aside from
‘main’ will be created as sections.

## Storing instances

When creating a new repository, a new section will be added in the first
yum repo directory that exists. The custom directory specified by the
‘/etc/yum.conf’ reposdir property is checked first, followed by
‘/etc/yum/repos.d’, and then ‘/etc/yum.repos.d’. If none of these exist, the
section will be created in ‘/etc/yum.conf’.

proxy
: URL of a proxy server that Yum should use when accessing this repository.
This attribute can also be set to `’_none_’`, which will make Yum bypass any
global proxy settings when accessing this repository.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

proxy_password
: Password for this proxy. Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

proxy_username
: Username for this proxy. Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

repo_gpgcheck
: Whether to check the GPG signature on repodata.
Valid values are: False/0/No or True/1/Yes.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^(True|False|0|1|No|Yes)$/i`.

retries
: Set the number of times any attempt to retrieve a file should
retry before returning an error. Setting this to `0` makes yum
try forever.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^[0-9]+$/`.

s3_enabled
: Access the repo via S3.
Valid values are: False/0/No or True/1/Yes.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^(True|False|0|1|No|Yes)$/i`.

skip_if_unavailable
: Should yum skip this repository if unable to reach it.
Valid values are: False/0/No or True/1/Yes.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^(True|False|0|1|No|Yes)$/i`.

sslcacert
: Path to the directory containing the databases of the
certificate authorities yum should use to verify SSL certificates.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

sslclientcert
: Path to the SSL client certificate yum should use to connect
to repos/remote sites. Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

sslclientkey
: Path to the SSL client key yum should use to connect
to repos/remote sites. Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/.*/`.

sslverify
: Should yum verify SSL certificates/hosts at all.
Valid values are: False/0/No or True/1/Yes.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^(True|False|0|1|No|Yes)$/i`.

target
: The filename to write the yum repository to.

throttle
: Enable bandwidth throttling for downloads. This option
can be expressed as a absolute data rate in bytes/sec or a
percentage `60%`. An SI prefix (k, M or G) may be appended
to the data rate values.
Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^\d+[kMG%]?$/`.

timeout
: Number of seconds to wait for a connection before timing
out. Set this to `absent` to remove it from the file completely.

Valid values are `absent`. Values can match `/^\d+$/`.
—————-

### zfs

Manage zfs. Create destroy and set properties on zfs instances.

**Autorequires:** If Puppet is managing the zpool at the root of this zfs
instance, the zfs resource will autorequire it. If Puppet is managing any
parent zfs instances, the zfs resource will autorequire them.

#### Parameters
aclinherit
: The aclinherit property. Valid values are `discard`, `noallow`, `restricted`, `passthrough`, `passthrough-x`.

aclmode
: The aclmode property. Valid values are `discard`, `groupmask`, `passthrough`.

atime
: The atime property. Valid values are `on`, `off`.

canmount
: The canmount property. Valid values are `on`, `off`, `noauto`.

checksum
: The checksum property. Valid values are `on`, `off`, `fletcher2`, `fletcher4`, `sha256`.

compression
: The compression property. Valid values are `on`, `off`, `lzjb`, `gzip`, `gzip-[1-9]`, `zle`.

copies
: The copies property. Valid values are `1`, `2`, `3`.

dedup
: The dedup property. Valid values are `on`, `off`.

devices
: The devices property. Valid values are `on`, `off`.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

exec
: The exec property. Valid values are `on`, `off`.

logbias
: The logbias property. Valid values are `latency`, `throughput`.

mountpoint
: The mountpoint property. Valid values are `<path>`, `legacy`, `none`.

name
: The full name for this filesystem (including the zpool).

nbmand
: The nbmand property. Valid values are `on`, `off`.

primarycache
: The primarycache property. Valid values are `all`, `none`, `metadata`.

provider
: The specific backend to use for this `zfs`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

zfs
: Provider for zfs.

* Required binaries: `zfs`.

quota
: The quota property. Valid values are `<size>`, `none`.

readonly
: The readonly property. Valid values are `on`, `off`.

recordsize
: The recordsize property. Valid values are powers of two between 512 and 128k.

refquota
: The refquota property. Valid values are `<size>`, `none`.

refreservation
: The refreservation property. Valid values are `<size>`, `none`.

reservation
: The reservation property. Valid values are `<size>`, `none`.

secondarycache
: The secondarycache property. Valid values are `all`, `none`, `metadata`.

setuid
: The setuid property. Valid values are `on`, `off`.

shareiscsi
: The shareiscsi property. Valid values are `on`, `off`, `type=<type>`.

sharenfs
: The sharenfs property. Valid values are `on`, `off`, share(1M) options

sharesmb
: The sharesmb property. Valid values are `on`, `off`, sharemgr(1M) options

snapdir
: The snapdir property. Valid values are `hidden`, `visible`.

version
: The version property. Valid values are `1`, `2`, `3`, `4`, `current`.

volsize
: The volsize property. Valid values are `<size>`

vscan
: The vscan property. Valid values are `on`, `off`.

xattr
: The xattr property. Valid values are `on`, `off`.

zoned
: The zoned property. Valid values are `on`, `off`.
—————-

### zone

Manages Solaris zones.

**Autorequires:** If Puppet is managing the directory specified as the root of
the zone’s filesystem (with the `path` attribute), the zone resource will
autorequire that directory.

#### Parameters
autoboot
: Whether the zone should automatically boot.

Valid values are `true`, `false`.

clone
: Instead of installing the zone, clone it from another zone.
If the zone root resides on a zfs file system, a snapshot will be
used to create the clone; if it resides on a ufs filesystem, a copy of the
zone will be used. The zone from which you clone must not be running.

create_args
: Arguments to the `zonecfg` create command. This can be used to create branded zones.

dataset
: The list of datasets delegated to the non-global zone from the
global zone. All datasets must be zfs filesystem names which are
different from the mountpoint.

ensure
: The running state of the zone. The valid states directly reflect
the states that `zoneadm` provides. The states are linear,
in that a zone must be `configured`, then `installed`, and
only then can be `running`. Note also that `halt` is currently
used to stop zones.

Valid values are `absent`, `configured`, `installed`, `running`.

id
: The numerical ID of the zone. This number is autogenerated
and cannot be changed.

inherit
: The list of directories that the zone inherits from the global
zone. All directories must be fully qualified.

install_args
: Arguments to the `zoneadm` install command. This can be used to create branded zones.

ip
: The IP address of the zone. IP addresses **must** be specified
with an interface, and may optionally be specified with a default router
(sometimes called a defrouter). The interface, IP address, and default
router should be separated by colons to form a complete IP address string.
For example: `bge0:192.168.178.200` would be a valid IP address string
without a default router, and `bge0:192.168.178.200:192.168.178.1` adds a
default router to it.

For zones with multiple interfaces, the value of this attribute should be
an array of IP address strings (each of which must include an interface
and may include a default router).

iptype
: The IP stack type of the zone.

Valid values are `shared`, `exclusive`.

name
: The name of the zone.

path
: The root of the zone’s filesystem. Must be a fully qualified
file name. If you include `%s` in the path, then it will be
replaced with the zone’s name. Currently, you cannot use
Puppet to move a zone. Consequently this is a readonly property.

pool
: The resource pool for this zone.

provider
: The specific backend to use for this `zone`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

solaris
: Provider for Solaris Zones.

* Required binaries: `/usr/sbin/zoneadm`, `/usr/sbin/zonecfg`.
* Default for `osfamily` == `solaris`.

realhostname
: The actual hostname of the zone.

shares
: Number of FSS CPU shares allocated to the zone.

sysidcfg
: The text to go into the `sysidcfg` file when the zone is first
booted. The best way is to use a template:

# $confdir/modules/site/templates/sysidcfg.erb
system_locale=en_US
timezone=GMT
terminal=xterms
security_policy=NONE
root_password=<%= password %>
timeserver=localhost
name_service=DNS {domain_name=<%= domain %> name_server=<%= nameserver %>}
network_interface=primary {hostname=<%= realhostname %>
ip_address=<%= ip %>
netmask=<%= netmask %>
protocol_ipv6=no
default_route=<%= defaultroute %>}
nfs4_domain=dynamic

And then call that:

zone { myzone:
ip => “bge0:192.168.0.23”,
sysidcfg => template(“site/sysidcfg.erb”),
path => “/opt/zones/myzone”,
realhostname => “fully.qualified.domain.name”
}

The `sysidcfg` only matters on the first booting of the zone,
so Puppet only checks for it at that time.
—————-

### zpool

Manage zpools. Create and delete zpools. The provider WILL NOT SYNC, only report differences.

Supports vdevs with mirrors, raidz, logs and spares.

#### Parameters
disk
: The disk(s) for this pool. Can be an array or a space separated string.

ensure
: The basic property that the resource should be in.

Valid values are `present`, `absent`.

log
: Log disks for this pool. This type does not currently support mirroring of log disks.

mirror
: List of all the devices to mirror for this pool. Each mirror should be a
space separated string:

mirror => [“disk1 disk2”, “disk3 disk4”],

pool
: (**Namevar:** If omitted, this parameter’s value defaults to the resource’s title.)

The name for this pool.

provider
: The specific backend to use for this `zpool`
resource. You will seldom need to specify this — Puppet will usually
discover the appropriate provider for your platform.Available providers are:

zpool
: Provider for zpool.

* Required binaries: `zpool`.

raid_parity
: Determines parity when using the `raidz` parameter.

raidz
: List of all the devices to raid for this pool. Should be an array of
space separated strings:

raidz => [“disk1 disk2”, “disk3 disk4”],

spare
: Spare disk(s) for this pool.
—————-

*This page autogenerated on 2017-01-11 16:46:05 +0000*

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s