DevOps Zone is brought to you in partnership with:

Jakub is a Java EE developer since 2005 and occasionally a project manager, working currently with Iterate AS. He's highly interested in developer productivity (and tools like Maven and AOP/AspectJ), web frameworks, Java portals, testing and performance and works a lot with IBM technologies. A native to Czech Republic, he lives now in Oslo, Norway. Jakub is a DZone MVB and is not an employee of DZone and has posted 154 posts at DZone. You can read more from them at their website. View Full User Profile

Serving Files with Puppet Standalone in Vagrant From the puppet:// URIs

  • submit to reddit

If you use Puppet in the client-server mode to configure your production environment then you might want to be able to copy & paste from the prod configuration into the Vagrant’s standalone puppet‘s configuration to test stuff. One of the key features necessary for that is enabling file serving via “source => ‘puppet:///path/to/file’”. In the client-server mode the files are served by the server, in the standalone mode you can configure puppet to read from a local (likely shared) folder. We will see how to do this.

Credits: This post is based heavily on Akumria’s answer at StackOverflow: how to source a file in puppet manifest from module.

Enabling Puppet Standalone in Vagrant to Resolve puppet:///…

Quick overview:

  1. Make the directory with the files to be served available to the Vagrant VM
  2. Create fileserver.conf to inform Puppet about the directory
  3. Tell puppet about the fileserver.conf
  4. Use it

1. Make the directory with the files to be served available to the Vagrant VM

For example as a shared folder:

# Snippet of <vagrant directory>/Vagrantfile
config.vm.share_folder "PuppetFiles", "/etc/puppet/files", "./puppet-files-symlink"

(In my case this is actually a symlink to the actual folder in our puppet git repository. Beware that symlinks inside shared folders often don’t work and thus it’s better to use the symlink as a standalone shared folder root.)

Notice you don’t need to declare a shared folder

2. Create fileserver.conf to inform Puppet about the directory

You need to tell to Puppet that the source”puppet:///files/” should be served from /etc/puppet/files/:

# <vagrant directory>/fileserver.conf
  path /etc/puppet/files
  allow *

3. Tell puppet about the fileserver.conf

Puppet needs to know that it should read the fileserver.conf file:

# Snippet of <vagrant directory>/Vagrantfile
config.vm.provision :puppet,
  :options => ["--fileserverconfig=/vagrant/fileserver.conf"],
  :facter => { "fqdn" => "" } do |puppet|

4. Use it

vagrant_dir$ echo "dummy content" > ./puppet-files-symlink/example-file.txt
# Snippet of <vagrant directory>/manifests/<my manifest>.pp
  ensure => file,
  source => 'puppet:///files/example-file.txt',


URLs with server name (puppet://puppet/) don’t work

URLs like puppet://puppet/files/path/to/file don’t work, you must use puppet:///files/path/to/file instead (empty, i.e. implicit, server name => three slashes).

The reason is, I believe, that if you state the server name explicitely then Puppet will try to find the server and get the files from there (that might be a desirable behavior if you run Puppet Master locally or elsewhere; in that case just add the server name to /etc/hosts in the Vagrant VM or make sure the DNS server used can resolve it). On the other hand, if you leave the server name out and rely on the implicit value then Puppet in the standalone mode will consult its fileserver.conf and behave accordingly. (Notice that in the server-client mode the implicit server name equals the puppet master, i.e. puppet:/// works perfectly well there.)

If you use puppet://puppet/files/... then you’ll get an error like this:

err: /Stage[main]/My_example_class/File[]: Could not evaluate: 
getaddrinfo: Name or service not known Could not retrieve file metadata for puppet://puppet/files/analytics/ 
getaddrinfo: Name or service not known at /tmp/vagrant-puppet/manifests/analytics_dev.pp:283


Puppet: 2.7.14, Vagrant:1.0.2








Published at DZone with permission of Jakub Holý, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)