Adding file server mount points
Puppet Server includes a file server for transferring static file content to agents. If you need to serve large files that you don't want to store in source control or distribute with a module, you can make a custom file server mount point and let Puppet serve those files from another directory.
In Puppet code, you can tell the file server is being used when you see
a file resource that has
a source =>
puppet:///... attribute specified.
To set up a mount point:
Choose a directory on disk for the mount point, make sure Puppet Server can access it, and add your files to the directory.
Edit
fileserver.confon your Puppet Server node, so Puppet knows which directory to associate with the new mount point.(Optional) Edit Puppet Server's
auth.confto allow access to the new mount point.
puppet:///<MOUNT POINT>/<PATH>.
On this page:
Mount points in the Puppet URI
Puppet URIs look like this: puppet://<SERVER>/<MOUNT
POINT>/<PATH>.
The <SERVER> is optional, so it common practice to use
puppet:/// URIs with three slashes. Usually, there is no reason to
specify the server. For Puppet agent,
<SERVER> defaults to the value of the server setting. For Puppet apply, <SERVER> defaults to
a special mock server with a modules mount point.
<MOUNT POINT> is a unique identifier for some collection of
files. There are different kinds of mount points:
Custom mount points correspond to a directory that you specify.
The
taskmount point works in a similar way to themodulesmount point but for files that live under the modulestasksdirectory, rather than thefilesdirectory.The special
modulesmount point serves files from thefilesdirectory of every module. It behaves as if someone had copied thefilesdirectory from every module into one big directory, renaming each of them with the name of their module. For example, the files inapache/files/...are available atpuppet:///modules/apache/....The special
pluginsmount point serves files from thelibdirectory of every module. It behaves as if someone had copied the contents of everylibdirectory into one big directory, with no additional namespacing. Puppet agent uses this mount point when syncing plugins before a run, but there’s no reason to use it in afileresource.The special
pluginfactsmount point serves files from thefacts.ddirectory of every module to support external facts. It behaves like thepluginsmount point, but with a different source directory.The special
localesmount point serves files from thelocalesdirectory of every module to support automatic downloading of module translations to agents. It also behaves like thepluginsmount point, and also has a different source directory.
<PATH> is the remainder of the path to the file, starting from
the directory (or imaginary directory) that corresponds to the mount point.
Creating a new mount point in fileserver.conf
The fileserver.conf file uses the following syntax to define mount
points:
[<NAME OF MOUNT POINT>]
path <PATH TO DIRECTORY>
In the following example, a file at
/etc/puppetlabs/puppet/installer_files/oracle.pkg would be available
in manifests as
puppet:///installer_files/oracle.pkg:
[installer_files]
path /etc/puppetlabs/puppet/installer_files
Make sure that the puppet user has the right permissions to access that
directory and its contents.
Controlling access to a custom mount point in auth.conf
By default, any node with a valid certificate can access the files in your new mount
point. If a node can fetch a catalog, it can fetch files. If the node can’t fetch a
catalog, it can’t fetch files. This is the same behavior as the special
modules and plugins mount points. If necessary, you
can restrict access to a custom mount point in auth.conf.
To add a new auth rule to Puppet Server’s HOCON-format
auth.conf file, located at
/etc/puppetlabs/puppetserver/conf.d/auth.conf. , you must meet the
following requirements:
It must match requests to all four of these prefixes:
/puppet/v3/file_metadata/<MOUNT POINT>/puppet/v3/file_metadatas/<MOUNT POINT>/puppet/v3/file_content/<MOUNT POINT>/puppet/v3/file_contents/<MOUNT POINT>
Its
sort-ordermust be lower than 500, so that it overrides the default rule for the file server.
For example:
{
# Allow limited access to files in /etc/puppetlabs/puppet/installer_files:
match-request: {
path: "^/puppet/v3/file_(content|metadata)s?/installer_files"
type: regex
}
allow: "*.dev.example.com"
sort-order: 400
name: "dev.example.com large installer files"
},
Related topics: Module fundamentals, fileserver.conf: Custom fileserver mount points, puppetserver.conf, auth.conf.