Adding file server mount points
Included in Puppet Enterprise 3.8. A newer version is available; see the version menu above for details.
Puppet Server includes a file server for transferring static file content to agents; this is what’s used whenever a
file resource has a
source => puppet:///... attribute specified.
Generally, files are stored in modules. But if you need to serve larger files that shouldn’t be in source control or shouldn’t be distributed with a module, you can make a custom file server mount point and let Puppet serve those files from another directory.
To create a new mount point, you must:
- Choose a directory on disk for the mount point. Make sure Puppet Server can access it, and put files in it as needed.
fileserver.confon your Puppet Server node, so Puppet knows which directory to associate with the new mount point.
- If you want to restrict which nodes can access this mount point, edit
Once the mount point is working, you can reference its files like
What’s a mount point, in a Puppet URI?
Puppet URIs are constructed like this:
<SERVER>is optional, which is why you usually see
puppet:///URIs with three slashes. There’s little reason to specify a server, since the default is almost always what you want. (It’s the value of the
serversetting in Puppet agent, and a special mock server with a
modulesmount point in Puppet apply.)
<MOUNT POINT>is a unique identifier for some collection of files. There are basically three kinds:
- Custom mount points correspond to an arbitrary directory. The rest of this page is about these.
- The special
modulesmount point serves files from the
filesdirectory of every module. It behaves as if someone had copied the
filesdirectory from every module into one big directory, renaming each of them with the name of their module. (So the files in
apache/files/...are available at
- The special
pluginsmount point serves files from the
libdirectory of every module. It behaves as if someone had copied the contents of every
libdirectory 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 a
<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 uses an INI-like syntax. The
fileserver.conf page has a complete description, but all you need to know is:
[<NAME OF MOUNT POINT>] path <PATH TO DIRECTORY> allow * [installer_files] path /etc/puppetlabs/puppet/installer_files allow *
In the example above, a file at
/etc/puppetlabs/puppet/installer_files/oracle.pkg would be available in manifests as
Make sure that the
puppet user can access that directory and its contents.
Always include the
allow * line, since the default behavior is to deny all access. If you need to control access to a custom mount point, do so in
auth.conf. Putting authorization rules in
fileserver.conf is deprecated. (This deprecation targets Puppet 5.0; authorization rules in
fileserver.conf still work in Puppet 4.x.)
Controlling access to a custom mount point in
By default, any node with a valid certificate can access the files in your new mount point — if it can fetch a catalog, it can fetch files; if it can’t, it can’t. This is the same behavior as the special
plugins mount points.
If necessary, you can restrict access to a custom mount point in
You’ll be adding a stanza to
Your new auth rule must meet the following requirements:
- It matches requests to all four of these prefixes:
- It is located earlier in the
auth.conffile than the default
# Allow limited access to files in /etc/puppetlabs/puppet/installer_files: path ~ ^/file_(metadata|content)s?/installer_files/ auth yes allow *.dev.example.com allow_ip 192.168.100.0/24