Relevant mostly to OS X admins
Category Archives: software updates
October 21, 2013Posted by on
Munki is awesome for updating software on macs. But it can be better, as it first requires an admin to know there’s something to update, and to get that update, (sometimes altering the installer so it works properly), and import it to munki. In a better world, systems will see that an update has been released and automagically bring it into munki. That better world exists, and it’s brought to us via 2 tools: AutoPKG and Jenkins.
AutoPkg can automatically check for, download and import software updates into munki. It is well documented in the wiki: I won’t be able to rewrite it better, so I direct you there.
Jenkins main purpose is to automatically test software builds, but it is also useful for automated tasks- think launchd on steroids, with easier reporting than you’d get from writing your own launchd scripts. It is also decently documented- a great starting point being the PDF and video by Greg Neagle at MacSysAdmin 2013
What’s not well documented is how to integrate them together. Your munki+autopkg+jenkins machine (presuming they’re one and the same) will already have an admin user, where you’ve been managing the munki repository. The Jenkins .pkg instaler will install a new Jenkins user for you, with a low uid.
I wanted to manage my autopkg jobs via my existing admin user account. That causes a problem for Jenkins, as it won’t be able to see the recipes imported to my admin account- they write to /Users/admin/Library/AutoPkg/RecipeRepos. My first step was to set ACLs to allow Jenkins to see that path:
chmod +a "jenkins allow read,list,readattr,execute,readextattr,readsecurity" /Users/admin/Library chmod +a "jenkins allow read,list,write,readattr,execute,readextattr,readsecurity" /Users/admin/Library/Preferences chmod -R +a "jenkins allow read,write,execute,delete,append,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit" /Users/admin/Library/AutoPkg
Second was to set up the Jenkins jobs to run the desired recipes. I set a job per munki entry, running a shell command such as
/usr/local/bin/autopkg run Spotify.munki --search-dir /Users/admin/Library/AutoPkg/RecipeRepos/com.github.autopkg.recipes/ --override-dir /Users/admin/Library/AutoPkg/RecipeOverrides
I also added a simlink from my “real” AutoPkg plist (/Users/admin/Library/com.github.autopkg.plist) to the parallel place in the Jenkins directory, so Jenkins runs will read the configuration of the admin account. It’s important to make sure this plist in the admin account directory maintains the following ACL. If you add a repo or otherwise change the file and alter the ACL, Jenkins runs will break.
chmod +a "jenkins allow read,write,execute,delete,append,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown" /Users/mdm01admin/Library/Preferences/com.github.autopkg.plist
On test runs on Jenkins, this gives the builds as desired. I can now create and edit overrides as admin, save them in the expected spot, and have Jenkins run them.
Update: 2014/01/20: Since blogging this, I’ve decided that for the sole purpose of running autopkg and reporting results, Jenkins is overkill. Instead, I’ve migrated from the method above to Sean Kaiser’s autopkg-wrapper script, a simpler bash script + launchd to execute it. One of the fun things about IT is that there are usually many ways to accomplish a task, and we all get to choose what the optimal route is.