diff --git a/api/docs/http_certificate.md b/api/docs/http_certificate.md index 549b7214856..34c30f30dff 100644 --- a/api/docs/http_certificate.md +++ b/api/docs/http_certificate.md @@ -5,7 +5,7 @@ The `certificate` endpoint returns the certificate for the specified name, which might be either a standard certname or `ca`. Under Puppet Server's CA service, the `environment` parameter is ignored and can -be omitted. Under a Rack or WEBrick Puppet master, `environment` is required and +be omitted. Under a Rack or WEBrick Puppet server, `environment` is required and must be a valid environment, but it has no effect on the response. Find @@ -91,14 +91,14 @@ None No request key specified in /puppet-ca/v1/certificate -#### Master is not a CA +#### Server is not a CA GET /puppet/v1/certificate/valid_certificate?environment=env HTTP/1.1 400 Bad Request Content-Type: text/plain - this master is not a CA + this server is not a CA Schema diff --git a/api/docs/http_certificate_request.md b/api/docs/http_certificate_request.md index 4378b2b3312..3ab0b30e840 100644 --- a/api/docs/http_certificate_request.md +++ b/api/docs/http_certificate_request.md @@ -2,11 +2,11 @@ Certificate Request ============= The `certificate_request` endpoint submits a Certificate Signing Request (CSR) -to the master. The master must be configured to be a CA. The returned +to the server. The server must be configured to be a CA. The returned CSR is always in the `.pem` format. Under Puppet Server's CA service, the `environment` parameter is ignored and can -be omitted. Under a Rack or WEBrick Puppet master, `environment` is required and +be omitted. Under a Rack or WEBrick Puppet server, `environment` is required and must be a valid environment, but it has no effect on the response. Find diff --git a/api/docs/http_certificate_revocation_list.md b/api/docs/http_certificate_revocation_list.md index 83d239c2699..676ebfa0c24 100644 --- a/api/docs/http_certificate_revocation_list.md +++ b/api/docs/http_certificate_revocation_list.md @@ -2,11 +2,11 @@ Certificate Revocation List =========================== The `certificate_revocation_list` endpoint retrieves a Certificate Revocation List (CRL) -from the master. The master must be configured to be a CA. The returned +from the server. The server must be configured to be a CA. The returned CRL is always in the `.pem` format. Under Puppet Server's CA service, the `environment` parameter is ignored and can -be omitted. Under a Rack or WEBrick Puppet master, `environment` is required and +be omitted. Under a Rack or WEBrick Puppet server, `environment` is required and must be a valid environment, but it has no effect on the response. The `:nodename` should always be `ca`, due to Puppet Server's default diff --git a/api/docs/http_certificate_status.md b/api/docs/http_certificate_status.md index 74132b30d8e..fb5c301a51d 100644 --- a/api/docs/http_certificate_status.md +++ b/api/docs/http_certificate_status.md @@ -6,7 +6,7 @@ status of a certificate or pending certificate request. It is only useful on the CA. Under Puppet Server's CA service, the `environment` parameter is ignored and can -be omitted. Under a Rack or WEBrick Puppet master, `environment` is required and +be omitted. Under a Rack or WEBrick Puppet server, `environment` is required and must be a valid environment, but it has no effect on the response. Find @@ -68,7 +68,7 @@ Otherwise it returns This endpoint is disabled in the default configuration. It is recommended to be careful with this endpoint, as it can allow control -over the certificates used by the puppet master. +over the certificates used by the Puppet server. GET, PUT, DELETE diff --git a/api/docs/http_environments.md b/api/docs/http_environments.md index 83996187e3f..f7ad53b45f4 100644 --- a/api/docs/http_environments.md +++ b/api/docs/http_environments.md @@ -1,7 +1,7 @@ Environments ============ -The `environments` endpoint allows for enumeration of the environments known to the master. Each environment contains information +The `environments` endpoint allows for enumeration of the environments known to the server. Each environment contains information about itself like its modulepath, manifest directory, environment timeout, and the config version. This endpoint is by default accessible to any client with a valid certificate, though this may be changed in Puppet Server's `auth.conf`. diff --git a/api/docs/http_report.md b/api/docs/http_report.md index 59d6c91b19a..38d77f716b5 100644 --- a/api/docs/http_report.md +++ b/api/docs/http_report.md @@ -1,17 +1,17 @@ Report ====== -This document describes the Puppet master's report endpoint and the schema for +This document describes the Puppet server's report endpoint and the schema for Report Format 12 in technical terms. Also see the [documentation](https://puppet.com/docs/puppet/latest/format_report.html). -The `report` endpoint allows clients to send reports to the master via `http` -or `https`. Once received by the master they are processed by the *report +The `report` endpoint allows clients to send reports to the server via `http` +or `https`. Once received by the server they are processed by the *report processors* configured to be triggered when a report is received. As an example, storing reports in PuppetDB is handled by one such report processor. Save ---- -The http(s) endpoint for sending reports to the master is: +The http(s) endpoint for sending reports to the server is: PUT /puppet/v3/report/:nodename?environment=:environment diff --git a/docs/indirector.md b/docs/indirector.md index be37e3cf108..afa0568e995 100644 --- a/docs/indirector.md +++ b/docs/indirector.md @@ -2,7 +2,7 @@ > This document describes Puppet's indirector subsystem, but it has a number of limitations described below. As a result, don't introduce any new indirections or termini. -Puppet's indirector supports pluggable backends (termini) for a variety of key-value stores (indirections). Each indirection type corresponds to a particular Ruby class (the "Indirected Class" below) and values are instances of that class. Each instance's key is available from its name method. The termini can be local (e.g., on-disk files) or remote (e.g., using a REST interface to talk to a puppet master). +Puppet's indirector supports pluggable backends (termini) for a variety of key-value stores (indirections). Each indirection type corresponds to a particular Ruby class (the "Indirected Class" below) and values are instances of that class. Each instance's key is available from its name method. The termini can be local (e.g., on-disk files) or remote (e.g., using a REST interface to talk to a Puppet server). An indirector has five methods, which are mapped into HTTP verbs for the REST interface: @@ -157,7 +157,7 @@ Always return an empty node object. Assumes you keep track of nodes in flat file Note that class is responsible for merging the node's facts into the node instance before it is returned. `rest` terminus -Get a node via REST. Puppet agent uses this to allow the puppet master to override its environment. +Get a node via REST. Puppet agent uses this to allow the Puppet server to override its environment. `store_configs` terminus Part of the "storeconfigs" feature. Should not be directly set by end users. @@ -189,7 +189,7 @@ Manipulate resources with the resource abstraction layer. Only used internally. Part of the "storeconfigs" feature. Should not be directly set by end users. `rest` terminus -Get puppet master's status via REST. Useful because it tests the health of both the web server and the indirector. +Get Puppet server's status via REST. Useful because it tests the health of both the web server and the indirector. ## Limitations diff --git a/docs/profiling.md b/docs/profiling.md index 76bf80c7097..863974c8a22 100644 --- a/docs/profiling.md +++ b/docs/profiling.md @@ -10,11 +10,11 @@ spots. This can only work with code that is explicitly instrumented, which, at the time of this writing, is primarily the compiler. To enable profiling there are several options: -* To profile every request on the master add `--profile` to your master's +* To profile every request on the server add `--profile` to your server's startup. * To profile a single run for an agent add `--profile` to your agent's options for that run. -* To profile a masterless run add `--profile` to your `puppet apply` options. +* To profile a serverless run add `--profile` to your `puppet apply` options. The timing information will be output to the logs and tagged with the word "PROFILE". @@ -28,8 +28,8 @@ will be output to the logs. For much finer grained profiling, you'll want to use [ruby-prof](https://rubygems.org/gems/ruby-prof). Once you have the gem installed you can either modify the code to profile a certain section (using -RubyProf.profile) or run the master with ruby-prof by adding `use -Rack::RubyProf, :path => '/temp/profile'` to the config.ru for your master. +RubyProf.profile) or run the server with ruby-prof by adding `use +Rack::RubyProf, :path => '/temp/profile'` to the config.ru for your server. ## Running the Benchmarks diff --git a/examples/enc/regexp_nodes/regexp_nodes.rb b/examples/enc/regexp_nodes/regexp_nodes.rb index b14d97d79ac..90b0a7b8732 100644 --- a/examples/enc/regexp_nodes/regexp_nodes.rb +++ b/examples/enc/regexp_nodes/regexp_nodes.rb @@ -13,7 +13,7 @@ # finds. Each file's contents are a regexp-per-line which, if they match the # hostname passed to the program as ARGV[0], sets a class, parameter value # or environment named the same thing as the file itself. At the end, the -# resultant data structure is returned back to the puppet master process as +# resultant data structure is returned back to the Puppet server process as # yaml. # # = Caveats diff --git a/lib/puppet/application/agent.rb b/lib/puppet/application/agent.rb index 5d9876ba82c..5394c627bca 100644 --- a/lib/puppet/application/agent.rb +++ b/lib/puppet/application/agent.rb @@ -92,7 +92,7 @@ def help SYNOPSIS -------- - Retrieves the client configuration from the Puppet master and applies it to + Retrieves the client configuration from the Puppet server and applies it to the local host. This service may be run as a daemon, run periodically using cron (or something @@ -355,7 +355,7 @@ def help * SIGINT and SIGTERM: Shut down the puppet agent daemon. * SIGUSR1: - Immediately retrieve and apply configurations from the puppet master. + Immediately retrieve and apply configurations from the Puppet server. * SIGUSR2: Close file descriptors for log files and reopen them. Used with logrotate. diff --git a/lib/puppet/application/apply.rb b/lib/puppet/application/apply.rb index 96d84cf7924..6bb69a2bd9a 100644 --- a/lib/puppet/application/apply.rb +++ b/lib/puppet/application/apply.rb @@ -64,13 +64,13 @@ def help 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 + apply can effectively mimic the catalog that would be served by Puppet + Server 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 + Most users should use 'puppet agent' and 'puppet server' for site-wide manifests. @@ -144,7 +144,7 @@ def help Print extra information. * --catalog: - Apply a JSON catalog (such as one generated with 'puppet master --compile'). You can + Apply a JSON catalog (such as one generated with 'puppet catalog compile'). You can either specify a JSON file or pipe in JSON from standard input. * --write-catalog-summary diff --git a/lib/puppet/application/device.rb b/lib/puppet/application/device.rb index bdae357f901..04079bafa93 100644 --- a/lib/puppet/application/device.rb +++ b/lib/puppet/application/device.rb @@ -92,7 +92,7 @@ def help SYNOPSIS -------- - Retrieves catalogs from the Puppet master and applies them to remote devices. + Retrieves catalogs from the Puppet server and applies them to remote devices. This subcommand can be run manually; or periodically using cron, a scheduled task, or a similar tool. diff --git a/lib/puppet/face/catalog.rb b/lib/puppet/face/catalog.rb index 205a1b55a97..4aaee90ba53 100644 --- a/lib/puppet/face/catalog.rb +++ b/lib/puppet/face/catalog.rb @@ -62,7 +62,7 @@ $ puppet catalog apply --terminus yaml - Retrieve a catalog from the master and apply it, in one step: + Retrieve a catalog from the server and apply it, in one step: $ puppet catalog apply --terminus rest @@ -119,10 +119,10 @@ end action(:download) do - summary "Download this node's catalog from the puppet master server." + summary "Download this node's catalog from the Puppet server." description <<-'EOT' - Retrieves a catalog from the puppet master and saves it to the local yaml - cache. This action always contacts the puppet master and will ignore + Retrieves a catalog from the Puppet server and saves it to the local yaml + cache. This action always contacts the Puppet server and will ignore alternate termini. The saved catalog can be used in any subsequent catalog action by specifying diff --git a/lib/puppet/face/catalog/select.rb b/lib/puppet/face/catalog/select.rb index 1d33fb97284..557ce4ad464 100644 --- a/lib/puppet/face/catalog/select.rb +++ b/lib/puppet/face/catalog/select.rb @@ -16,13 +16,13 @@ notes <<-'NOTES' By default, this action will retrieve a catalog from Puppet's compiler subsystem; you must call the action with `--terminus rest` if you wish - to retrieve a catalog from the puppet master. + to retrieve a catalog from the Puppet server. FORMATTING ISSUES: This action cannot currently render useful yaml; instead, it returns an entire catalog. Use json instead. NOTES examples <<-'EOT' - Ask the puppet master for a list of managed file resources for a node: + Ask the Puppet server for a list of managed file resources for a node: $ puppet catalog select --terminus rest somenode.magpie.lan file EOT diff --git a/lib/puppet/face/facts.rb b/lib/puppet/face/facts.rb index 2fbf30e989e..65b12b92191 100644 --- a/lib/puppet/face/facts.rb +++ b/lib/puppet/face/facts.rb @@ -38,7 +38,7 @@ deactivate_action(:search) action(:upload) do - summary _("Upload local facts to the puppet master.") + summary _("Upload local facts to the Puppet server.") description <<-'EOT' Reads facts from the local system using the `facter` terminus, then saves the returned facts using the rest terminus. diff --git a/lib/puppet/face/node/clean.rb b/lib/puppet/face/node/clean.rb index 0be63f74bf4..e559aeccebe 100644 --- a/lib/puppet/face/node/clean.rb +++ b/lib/puppet/face/node/clean.rb @@ -2,10 +2,10 @@ Puppet::Face.define(:node, '0.0.1') do action(:clean) do - summary _("Clean up signed certs, cached facts, node objects, and reports for a node stored by the puppetmaster") + summary _("Clean up signed certs, cached facts, node objects, and reports for a node stored by the Puppet server") arguments _(" [ ...]") description <<-'EOT' - Cleans up the following information a puppet master knows about a node: + Cleans up the following information a Puppet server knows about a node: - ($vardir/ssl/ca/signed/node.domain.pem) diff --git a/lib/puppet/face/plugin.rb b/lib/puppet/face/plugin.rb index 78dcd336f2d..bdbdb6ba475 100644 --- a/lib/puppet/face/plugin.rb +++ b/lib/puppet/face/plugin.rb @@ -9,19 +9,19 @@ summary _("Interact with the Puppet plugin system.") description <<-'EOT' - This subcommand provides network access to the puppet master's store of + This subcommand provides network access to the Puppet server's store of plugins. - The puppet master serves Ruby code collected from the `lib` directories + The Puppet server serves Ruby code collected from the `lib` directories of its modules. These plugins can be used on agent nodes to extend Facter and implement custom types and providers. Plugins are normally downloaded by puppet agent during the course of a run. EOT action :download do - summary _("Download plugins from the puppet master.") + summary _("Download plugins from the Puppet server.") description <<-'EOT' - Downloads plugins from the configured puppet master. Any plugins + Downloads plugins from the configured Puppet server. Any plugins downloaded in this way will be used in all subsequent Puppet activity. This action modifies files on disk. EOT @@ -31,11 +31,11 @@ the files downloaded, which will be empty if none were retrieved. EOT examples <<-'EOT' - Retrieve plugins from the puppet master: + Retrieve plugins from the Puppet server: $ puppet plugin download - Retrieve plugins from the puppet master (API example): + Retrieve plugins from the Puppet server (API example): $ Puppet::Face[:plugin, '0.0.1'].download EOT diff --git a/lib/puppet/face/report.rb b/lib/puppet/face/report.rb index 5ed1fc44b54..7fa1e094bd1 100644 --- a/lib/puppet/face/report.rb +++ b/lib/puppet/face/report.rb @@ -27,7 +27,7 @@ action(:submit) do summary _("API only: submit a report with error handling.") description <<-'EOT' - API only: Submits a report to the puppet master. This action is + API only: Submits a report to the Puppet server. This action is essentially a shortcut and wrapper for the `save` action with the `rest` terminus, and provides additional details in the event of a failure. EOT diff --git a/lib/puppet/indirector/face.rb b/lib/puppet/indirector/face.rb index 7cea172c3d7..5bd36aca853 100644 --- a/lib/puppet/indirector/face.rb +++ b/lib/puppet/indirector/face.rb @@ -13,9 +13,9 @@ class Puppet::Indirector::Face < Puppet::Face these backends are called terminuses. Almost all indirected subsystems have a `rest` terminus that interacts - with the puppet master's data. Most of them have additional terminuses + with the Puppet server's data. Most of them have additional terminuses for various local data models, which are in turn used by the indirected - subsystem on the puppet master whenever it receives a remote request. + subsystem on the Puppet server whenever it receives a remote request. The terminus for an action is often determined by context, but occasionally needs to be set explicitly. See the "Notes" section of this diff --git a/lib/puppet/indirector/node/rest.rb b/lib/puppet/indirector/node/rest.rb index 6ca87219646..311634ce790 100644 --- a/lib/puppet/indirector/node/rest.rb +++ b/lib/puppet/indirector/node/rest.rb @@ -4,7 +4,7 @@ require_relative '../../../puppet/indirector/rest' class Puppet::Node::Rest < Puppet::Indirector::REST - desc "Get a node via REST. Puppet agent uses this to allow the puppet master + desc "Get a node via REST. Puppet agent uses this to allow the Puppet server to override its environment." def find(request) diff --git a/lib/puppet/parser/functions/generate.rb b/lib/puppet/parser/functions/generate.rb index b52eb4a7f36..059341b0717 100644 --- a/lib/puppet/parser/functions/generate.rb +++ b/lib/puppet/parser/functions/generate.rb @@ -2,7 +2,7 @@ # Runs an external command and returns the results Puppet::Parser::Functions.newfunction(:generate, :arity => -2, :type => :rvalue, - :doc => "Calls an external command on the Puppet master and returns + :doc => "Calls an external command on the Puppet server and returns the results of the command. Any arguments are passed to the external command as arguments. If the generator does not exit with return code of 0, the generator is considered to have failed and a parse error is diff --git a/lib/puppet/reference/configuration.rb b/lib/puppet/reference/configuration.rb index 44058f82ce3..2c0dca4d31c 100644 --- a/lib/puppet/reference/configuration.rb +++ b/lib/puppet/reference/configuration.rb @@ -78,7 +78,7 @@ `--no-setting` instead of `--setting (true|false)`. (Using `--setting false` results in "Error: Could not parse application options: needless argument".) * Settings can be interpolated as `$variables` in other settings; `$environment` - is special, in that puppet master will interpolate each agent node's + is special, in that Puppet Server will interpolate each agent node's environment instead of its own. * Multiple values should be specified as comma-separated lists; multiple directories should be separated with the system path separator (usually diff --git a/lib/puppet/reference/function.rb b/lib/puppet/reference/function.rb index efc525d28a8..e03d47c3b4c 100644 --- a/lib/puppet/reference/function.rb +++ b/lib/puppet/reference/function.rb @@ -10,8 +10,8 @@ only be used in a statement requiring a value, such as an assignment or a case statement. -Functions execute on the Puppet master. They do not execute on the Puppet agent. -Hence they only have access to the commands and data available on the Puppet master +Functions execute on the Puppet server. They do not execute on the Puppet agent. +Hence they only have access to the commands and data available on the Puppet server host. Here are the functions available in Puppet: diff --git a/lib/puppet/reference/indirection.rb b/lib/puppet/reference/indirection.rb index f4b508a5134..0b8ebe13d0e 100644 --- a/lib/puppet/reference/indirection.rb +++ b/lib/puppet/reference/indirection.rb @@ -39,7 +39,7 @@ Puppet's indirector support pluggable backends (termini) for a variety of key-value stores (indirections). Each indirection type corresponds to a particular Ruby class (the "Indirected Class" below) and values are instances of that class. Each instance's key is available from its `name` method. - The termini can be local (e.g., on-disk files) or remote (e.g., using a REST interface to talk to a puppet master). + The termini can be local (e.g., on-disk files) or remote (e.g., using a REST interface to talk to a Puppet server). An indirector has five methods, which are mapped into HTTP verbs for the REST interface: diff --git a/lib/puppet/reference/report.rb b/lib/puppet/reference/report.rb index c678ab1a05b..9fae230769d 100644 --- a/lib/puppet/reference/report.rb +++ b/lib/puppet/reference/report.rb @@ -9,10 +9,10 @@ report.header = " Puppet can generate a report after applying a catalog. This report includes events, log messages, resource statuses, and metrics and metadata about the run. -Puppet agent sends its report to a Puppet master server, and Puppet apply +Puppet agent sends its report to a Puppet server, and Puppet apply processes its own reports. -Puppet master and Puppet apply will handle every report with a set of report +Puppet Server and Puppet apply will handle every report with a set of report processors, configurable with the `reports` setting in puppet.conf. This page documents the built-in report processors. diff --git a/lib/puppet/type/file/source.rb b/lib/puppet/type/file/source.rb index 133e45865a5..409bec324f9 100644 --- a/lib/puppet/type/file/source.rb +++ b/lib/puppet/type/file/source.rb @@ -31,7 +31,7 @@ module Puppet `puppet:///modules//` - This will fetch a file from a module on the Puppet master (or from a + This will fetch a file from a module on the Puppet server (or from a local module when using Puppet apply). Given a `modulepath` of `/etc/puppetlabs/code/modules`, the example above would resolve to `/etc/puppetlabs/code/modules//files/`. diff --git a/lib/puppet/util/profiler.rb b/lib/puppet/util/profiler.rb index 072844852d7..64803ccdcc9 100644 --- a/lib/puppet/util/profiler.rb +++ b/lib/puppet/util/profiler.rb @@ -40,7 +40,7 @@ def self.remove_profiler(profiler) # Profile a block of code and log the time it took to execute. # - # This outputs logs entries to the Puppet masters logging destination + # This outputs log entries to the Puppet server's logging destination # providing the time it took, a message describing the profiled code # and a leaf location marking where the profile method was called # in the profiled hierarchy. diff --git a/lib/puppet/util/profiler/around_profiler.rb b/lib/puppet/util/profiler/around_profiler.rb index b4c88d58d56..b3a3dabb9b0 100644 --- a/lib/puppet/util/profiler/around_profiler.rb +++ b/lib/puppet/util/profiler/around_profiler.rb @@ -39,7 +39,7 @@ def remove_profiler(profiler) # Profile a block of code and log the time it took to execute. # - # This outputs logs entries to the Puppet masters logging destination + # This outputs log entries to the Puppet server's logging destination # providing the time it took, a message describing the profiled code # and a leaf location marking where the profile method was called # in the profiled hierarchy. diff --git a/locales/puppet.pot b/locales/puppet.pot index 5898e0f200a..61327167147 100644 --- a/locales/puppet.pot +++ b/locales/puppet.pot @@ -1058,7 +1058,7 @@ msgid "[]" msgstr "" #: ../lib/puppet/face/facts.rb:41 -msgid "Upload local facts to the puppet master." +msgid "Upload local facts to the Puppet server." msgstr "" #: ../lib/puppet/face/facts.rb:79 @@ -1462,7 +1462,7 @@ msgid "Interact with the Puppet plugin system." msgstr "" #: ../lib/puppet/face/plugin.rb:22 -msgid "Download plugins from the puppet master." +msgid "Download plugins from the Puppet server." msgstr "" #: ../lib/puppet/face/plugin.rb:56 diff --git a/man/man5/puppet.conf.5 b/man/man5/puppet.conf.5 index cd6e58402b9..0f1d4605b75 100644 --- a/man/man5/puppet.conf.5 +++ b/man/man5/puppet.conf.5 @@ -15,7 +15,7 @@ Puppet Enterprise (PE) and open source Puppet share the configuration settings d When using boolean settings on the command line, use \fB\-\-setting\fR and \fB\-\-no\-setting\fR instead of \fB\-\-setting (true|false)\fR\. (Using \fB\-\-setting false\fR results in "Error: Could not parse application options: needless argument"\.) . .IP "\(bu" 4 -Settings can be interpolated as \fB$variables\fR in other settings; \fB$environment\fR is special, in that puppet master will interpolate each agent node\'s environment instead of its own\. +Settings can be interpolated as \fB$variables\fR in other settings; \fB$environment\fR is special, in that Puppet Server will interpolate each agent node\'s environment instead of its own\. . .IP "\(bu" 4 Multiple values should be specified as comma\-separated lists; multiple directories should be separated with the system path separator (usually a colon)\. diff --git a/man/man8/puppet-agent.8 b/man/man8/puppet-agent.8 index bc7b4871c4a..f61846e7daf 100644 --- a/man/man8/puppet-agent.8 +++ b/man/man8/puppet-agent.8 @@ -7,7 +7,7 @@ \fBpuppet\-agent\fR \- The puppet agent daemon . .SH "SYNOPSIS" -Retrieves the client configuration from the Puppet master and applies it to the local host\. +Retrieves the client configuration from the Puppet server and applies it to the local host\. . .P This service may be run as a daemon, run periodically using cron (or something similar), or run interactively for testing purposes\. @@ -190,7 +190,7 @@ Shut down the puppet agent daemon\. . .TP SIGUSR1 -Immediately retrieve and apply configurations from the puppet master\. +Immediately retrieve and apply configurations from the Puppet server\. . .TP SIGUSR2 diff --git a/man/man8/puppet-apply.8 b/man/man8/puppet-apply.8 index 43cab03e03c..4f7c60a9483 100644 --- a/man/man8/puppet-apply.8 +++ b/man/man8/puppet-apply.8 @@ -16,10 +16,10 @@ puppet apply [\-h|\-\-help] [\-V|\-\-version] [\-d|\-\-debug] [\-v|\-\-verbose] This is the standalone puppet execution tool; use it to apply individual manifests\. . .P -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\. +When provided with a modulepath, via command line or config file, puppet apply can effectively mimic the catalog that would be served by Puppet Server 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\. . .P -Most users should use \'puppet agent\' and \'puppet master\' for site\-wide manifests\. +Most users should use \'puppet agent\' and \'puppet server\' for site\-wide manifests\. . .SH "OPTIONS" Any setting that\'s valid in the configuration file is a valid long argument for puppet apply\. For example, \'tags\' is a valid setting, so you can specify \'\-\-tags \fIclass\fR,\fItag\fR\' as an argument\. @@ -76,7 +76,7 @@ A path ending with \'\.jsonl\' will receive structured output in JSON Lines form \-\-verbose: Print extra information\. . .IP "\(bu" 4 -\-\-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\. +\-\-catalog: Apply a JSON catalog (such as one generated with \'puppet catalog compile\')\. You can either specify a JSON file or pipe in JSON from standard input\. . .IP "\(bu" 4 \-\-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 diff --git a/man/man8/puppet-catalog.8 b/man/man8/puppet-catalog.8 index 8c82202c4ba..bbce36980a4 100644 --- a/man/man8/puppet-catalog.8 +++ b/man/man8/puppet-catalog.8 @@ -35,7 +35,7 @@ Whether to log debug information\. Indirector faces expose indirected subsystems of Puppet\. These subsystems are each able to retrieve and alter a specific type of data (with the familiar actions of \fBfind\fR, \fBsearch\fR, \fBsave\fR, and \fBdestroy\fR) from an arbitrary number of pluggable backends\. In Puppet parlance, these backends are called terminuses\. . .IP -Almost all indirected subsystems have a \fBrest\fR terminus that interacts with the puppet master\'s data\. Most of them have additional terminuses for various local data models, which are in turn used by the indirected subsystem on the puppet master whenever it receives a remote request\. +Almost all indirected subsystems have a \fBrest\fR terminus that interacts with the Puppet server\'s data\. Most of them have additional terminuses for various local data models, which are in turn used by the indirected subsystem on the Puppet server whenever it receives a remote request\. . .IP The terminus for an action is often determined by context, but occasionally needs to be set explicitly\. See the "Notes" section of this face\'s manpage for more details\. @@ -81,7 +81,7 @@ Compiles a catalog locally for a node, requiring access to modules, node classif A serialized catalog\. . .TP -\fBdownload\fR \- Download this node\'s catalog from the puppet master server\. +\fBdownload\fR \- Download this node\'s catalog from the Puppet server server\. \fBSYNOPSIS\fR . .IP @@ -91,7 +91,7 @@ puppet catalog download [\-\-terminus _TERMINUS] \fBDESCRIPTION\fR . .IP -Retrieves a catalog from the puppet master and saves it to the local yaml cache\. This action always contacts the puppet master and will ignore alternate termini\. +Retrieves a catalog from the Puppet server and saves it to the local yaml cache\. This action always contacts the Puppet server and will ignore alternate termini\. . .IP The saved catalog can be used in any subsequent catalog action by specifying \'\-\-terminus yaml\' for that action\. @@ -179,7 +179,7 @@ A list of resource references ("Type[title]")\. When used from the API, returns \fBNOTES\fR . .IP -By default, this action will retrieve a catalog from Puppet\'s compiler subsystem; you must call the action with \fB\-\-terminus rest\fR if you wish to retrieve a catalog from the puppet master\. +By default, this action will retrieve a catalog from Puppet\'s compiler subsystem; you must call the action with \fB\-\-terminus rest\fR if you wish to retrieve a catalog from the Puppet server\. . .IP FORMATTING ISSUES: This action cannot currently render useful yaml; instead, it returns an entire catalog\. Use json instead\. @@ -194,7 +194,7 @@ Apply the locally cached catalog: $ puppet catalog apply \-\-terminus yaml . .P -Retrieve a catalog from the master and apply it, in one step: +Retrieve a catalog from the server and apply it, in one step: . .P $ puppet catalog apply \-\-terminus rest @@ -255,7 +255,7 @@ Puppet::Face[:catalog, \'0\.0\.1\']\.download \fBselect\fR . .P -Ask the puppet master for a list of managed file resources for a node: +Ask the Puppet server for a list of managed file resources for a node: . .P $ puppet catalog select \-\-terminus rest somenode\.magpie\.lan file diff --git a/man/man8/puppet-device.8 b/man/man8/puppet-device.8 index 5a8daebb95d..951eed55288 100644 --- a/man/man8/puppet-device.8 +++ b/man/man8/puppet-device.8 @@ -7,7 +7,7 @@ \fBpuppet\-device\fR \- Manage remote network devices . .SH "SYNOPSIS" -Retrieves catalogs from the Puppet master and applies them to remote devices\. +Retrieves catalogs from the Puppet server and applies them to remote devices\. . .P This subcommand can be run manually; or periodically using cron, a scheduled task, or a similar tool\. diff --git a/man/man8/puppet-facts.8 b/man/man8/puppet-facts.8 index cd2f87ba73a..727616628fc 100644 --- a/man/man8/puppet-facts.8 +++ b/man/man8/puppet-facts.8 @@ -35,7 +35,7 @@ Whether to log debug information\. Indirector faces expose indirected subsystems of Puppet\. These subsystems are each able to retrieve and alter a specific type of data (with the familiar actions of \fBfind\fR, \fBsearch\fR, \fBsave\fR, and \fBdestroy\fR) from an arbitrary number of pluggable backends\. In Puppet parlance, these backends are called terminuses\. . .IP -Almost all indirected subsystems have a \fBrest\fR terminus that interacts with the puppet master\'s data\. Most of them have additional terminuses for various local data models, which are in turn used by the indirected subsystem on the puppet master whenever it receives a remote request\. +Almost all indirected subsystems have a \fBrest\fR terminus that interacts with the Puppet server\'s data\. Most of them have additional terminuses for various local data models, which are in turn used by the indirected subsystem on the Puppet server whenever it receives a remote request\. . .IP The terminus for an action is often determined by context, but occasionally needs to be set explicitly\. See the "Notes" section of this face\'s manpage for more details\. @@ -143,7 +143,7 @@ The output of facter with added puppet specific facts\. \fBNOTES\fR . .TP -\fBupload\fR \- Upload local facts to the puppet master\. +\fBupload\fR \- Upload local facts to the Puppet server\. \fBSYNOPSIS\fR . .IP diff --git a/man/man8/puppet-node.8 b/man/man8/puppet-node.8 index f334c2ed921..3eedeee8215 100644 --- a/man/man8/puppet-node.8 +++ b/man/man8/puppet-node.8 @@ -35,7 +35,7 @@ Whether to log debug information\. Indirector faces expose indirected subsystems of Puppet\. These subsystems are each able to retrieve and alter a specific type of data (with the familiar actions of \fBfind\fR, \fBsearch\fR, \fBsave\fR, and \fBdestroy\fR) from an arbitrary number of pluggable backends\. In Puppet parlance, these backends are called terminuses\. . .IP -Almost all indirected subsystems have a \fBrest\fR terminus that interacts with the puppet master\'s data\. Most of them have additional terminuses for various local data models, which are in turn used by the indirected subsystem on the puppet master whenever it receives a remote request\. +Almost all indirected subsystems have a \fBrest\fR terminus that interacts with the Puppet server\'s data\. Most of them have additional terminuses for various local data models, which are in turn used by the indirected subsystem on the Puppet server whenever it receives a remote request\. . .IP The terminus for an action is often determined by context, but occasionally needs to be set explicitly\. See the "Notes" section of this face\'s manpage for more details\. @@ -43,7 +43,7 @@ The terminus for an action is often determined by context, but occasionally need .SH "ACTIONS" . .TP -\fBclean\fR \- Clean up signed certs, cached facts, node objects, and reports for a node stored by the puppetmaster +\fBclean\fR \- Clean up signed certs, cached facts, node objects, and reports for a node stored by the Puppet server \fBSYNOPSIS\fR . .IP @@ -53,7 +53,7 @@ puppet node clean [\-\-terminus _TERMINUS] \fIhost1\fR [\fIhost2\fR \.\.\.] \fBDESCRIPTION\fR . .IP -Cleans up the following information a puppet master knows about a node: +Cleans up the following information a Puppet server knows about a node: . .IP \fISigned certificates\fR \- ($vardir/ssl/ca/signed/node\.domain\.pem) diff --git a/man/man8/puppet-plugin.8 b/man/man8/puppet-plugin.8 index b079e41edec..9c344618dc8 100644 --- a/man/man8/puppet-plugin.8 +++ b/man/man8/puppet-plugin.8 @@ -10,10 +10,10 @@ puppet plugin \fIaction\fR . .SH "DESCRIPTION" -This subcommand provides network access to the puppet master\'s store of plugins\. +This subcommand provides network access to the Puppet server\'s store of plugins\. . .P -The puppet master serves Ruby code collected from the \fBlib\fR directories of its modules\. These plugins can be used on agent nodes to extend Facter and implement custom types and providers\. Plugins are normally downloaded by puppet agent during the course of a run\. +The Puppet server serves Ruby code collected from the \fBlib\fR directories of its modules\. These plugins can be used on agent nodes to extend Facter and implement custom types and providers\. Plugins are normally downloaded by puppet agent during the course of a run\. . .SH "OPTIONS" Note that any setting that\'s valid in the configuration file is also a valid long argument, although it may or may not be relevant to the present action\. For example, \fBserver\fR and \fBrun_mode\fR are valid settings, so you can specify \fB\-\-server \fR, or \fB\-\-run_mode \fR as an argument\. @@ -36,7 +36,7 @@ Whether to log debug information\. .SH "ACTIONS" . .TP -\fBdownload\fR \- Download plugins from the puppet master\. +\fBdownload\fR \- Download plugins from the Puppet server\. \fBSYNOPSIS\fR . .IP @@ -46,7 +46,7 @@ puppet plugin download \fBDESCRIPTION\fR . .IP -Downloads plugins from the configured puppet master\. Any plugins downloaded in this way will be used in all subsequent Puppet activity\. This action modifies files on disk\. +Downloads plugins from the configured Puppet server\. Any plugins downloaded in this way will be used in all subsequent Puppet activity\. This action modifies files on disk\. . .IP \fBRETURNS\fR @@ -58,13 +58,13 @@ A list of the files downloaded, or a confirmation that no files were downloaded\ \fBdownload\fR . .P -Retrieve plugins from the puppet master: +Retrieve plugins from the Puppet server: . .P $ puppet plugin download . .P -Retrieve plugins from the puppet master (API example): +Retrieve plugins from the Puppet server (API example): . .P $ Puppet::Face[:plugin, \'0\.0\.1\']\.download diff --git a/man/man8/puppet-report.8 b/man/man8/puppet-report.8 index ea3f7aed77e..66a805af860 100644 --- a/man/man8/puppet-report.8 +++ b/man/man8/puppet-report.8 @@ -32,7 +32,7 @@ Whether to log debug information\. Indirector faces expose indirected subsystems of Puppet\. These subsystems are each able to retrieve and alter a specific type of data (with the familiar actions of \fBfind\fR, \fBsearch\fR, \fBsave\fR, and \fBdestroy\fR) from an arbitrary number of pluggable backends\. In Puppet parlance, these backends are called terminuses\. . .IP -Almost all indirected subsystems have a \fBrest\fR terminus that interacts with the puppet master\'s data\. Most of them have additional terminuses for various local data models, which are in turn used by the indirected subsystem on the puppet master whenever it receives a remote request\. +Almost all indirected subsystems have a \fBrest\fR terminus that interacts with the Puppet server\'s data\. Most of them have additional terminuses for various local data models, which are in turn used by the indirected subsystem on the Puppet server whenever it receives a remote request\. . .IP The terminus for an action is often determined by context, but occasionally needs to be set explicitly\. See the "Notes" section of this face\'s manpage for more details\. @@ -82,7 +82,7 @@ puppet report submit [\-\-terminus _TERMINUS] \fIreport\fR \fBDESCRIPTION\fR . .IP -API only: Submits a report to the puppet master\. This action is essentially a shortcut and wrapper for the \fBsave\fR action with the \fBrest\fR terminus, and provides additional details in the event of a failure\. +API only: Submits a report to the Puppet server\. This action is essentially a shortcut and wrapper for the \fBsave\fR action with the \fBrest\fR terminus, and provides additional details in the event of a failure\. . .SH "EXAMPLES" \fBsave\fR diff --git a/references/configuration.md b/references/configuration.md index 10619c172f3..568b5f917cf 100644 --- a/references/configuration.md +++ b/references/configuration.md @@ -27,7 +27,7 @@ canonical: "/puppet/latest/configuration.html" `--no-setting` instead of `--setting (true|false)`. (Using `--setting false` results in "Error: Could not parse application options: needless argument".) * Settings can be interpolated as `$variables` in other settings; `$environment` - is special, in that puppet master will interpolate each agent node's + is special, in that Puppet Server will interpolate each agent node's environment instead of its own. * Multiple values should be specified as comma-separated lists; multiple directories should be separated with the system path separator (usually diff --git a/references/function.md b/references/function.md index 3eba6a80e47..2a19fec6de5 100644 --- a/references/function.md +++ b/references/function.md @@ -1528,7 +1528,7 @@ node. (For example, `fqdn_rand(30)`, `fqdn_rand(30, 'expensive job 1')`, and ## `generate` -Calls an external command on the Puppet master and returns +Calls an external command on the Puppet server and returns the results of the command. Any arguments are passed to the external command as arguments. If the generator does not exit with return code of 0, the generator is considered to have failed and a parse error is diff --git a/references/man/agent.md b/references/man/agent.md index ae96ba531b2..ef0db9e8730 100644 --- a/references/man/agent.md +++ b/references/man/agent.md @@ -13,7 +13,7 @@ canonical: "/puppet/latest/man/agent.html" **puppet-agent** - The puppet agent daemon ## SYNOPSIS -Retrieves the client configuration from the Puppet master and applies it +Retrieves the client configuration from the Puppet server and applies it to the local host. This service may be run as a daemon, run periodically using cron (or @@ -85,7 +85,7 @@ runs once and displays on the console (and in the log) the current certificate (or certificate request) fingerprint. Providing the \'\--digest\' option allows you to use a different digest algorithm to generate the fingerprint. The main use is to verify that before signing -a certificate request on the master, the certificate request the master +a certificate request on the server, the certificate request the server received is the same as the one the client sent (to prevent against man-in-the-middle attacks when signing certificates). @@ -106,7 +106,7 @@ https://puppet.com/docs/puppet/latest/configuration.html for the full list of acceptable settings. A commented list of all settings can also be generated by running puppet agent with \'\--genconfig\'. -- \--certname: Set the certname (unique ID) of the client. The master +- \--certname: Set the certname (unique ID) of the client. The server reads this unique identifying string, which is usually set to the node\'s fully-qualified domain name, to determine which configurations the node will receive. Use this option to debug setup @@ -266,8 +266,8 @@ SIGINT and SIGTERM SIGUSR1 -: Immediately retrieve and apply configurations from the puppet - master. +: Immediately retrieve and apply configurations from the Puppet + server. SIGUSR2 diff --git a/references/man/apply.md b/references/man/apply.md index f7d3e60b8e3..77612f3d4e5 100644 --- a/references/man/apply.md +++ b/references/man/apply.md @@ -27,13 +27,13 @@ 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 +apply can effectively mimic the catalog that would be served by Puppet +Server 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 +Most users should use \'puppet agent\' and \'puppet server\' for site-wide manifests. ## OPTIONS @@ -96,7 +96,7 @@ configuration options by running puppet with \'\--genconfig\'. - \--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 + \'puppet catalog compile\'). You can either specify a JSON file or pipe in JSON from standard input. - \--write-catalog-summary After compiling the catalog saves the diff --git a/references/man/catalog.md b/references/man/catalog.md index fbaa4a0da30..4bedf245610 100644 --- a/references/man/catalog.md +++ b/references/man/catalog.md @@ -59,9 +59,9 @@ options can also be generated by running puppet with **\--genconfig**. Puppet parlance, these backends are called terminuses. Almost all indirected subsystems have a **rest** terminus that - interacts with the puppet master\'s data. Most of them have + interacts with the Puppet server\'s data. Most of them have additional terminuses for various local data models, which are in - turn used by the indirected subsystem on the puppet master whenever + turn used by the indirected subsystem on the Puppet server whenever it receives a remote request. The terminus for an action is often determined by context, but @@ -101,7 +101,7 @@ options can also be generated by running puppet with **\--genconfig**. A serialized catalog. -**download** - Download this node\'s catalog from the puppet master server. +**download** - Download this node\'s catalog from the Puppet server server. : **SYNOPSIS** @@ -109,8 +109,8 @@ options can also be generated by running puppet with **\--genconfig**. **DESCRIPTION** - Retrieves a catalog from the puppet master and saves it to the local - yaml cache. This action always contacts the puppet master and will + Retrieves a catalog from the Puppet server and saves it to the local + yaml cache. This action always contacts the Puppet server and will ignore alternate termini. The saved catalog can be used in any subsequent catalog action by @@ -192,7 +192,7 @@ options can also be generated by running puppet with **\--genconfig**. By default, this action will retrieve a catalog from Puppet\'s compiler subsystem; you must call the action with **\--terminus - rest** if you wish to retrieve a catalog from the puppet master. + rest** if you wish to retrieve a catalog from the Puppet server. FORMATTING ISSUES: This action cannot currently render useful yaml; instead, it returns an entire catalog. Use json instead. @@ -204,7 +204,7 @@ Apply the locally cached catalog: \$ puppet catalog apply \--terminus yaml -Retrieve a catalog from the master and apply it, in one step: +Retrieve a catalog from the server and apply it, in one step: \$ puppet catalog apply \--terminus rest @@ -237,7 +237,7 @@ API example: ## ... **select** -Ask the puppet master for a list of managed file resources for a node: +Ask the Puppet server for a list of managed file resources for a node: \$ puppet catalog select \--terminus rest somenode.magpie.lan file diff --git a/references/man/device.md b/references/man/device.md index 125ded8bed5..24b98acc540 100644 --- a/references/man/device.md +++ b/references/man/device.md @@ -13,7 +13,7 @@ canonical: "/puppet/latest/man/device.html" **puppet-device** - Manage remote network devices ## SYNOPSIS -Retrieves catalogs from the Puppet master and applies them to remote +Retrieves catalogs from the Puppet server and applies them to remote devices. This subcommand can be run manually; or periodically using cron, a diff --git a/references/man/facts.md b/references/man/facts.md index 489771cb915..3eeca7f8204 100644 --- a/references/man/facts.md +++ b/references/man/facts.md @@ -55,9 +55,9 @@ options can also be generated by running puppet with **\--genconfig**. Puppet parlance, these backends are called terminuses. Almost all indirected subsystems have a **rest** terminus that - interacts with the puppet master\'s data. Most of them have + interacts with the Puppet server\'s data. Most of them have additional terminuses for various local data models, which are in - turn used by the indirected subsystem on the puppet master whenever + turn used by the indirected subsystem on the Puppet server whenever it receives a remote request. The terminus for an action is often determined by context, but @@ -152,7 +152,7 @@ options can also be generated by running puppet with **\--genconfig**. **NOTES** -**upload** - Upload local facts to the puppet master. +**upload** - Upload local facts to the Puppet server. : **SYNOPSIS** diff --git a/references/man/node.md b/references/man/node.md index 0b59a82b7a0..91ee083ba51 100644 --- a/references/man/node.md +++ b/references/man/node.md @@ -56,9 +56,9 @@ options can also be generated by running puppet with **\--genconfig**. Puppet parlance, these backends are called terminuses. Almost all indirected subsystems have a **rest** terminus that - interacts with the puppet master\'s data. Most of them have + interacts with the Puppet server\'s data. Most of them have additional terminuses for various local data models, which are in - turn used by the indirected subsystem on the puppet master whenever + turn used by the indirected subsystem on the Puppet server whenever it receives a remote request. The terminus for an action is often determined by context, but @@ -75,7 +75,7 @@ options can also be generated by running puppet with **\--genconfig**. **DESCRIPTION** - Cleans up the following information a puppet master knows about a + Cleans up the following information a Puppet server knows about a node: *Signed certificates* - (\$vardir/ssl/ca/signed/node.domain.pem) diff --git a/references/man/plugin.md b/references/man/plugin.md index bd540be242e..8a4b8e02baf 100644 --- a/references/man/plugin.md +++ b/references/man/plugin.md @@ -16,10 +16,10 @@ canonical: "/puppet/latest/man/plugin.html" puppet plugin *action* ## DESCRIPTION -This subcommand provides network access to the puppet master\'s store of +This subcommand provides network access to the Puppet server\'s store of plugins. -The puppet master serves Ruby code collected from the **lib** +The Puppet server serves Ruby code collected from the **lib** directories of its modules. These plugins can be used on agent nodes to extend Facter and implement custom types and providers. Plugins are normally downloaded by puppet agent during the course of a run. @@ -51,7 +51,7 @@ options can also be generated by running puppet with **\--genconfig**. : Whether to log debug information. ## ACTIONS -**download** - Download plugins from the puppet master. +**download** - Download plugins from the Puppet server. : **SYNOPSIS** @@ -59,7 +59,7 @@ options can also be generated by running puppet with **\--genconfig**. **DESCRIPTION** - Downloads plugins from the configured puppet master. Any plugins + Downloads plugins from the configured Puppet server. Any plugins downloaded in this way will be used in all subsequent Puppet activity. This action modifies files on disk. @@ -73,11 +73,11 @@ options can also be generated by running puppet with **\--genconfig**. ## EXAMPLES **download** -Retrieve plugins from the puppet master: +Retrieve plugins from the Puppet server: \$ puppet plugin download -Retrieve plugins from the puppet master (API example): +Retrieve plugins from the Puppet server (API example): \$ Puppet::Face\[:plugin, \'0.0.1\'\].download diff --git a/references/man/report.md b/references/man/report.md index bc4c39399b6..19c4cd97af7 100644 --- a/references/man/report.md +++ b/references/man/report.md @@ -50,9 +50,9 @@ options can also be generated by running puppet with **\--genconfig**. Puppet parlance, these backends are called terminuses. Almost all indirected subsystems have a **rest** terminus that - interacts with the puppet master\'s data. Most of them have + interacts with the Puppet server\'s data. Most of them have additional terminuses for various local data models, which are in - turn used by the indirected subsystem on the puppet master whenever + turn used by the indirected subsystem on the Puppet server whenever it receives a remote request. The terminus for an action is often determined by context, but @@ -96,7 +96,7 @@ options can also be generated by running puppet with **\--genconfig**. **DESCRIPTION** - API only: Submits a report to the puppet master. This action is + API only: Submits a report to the Puppet server. This action is essentially a shortcut and wrapper for the **save** action with the **rest** terminus, and provides additional details in the event of a failure. diff --git a/references/report.md b/references/report.md index c859779ba90..d6b65e9a59e 100644 --- a/references/report.md +++ b/references/report.md @@ -15,10 +15,10 @@ canonical: "/puppet/latest/report.html" Puppet can generate a report after applying a catalog. This report includes events, log messages, resource statuses, and metrics and metadata about the run. -Puppet agent sends its report to a Puppet master server, and Puppet apply +Puppet agent sends its report to a Puppet server, and Puppet apply processes its own reports. -Puppet master and Puppet apply will handle every report with a set of report +Puppet Server and Puppet apply will handle every report with a set of report processors, configurable with the `reports` setting in puppet.conf. This page documents the built-in report processors. diff --git a/references/type.md b/references/type.md index 4cdb9725ee0..9cd292bc7b7 100644 --- a/references/type.md +++ b/references/type.md @@ -1270,7 +1270,7 @@ The normal form of a `puppet:` URI is: `puppet:///modules//` -This will fetch a file from a module on the Puppet master (or from a +This will fetch a file from a module on the Puppet server (or from a local module when using Puppet apply). Given a `modulepath` of `/etc/puppetlabs/code/modules`, the example above would resolve to `/etc/puppetlabs/code/modules//files/`. diff --git a/references/types/file.md b/references/types/file.md index 7870c9ba044..0beee93d118 100644 --- a/references/types/file.md +++ b/references/types/file.md @@ -714,7 +714,7 @@ The normal form of a `puppet:` URI is: `puppet:///modules//` -This will fetch a file from a module on the Puppet master (or from a +This will fetch a file from a module on the Puppet server (or from a local module when using Puppet apply). Given a `modulepath` of `/etc/puppetlabs/code/modules`, the example above would resolve to `/etc/puppetlabs/code/modules//files/`.