puppet help doc

mshaik@noc:~$ sudo apt-get install puppet

mshaik@noc:~$ puppet –version
3.8.5

mshaik@noc:~$ puppet resource package |less
package { ‘vagrant’:
ensure => ‘1:2.0.2’,
}

package { ‘telnet’:
ensure => ‘0.17-40’,
}

mshaik@noc:~$ puppet resource package whois
package { ‘whois’:
ensure => ‘5.2.11’,
}

mshaik@noc:~$ puppet resource package nmap
package { ‘nmap’:
ensure => ‘purged’,
}

mshaik@noc:~$ puppet resource package –help

puppet-resource(8) — The resource abstraction layer shell
========

SYNOPSIS
——–
Uses the Puppet RAL to directly interact with the system.

 

USAGE
—–
puppet resource [-h|–help] [-d|–debug] [-v|–verbose] [-e|–edit]
[-H|–host <host>] [-p|–param <parameter>] [-t|–types] <type>
[<name>] [<attribute>=<value> …]

 

DESCRIPTION
———–
This command provides simple facilities for converting current system
state into Puppet code, along with some ability to modify the current
state using Puppet’s RAL.

By default, you must at least provide a type to list, in which case
puppet resource will tell you everything it knows about all resources of
that type. You can optionally specify an instance name, and puppet
resource will only describe that single instance.

If given a type, a name, and a series of <attribute>=<value> pairs,
puppet resource will modify the state of the specified resource.
Alternately, if given a type, a name, and the ‘–edit’ flag, puppet
resource will write its output to a file, open that file in an editor,
and then apply the saved file as a Puppet transaction.

 

OPTIONS
——-
Note that any setting that’s valid in the configuration
file is also a valid long argument. For example, ‘ssldir’ is a valid
setting, so you can specify ‘–ssldir <directory>’ as an
argument.

See the configuration file documentation at
http://docs.puppetlabs.com/references/stable/configuration.html for the
full list of acceptable parameters. A commented list of all
configuration options can also be generated by running puppet with
‘–genconfig’.

* –debug:
Enable full debugging.

* –edit:
Write the results of the query to a file, open the file in an editor,
and read the file back in as an executable Puppet manifest.

* –host:
When specified, connect to the resource server on the named host
and retrieve the list of resouces of the type specified.

* –help:
Print this help message.

* –param:
Add more parameters to be outputted from queries.

* –types:
List all available types.

* –verbose:
Print extra information.

 

EXAMPLE
——-
This example uses `puppet resource` to return a Puppet configuration for
the user `luke`:

$ puppet resource user luke
user { ‘luke’:
home => ‘/home/luke’,
uid => ‘100’,
ensure => ‘present’,
comment => ‘Luke Kanies,,,’,
gid => ‘1000’,
shell => ‘/bin/bash’,
groups => [‘sysadmin’,’audio’,’video’,’puppet’]
}

 

AUTHOR
——
Luke Kanies

 

COPYRIGHT
———
Copyright (c) 2011 Puppet Labs, LLC Licensed under the Apache 2.0 License

mshaik@noc:~$ puppet resource service sshd
service { ‘sshd’:
ensure => ‘running’,
enable => ‘true’,
}

mshaik@noc:~$ puppet resource service apache2
service { ‘apache2’:
ensure => ‘stopped’,
enable => ‘false’,
}

mshaik@noc:~$ puppet resource service –help

puppet-resource(8) — The resource abstraction layer shell
========

SYNOPSIS
——–
Uses the Puppet RAL to directly interact with the system.

 

USAGE
—–
puppet resource [-h|–help] [-d|–debug] [-v|–verbose] [-e|–edit]
[-H|–host <host>] [-p|–param <parameter>] [-t|–types] <type>
[<name>] [<attribute>=<value> …]

 

DESCRIPTION
———–
This command provides simple facilities for converting current system
state into Puppet code, along with some ability to modify the current
state using Puppet’s RAL.

By default, you must at least provide a type to list, in which case
puppet resource will tell you everything it knows about all resources of
that type. You can optionally specify an instance name, and puppet
resource will only describe that single instance.

If given a type, a name, and a series of <attribute>=<value> pairs,
puppet resource will modify the state of the specified resource.
Alternately, if given a type, a name, and the ‘–edit’ flag, puppet
resource will write its output to a file, open that file in an editor,
and then apply the saved file as a Puppet transaction.

 

OPTIONS
——-
Note that any setting that’s valid in the configuration
file is also a valid long argument. For example, ‘ssldir’ is a valid
setting, so you can specify ‘–ssldir <directory>’ as an
argument.

See the configuration file documentation at
http://docs.puppetlabs.com/references/stable/configuration.html for the
full list of acceptable parameters. A commented list of all
configuration options can also be generated by running puppet with
‘–genconfig’.

* –debug:
Enable full debugging.

* –edit:
Write the results of the query to a file, open the file in an editor,
and read the file back in as an executable Puppet manifest.

* –host:
When specified, connect to the resource server on the named host
and retrieve the list of resouces of the type specified.

* –help:
Print this help message.

* –param:
Add more parameters to be outputted from queries.

* –types:
List all available types.

* –verbose:
Print extra information.

 

EXAMPLE
——-
This example uses `puppet resource` to return a Puppet configuration for
the user `luke`:

$ puppet resource user luke
user { ‘luke’:
home => ‘/home/luke’,
uid => ‘100’,
ensure => ‘present’,
comment => ‘Luke Kanies,,,’,
gid => ‘1000’,
shell => ‘/bin/bash’,
groups => [‘sysadmin’,’audio’,’video’,’puppet’]
}

 

AUTHOR
——
Luke Kanies

 

COPYRIGHT
———
Copyright (c) 2011 Puppet Labs, LLC Licensed under the Apache 2.0 License

 

mshaik@noc:~$ puppet describe user

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.

 

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.

– **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).

Providers
———
aix, directoryservice, hpuxuseradd, ldap, pw, user_role_add, useradd,
windows_adsi

mshaik@noc:~$ puppet doc |less

mshaik@noc:~$ puppet doc > puppet_doc

mshaik@noc:~$ puppet describe resource file
Unknown type resource

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.

 

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
or
or
or
](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*)
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 `\\`).

– **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: `%`

Providers
———
posix, windows

 

Leave a comment