1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
---
inMenu: true
title: Configuration Reference
orderInfo: 40
---
# Puppet Configuration Reference
## Specifying Configuration Parameters
Every Puppet executable (with the exception of ``puppetdoc``) accepts all of
the arguments below, but not all of the arguments make sense for every executable.
Each argument has a section listed with it in parentheses; often, that section
will map to an executable (e.g., ``puppetd``), in which case it probably only
makes sense for that one executable. If ``puppet`` is listed as the section,
it is most likely an option that is valid for everyone.
This will not always be the case. I have tried to be as thorough as possible
in the descriptions of the arguments, so it should be obvious whether an
argument is appropriate or not.
These arguments can be supplied to the executables either as command-line
arugments or in the configuration file for the appropriate executable. For
instance, the command-line invocation below would set the configuration directory
to /private/puppet
$ puppetd --confdir=/private/puppet
Note that boolean options are turned on and off with a slightly different syntax
on the command line:
$ puppetd --storeconfigs
$ puppetd --no-storeconfigs
The invocations above will enable and disable, respectively, the storage of
the client configuration.
As mentioned above, the configuration parameters can also be stored in a
configuration file located in the configuration directory (`/etc/puppet`
by default). The file is named for the executable it is intended for, for
example `/etc/puppetd.conf` is the configuration file for `puppetd`.
The file, which follows INI-style formatting, should contain a bracketed
heading named for the executable, followed by pairs of parameters with their
values. Here is an example of a very simple `puppetd.conf` file:
[puppetd]
confdir = /private/puppet
storeconfigs = true
Note that boolean parameters must be explicitly specified as `true` or
`false` as seen above.
If you're starting out with a fresh configuration, you may wish to let
the executable generate a template configuration file for you by invoking
the executable in question with the `--genconfig` command. The executable
will print a template configuration to standard output, which can be
redirected to a file like so:
$ puppetd --genconfig > /etc/puppet/puppetd.conf
Note that this invocation will "clobber" (throw away) the contents of any
pre-existing `puppetd.conf` file, so make a backup of your present config
if it contains valuable information.
Like the `--genconfig` argument, the executables also accept a `--genmanifest`
argument, which will generate a manifest that can be used to manage all of
Puppet's directories and files and prints it to standard output. This can
likewise be redirected to a file:
$ puppetd --genmanifest > /etc/puppet/manifests/site.pp
Puppet can also create user and group accounts for itself (one `puppet` group
and one `puppet` user) if it is invoked as `root` with the `--mkusers` argument:
$ puppetd --mkusers
## Signals
The `puppetd` and `puppetmasterd` executables catch some signals for special
handling. Both daemons catch (`SIGHUP`), which forces the server to restart
tself. Predictably, interrupt and terminate (`SIGINT` and `SIGHUP`) will shut
down the server, whether it be an instance of `puppetd` or `puppetmasterd`.
Sending the `SIGUSR1` signal to an instance of `puppetd` will cause it to
immediately begin a new configuration transaction with the server. This
signal has no effect on `puppetmasterd`.
## Configuration Parameter Reference
Below is a list of all documented parameters. Any default values are in ``block type`` at the end of the description.
|
