Note: This document covers open source releases of Puppet version 3.8 and lower. For current versions, you should see instructions for installing the latest version of Puppet or installing Puppet Enterprise.
Before installing Puppet, review the pre-install tasks.
Puppet builds packages for OS X, but we don’t run automated testing on them.
Puppet publishes and tests open-source Puppet 3.8 agent installers for the following versions of OS X to downloads.puppetlabs.com/mac:
The Puppet master service is not available on any version of OS X.
We recommend using Puppet on the newest version of OS X available, because we might not address bugs related to older versions. Our Puppet 3.8 packages are intended for OS X 10.9 (Mavericks) and later, and newer versions of Puppet are built and tested against newer versions of OS X.
To install on other operating systems, see the product navigation.
Download Puppet’s OS X installers from downloads.puppetlabs.com/mac. You need these three packages:
The list of OS X packages includes release candidates, whose filenames have something like
-rc1 after the version number. Only use these if you want to test upcoming Puppet versions.
Mount the Facter disk image, and run the installer package it contains.
Mount the Hiera disk image, and run the installer package it contains.
Mount the Puppet disk image, and run the installer package it contains.
Although OS X systems can act as puppet master servers, we don’t ship separate packages for that. This is mostly because the OS X package is very minimal compared to the Linux packages, and it doesn’t include the relevant init scripts.
Note: Be sure to read our tips on upgrading before upgrading your whole Puppet deployment.
To upgrade to the latest versions of Puppet, Facter, and Hiera, download new packages and run the installers again.
You’ll need to restart the
com.puppetlabs.puppet service and/or the puppet master web server after upgrading. To restart a launchd service, run something like
sudo launchctl stop com.puppetlabs.puppet; the service will be restarted as soon as it stops.
The OS X packages don’t have some of the conveniences that the Linux and Windows packages have. To prepare for the post-install tasks, you should now do the following:
The puppet master service needs a
puppet user and group. If this node might ever act as a puppet master server, do the following now:
puppetgroup, by running
sudo puppet resource group puppet ensure=present.
puppetuser, by running
sudo puppet resource user puppet ensure=present gid=puppet shell='/sbin/nologin'.
This step is optional on agent nodes.
OS X services are managed by launchd (which is controlled with the
launchctl command). To run puppet agent as a service, you’ll need to create a job configuration plist and put it where launchd expects to find it. (This service will be named
Make the service by creating a plist file at
/Library/LaunchDaemons/com.puppetlabs.puppet.plist. The contents of the file should be something like this:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.puppetlabs.puppet</string> <key>OnDemand</key> <false/> <key>ProgramArguments</key> <array> <string>/usr/bin/puppet</string> <string>agent</string> <string>--no-daemonize</string> <string>--logdest</string> <string>syslog</string> <string>--color</string> <string>false</string> </array> <key>RunAtLoad</key> <true/> <key>ServiceDescription</key> <string>Puppet agent service</string> <key>ServiceIPC</key> <false/> </dict> </plist>
Once you’ve created the plist, make sure it can only be modified by the root user:
$ sudo chown root:wheel /Library/LaunchDaemons/com.puppetlabs.puppet.plist $ sudo chmod 644 /Library/LaunchDaemons/com.puppetlabs.puppet.plist
Do not start the
com.puppetlabs.puppet service yet. If this node will also be a puppet master, do not start the puppet master’s web server yet.
You can customize this configuration if you want to.
By default, all of Puppet’s messages will go to the main system log; you can view them in Console.app under “All Messages,” and they will appear in
/var/log/system.log. You can keep Puppet’s messages out of the system log by changing
console in the
ProgramArguments array. You can also redirect Puppet’s messages and errors to their own files by adding the following lines to the main
<key>StandardErrorPath</key> <string>/var/log/puppet/puppet.err</string> <key>StandardOutPath</key> <string>/var/log/puppet/puppet.out</string>
(Note that the
/var/log/puppet directory doesn’t exist by default, so you’ll have to manually create it before launchd can use these files.)
You can also set any command line options you want for puppet agent by adding them to the
ProgramArguments array. For example, you could increase the detail in your logs by adding:
See the puppet agent man page for details about available options; note that any of Puppet’s settings can also be set on the command line.
As long as a service plist is in the
puppet resource service can manage it by name. You do not need to use
launchctl load to enable the service.
At this point, Puppet is installed, but it isn’t configured or running. You should now do the post-install tasks.