Getting Munki up and running.

Munki is a great tool for installing/updating/uninstalling software packages. Munki provides a central repository of software and allows for easy software-build management. With Munki, you can keep all your software in the repo, write manifests for each of your builds and push out the manifests out. Another advantage of Munki (that may be later utilized in our environment) is that it allows non-admin users to update the software on their machines through the updates provided by Munki.
Previously we were using DeployStudio to push out tiered builds, however the downside of this method is that it’s not simple to mass-update/uninstall software. The methods to make these changes would include either (a) writing a script that uninstalls packages, (b) rebuilding the machine with the new software build. With Munki, all of that is eliminated, and it comes down to maintaining a software manifest.
Currently we’ve installed Munki on https://adams.cul.columbia.edu. The wiki pages used for this are the following:

Step 1: Create a CA and certificate for our Munki Server to use

When setting up Adams, I more or less followed the instructions above (Using Munki with SSL client certificates). A quick outline of the steps would be:
1. Download materials
2. Edit config/openssl.conf (optional, either do this step to setup default values or enter in values as you run the following steps)
3. run bin/createCA.sh – creates cert, use Common Name MUNKI_CA (identifies which CA you’re creating).
4. run bin/newServer.sh – create server certificate, use the domain of your server as the Common Name (e.g. Common Name = adams.cul.columbia.edu).
5. run bin/addClient.sh – creates client certificate, use Common Name has to be the argument you used to start the script.
6. Store the contents of the parent folder (that contains bin, demoCA, servers, clients) in /private/etc/munki)
7. In Server Admin (assuming your munki server is running on an OS X server 10.6+), under add the certificates you just created.

Step 2: Set up your repo

1. Add a site under “Web” with Server Admin, under the security tab, use the certificate you have just imported.
2. Within the directory of your site, create the following directories:
a. munki/
b. munki/repo
c. munki/repo/pkgs
d. munki/repo/pkgsinfo
e. munki/repo/catalogs
f. munki/repo/manifests

Step 3: Configure Munki on the server

When setting up Munki, you could follow the steps in “Installing on a standalone machine”, but I found a very useful alternative to that in the “Creating Disk Images” page. The nugget being: /usr/local/munki/munkiimport, which will import .pkg files and turn .mpkg files into a disk image for Munki. That’s not the best part though, the best part is that it creates the catalog files, pkginfos and puts the disk image/pkg in the repository. The only setup that needs to be done is running /usr/local/munki/munkiimport –configure to set up the basic values, i.e. the repo path, munki’s url.

Step 4: Secure the server with some basic authentication

Firstly, in Server Admin, go to Web -> Sites -> YOUR SITE -> Options and enable all overrides. Then in terminal cd to your repo directory and create a .htpasswd file with the following command:

$ htpasswd -c .htpasswd munki
New password:
Re-type new password:
Adding password for user munki

Then you need to create the .htaccess file in your repo’s directory with the following content:

AuthType Basic
AuthName "Munki Repository"
AuthUserFile /path/to/your/munki/repo_root/.htpasswd
Require valid-user

Step 5: Configure Munki on the client

First move munki_client.pem from clients/munki_client/ and cacert.pem from demoCA/ to the certs directory in /Library/Managed Installs/ folder (or wherever you’ve set the ManagedInstallDir) on the client, you may have to create this directory.
Munki’s configuration plist values lists all the possible values for the plist that we’ll use on the clients. Make sure the following are set properly:

  • ClientIdentifier (the manifest that the client is going to use)
  • ManagedInstallDir (local directory that Munki will use to store pkgs)
  • LogFile
  • LoggingLevel
  • UseClientCertificate (set to TRUE)
  • SoftwareRepoCAPath (set to the certs directory)
  • SoftwareRepoCACertificate (set to cacert.pem’s path)
  • SuppressUserNotification (if set to true, will make the process silent)

There’s more on that page, customize your own.

In our deployment we plan to:

1. Create a custom Munki client pkg, which will contain the certificates and ManagedInstalls.plist (as well as create custom directories if we see move in that direction). We will deploy this package via DeployStudio, and then run a script that will call Munki to install software.
2. Create sub directories within our repo based on software vendor and manifest.

Advertisements

Installing and using DeployStudio

Installing DeployStudio

First of all download the latest DeployStudio from their homepage(link). The instructions on their site are pretty clear for installation. First, run the installer and install DeployStudio. Then run the DeployStudio Assistant to setup your DeployStudio Server (Start the DeployStudio server when it prompts you).
Set the server address to your server, don’t change the port, set administrative account.
The next screen will allow you to choose whether or not your want your server to be a replica or to be a master.
After that, DS Assistant will ask your to choose where you want your repository, choose a network sharepoint (have an AFP sharepoint set up previously for this). Set the URL and authentication, don’t worry about the ‘advanced parameters’. If you have a mail-server then you can have DS send you mail upon completing a workflow (LTR). While it isn’t critical, it is recommended that you have a SSL certificate with which you can secure network traffic (i.e. the next step), in this step you also choose which interface you want DS to communicate over.
If you have an OD up and running and would like to designate multiple administrators for DeployStudio, you can drag/drop their groups in the next step into the appropriate places. Hit “Continue” and then hit “Continue” again… the options that you have skipped related to multicasting (which is still buggy over subnets). DeployStudio will now tell you setup is done, and your server is ready to use!

Using DeployStudio

Using DeployStudio is easier than setting it up. There is one thing you want to consider before jumping in though, are you going to deploy a monolithic image or a tiered build? There are advantages and disadvantages of both:
Monolithic Build:

Advantages Disadvantages
Easy to build
safe to deploy
Bulky
takes forever to deploy
hard to customize

Tiered Build:

Advantages Disadvantages
light
low network load
easy to pinpoint mistakes in workflow
Can be difficult to build custom packages
if a package isn’t configured properly, it’ll fail

While DS is great at deploying images in general, it’s my opinion that it’s best suited for the tiered build. Firstly, if there are procedures that Deploy Studio cannot handle in a workflow (i.e. setting up ldap connection to culdap), do them on the base image. Update the OS software on the base image and then netboot to the DS server via the bless command (sudo bless –netboot –server bsdp://your.DS.server.dns) and reboot. The machine will reboot to DS at which point you can make an image of the machine via one of the default workflows (“Create a Master From a Volume”). Once the image is made you can deploy it to any machine that boots to the DS server with another one of the default workflows (“Restore a master on a volume”).
With the base image ready, prepare software .pkgs/mpkgs for any software you wish to install and place them in the DS server’s package repository. Next open DS Admin and create a workflow. The ideal workflow should include the following steps (these are all drag and drops):
1. Partition Drive
2. Restore Image (restore your base)
3. Firmware lock
3. Install pkg (one of these each for each pkg you want to install)
note: you want to check on “postpone installation” so that it will install on the first launch.
4. Software Update (also postpone until reboot).

The main difference between the tiered build workflow and the monolithic workflow is step 3 in which the packages are installed. Also before creating the base image make sure to turn off the airport (otherwise the software update gets stuck). That more or less covers installing and running the basic Deploy Studio setup.