Intro This is part one in a four part series on using Puppet on OS X. However to understand my move to Puppet I wanted to share my thoughts on Configuration Management (CM) in general.
For the last five months, I have been seriously questioning my deployment/management process. Even with Munki’s native support for configuration profiles in v2.2.4, it has always seemed like I was creating extra work for myself.
Intro I have been using puppet in one way or another since April of 2014. My first introduction to puppet was boxen but up until recently I have only focused on how puppet can apply to me personally. With this module and a few ideas I have for the future this is going to change the way clients are configured at $work_place.
Now this technically is not my first module it is the first module that I have created the logic and wrote entirely myself.
What is boxen? So odds are if you have landed on this page you have probably already heard of boxen. For those who have not heard yet, boxen is an open source project created by the good people at github.com as a way to quickly setup a Macintosh computer. Boxen can also be used as a way to keep certain settings managed between two or more devices. Think for a second, your laptop goes with you everywhere and along with that you have all of your custom shell scripts, shell alias, ssh keys, etc.
For various reasons I decided to set up my puppetmaster on an OS X install of Mavericks instead of what I would consider the norm, being a linux distro. Here are the results. This documentation is strongly based on the article by Nate Walck on afp548.com.
Notice: I do not use these instructions any longer. The setup of a puppetmaster on OS X Server was just for testing purposes.
