Mac – Munkiserver Puppet Module

Forget what you know about the word puppet because when I say Puppet I want you to think of configuration/state management to the extreme, and not marionnettes. What can Puppet do, you ask? Puppet can manage a machine from the beginning to the end of its lifecycle. It can enforce a state on a machine. You want to ensure that the SSH/Apache/MySQL services are always running? No problem, Puppet will do that. And you’ll see this first hand after the jump, but it can also automate repetitive tasks (ex: setting up clients) and quickly deploy additional servers to help load balance a critical service. Alright, this sales pitch is over. If you want to know more, you can learn more learn more about how Puppet works here.

Munkiserver? You know about munki, Greg Neagle’s fantastic software management application, but what is munkiserver? Munkiserver is a Ruby on Rails web application for managing your munki setup, developed by Jordan Raine. It uses munki a little bit differently but adds some neat features. For example, clients are in a 1-1 relationship with the server  (i.e. each client has their own manifest), making it super easy to specify one off installs. However, you can still group clients together using computer groups and apply software bundles to them, thus achieving the same level of functionality as regular manifests in vanilla munki. Another difference is that all configurations (ex: pkginfo, manifests, bundles, etc…) are stored in a backend database; there is no flat repo. This does add some complexity and makes it impossible to add manifest logic. However, munkiserver does give you the ability to add raw tags to a package’s pkginfo file via the web application. Now that I mentioned it, everything is done through the web application:

  • Adding/removing computer clients
  • Uploading/editing packages
  • Editing manifests
  • Assigning user/group permissions
  • Viewing which packages have updates (uses to check)
  • Viewing warranty information
  • The list goes on…

If munkiserver sounds like something you want to try but don’t want to spend the time setting it up, today is your lucky day. I’ve wrote a Puppet module that will automatically configure a new instance of the munkiserver application on any Mac OS X 10.6+ system in 20 minutes or less (depending on your internet connection, and CPU speed). And regardless of whether or not you have any knowledge about Puppet or an existing Puppet server, this writeup will assume you don’t in both cases, I will explain how to deploy a new munkiserver using only a local Puppet manifest (no Puppet server required). This is because if you already have a Puppet server I think you’ll know what to do for the most part. Details after the jump.

Continue reading


Mac/Windows/Linux – Disabling Adobe’s PDF Plugin in Firefox

Back in January 2010 Greg Neagle wrote up a popular article detailing how to set default settings for Firefox. While his article was Mac focused, this technique is able to be used on all platforms. And in using it, you can effectively control a user’s experience with the browser. I previously have been using custom cfg files to disable the annoying update popups users receive, as we use munki to update software and most of our users aren’t administrators anyways. I recently just updated our cfg to disable Adobe’s PDF plugin and thought I’d share how I did it as, if you can believe this, it’s prone to problems. If you don’t already have a custom cfg file in place I recommend reading Greg’s article and following his instructions first. If you’re doing this on Windows or Linux, swap out the file locations mentioned in Greg’s article for the ones posted in the resource section at the end of this article.

Got a custom cfg file? Good. Add the following lines, this has been tested on Firefox 17+:

pref(“browser.preferences.inContent”, true);
pref(“pdfjs.disabled”, false);
pref(‘plugin.disable_full_page_plugin_for_types’, ‘application/pdf’);

The first two lines enable the in-browser PDF viewer Firefox has recently added. The third line forces Firefox to switch back to its default PDF handling action (Use Preview) if any 3rd party PDF plugin is selected on launch. Note that non 3rd party options (i.e. Use Preview, Always Ask, Preview in Firefox, Save File), are able to be chosen and will stick on re-launch. I want to emphasize this point, the above does not stop a user from selecting a 3rd party PDF plugin for their session but will merely reset it if its been done on re-launch.



Windows (may vary on the architecture version installed):

cfg: “C:\Program Files\Mozilla Firefox”

js: “C:\Program Files\Mozilla Firefox\defaults\pref”

Linux (may vary on flavour, installation method, and/or architecture version installed):

cfg: ” /usr/lib/firefox/”

js: “/usr/lib/firefox/defaults/preferences/”