Puppet

Warning: Much or most of the content on this wiki is outdated or incorrect. We are in the process of migrating the useful content to a new home; in the meantime, you should consult docs.puppetlabs.com instead of this wiki.

Wiki

Generally speaking, there are very few differences between Mac OS X
and other Unix operating systems. OS X’s unix underpinnings are
evident in the short list of special cases we must take into
account when running Puppet on an OS X computer. Throughout the
rest of this document, I’ll refer to Mac OS X as Darwin.

Within the Mac OS X system administration community, there are
currently three major deployment strategies:

Monolithic Disk Image (Block Level Cloning)

Filesystem Synchronization (File Level Cloning)

Package Installation (often ad-hoc or on-demand)

Most large sites appear to deploy monolithic “master images” which
contain all managed software. This is similar to Ghost in the
Microsoft world, and is commonly achieved by using
Apple NetBoot-Install Service,
part of Mac OS X Server, or Mike Bombich’s NetRestore-Helper. The
popular NetRestore product by Bombich was recently retired, and
Deploy Studio has been recommended
as a capable successor, one that supports advanced large-scale
cloning using technologies like
multicastasr,
among others.

A common alternative to NetBoot-Install monolithic images are file
level synchronization services, such as
Radmind

Puppet plays nicely with all three of these strategies. In
particular, Puppet’s dependency mapping features set it apart from
most other tools, particularly for package deployment. In addition,
unlike the common Remote Desktop package deployment method, Puppet
is able to ensure packages get installed, even if the receiving
node is off line when the package is deployed to the site.

Mac OS X nodes have a slightly unique package provider available to
them. The pkgdmg provider facilitates the deployment of
software packaged with Package Maker, and wrapped in a disk image
(DMG). The package is wrapped in order to provide easier network
file copies, as a .pkg and .mpkg object are standard directories.

The pkgdmg provider also allows source packages to reside at any
location Open::URI accepts. In plain terms, this means a standard
HTTP server.

The pkg_deploy component defines standard package objects on the
client, and specifies the use of pkgdmg as the provider.

Note the use of require => Package[ard-admin300] in the
RemoteDesktopAdmin310.dmg definition. This dependency coupling
feature of puppet sets it apart from other tools such as Apple
Remote Desktop and Filewave.

The overall process this provider takes is:

If necessary, download the DMG to the local file system.

Mount the DMG using hdiutil

Install all .pkg or .mpkg objects in the root directory of the
DMG using installer

A somewhat unique issue when managing Apple hardware is dealing
with two very different hardware architectures; powerpc and
i386. Apple has done a remarkable job of pulling off the
complete transition of all their products to intel hardware, but
this poses a problem for some software which refuses to run on the
wrong hardware.

I typically handle these unique cases using case statements or
selectors: (Note: $hardwaremodel is automatically set by the
Facter library on each client node.)

Check out the Puppet With Launchd page for plist files and
information about running puppetd and puppetmasterd automatically
at system startup via launchd.

%flipper — docs.puppetlabs.com/osx, by analogy with /windows? We think this is probably sensible. Some of this info is outdated (multiple architectures). What ELSE should go in /osx? This is certainly incomplete.