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
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
# File 'lib/puppet/application/apply.rb', line 38
def help
<<-HELP
puppet-apply(8) -- #{summary}
========
SYNOPSIS
--------
Applies a standalone Puppet manifest to the local system.
USAGE
-----
puppet apply [-h|--help] [-V|--version] [-d|--debug] [-v|--verbose]
[-e|--execute] [--detailed-exitcodes] [-L|--loadclasses]
[-l|--logdest syslog|eventlog|<FILE>|console] [--noop]
[--catalog <catalog>] [--write-catalog-summary] <file>
DESCRIPTION
-----------
This is the standalone puppet execution tool; use it to apply
individual manifests.
When provided with a modulepath, via command line or config file, puppet
apply can effectively mimic the catalog that would be served by puppet
master with access to the same modules, although there are some subtle
differences. When combined with scheduling and an automated system for
pushing manifests, this can be used to implement a serverless Puppet
site.
Most users should use 'puppet agent' and 'puppet master' for site-wide
manifests.
OPTIONS
-------
Note that any setting that's valid in the configuration
file is also a valid long argument. For example, 'tags' is a
valid setting, so you can specify '--tags <class>,<tag>'
as an argument.
See the configuration file documentation at
https://docs.puppetlabs.com/puppet/latest/reference/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.
* --detailed-exitcodes:
Provide extra information about the run via exit codes. If enabled, 'puppet
apply' will use the following exit codes:
0: The run succeeded with no changes or failures; the system was already in
the desired state.
1: The run failed.
2: The run succeeded, and some resources were changed.
4: The run succeeded, and some resources failed.
6: The run succeeded, and included both changes and failures.
* --help:
Print this help message
* --loadclasses:
Load any stored classes. 'puppet agent' caches configured classes
(usually at /etc/puppetlabs/puppet/classes.txt), and setting this option causes
all of those classes to be set in your puppet manifest.
* --logdest:
Where to send log messages. Choose between 'syslog' (the POSIX syslog
service), 'eventlog' (the Windows Event Log), 'console', or the path to a log
file. Defaults to 'console'.
A path ending with '.json' will receive structured output in JSON format. The
log file will not have an ending ']' automatically written to it due to the
appending nature of logging. It must be appended manually to make the content
valid JSON.
* --noop:
Use 'noop' mode where Puppet runs in a no-op or dry-run mode. This
is useful for seeing what changes Puppet will make without actually
executing the changes.
* --execute:
Execute a specific piece of Puppet code
* --test:
Enable the most common options used for testing. These are 'verbose',
'detailed-exitcodes' and 'show_diff'.
* --verbose:
Print extra information.
* --catalog:
Apply a JSON catalog (such as one generated with 'puppet master --compile'). You can
either specify a JSON file or pipe in JSON from standard input.
* --write-catalog-summary
After compiling the catalog saves the resource list and classes list to the node
in the state directory named classes.txt and resources.txt
EXAMPLE
-------
$ puppet apply -l /tmp/manifest.log manifest.pp
$ puppet apply --modulepath=/root/dev/modules -e "include ntpd::server"
$ puppet apply --catalog catalog.json
AUTHOR
------
Luke Kanies
COPYRIGHT
---------
Copyright (c) 2011 Puppet Inc., LLC Licensed under the Apache 2.0 License
HELP
end
|