puppetlabs · samtuckerdavis · Feb 25, 2026
@@ -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

@@ -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

@@ -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

@@ -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
 

@@ -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`.
 

@@ -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
 

@@ -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
 

@@ -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
 

@@ -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

@@ -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.
 

@@ -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

@@ -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.

@@ -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

@@ -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

@@ -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.

@@ -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 _("<host1> [<host2> ...]")
     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:
 
       <Signed certificates> - ($vardir/ssl/ca/signed/node.domain.pem)
 

@@ -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

@@ -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

@@ -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

@@ -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)

@@ -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

@@ -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

@@ -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:

@@ -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:
 

@@ -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.