SWY's technical notes

Relevant mostly to OS X admins

Monthly Archives: October 2013

AutoPkg and Jenkins under one admin account

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.


NPD Power Viewer and XenApp

As a mac-based organization, there are always times you have to deal with the occasional non-mac software. My employer’s daily use is our accounting vendor’s software, as they’ve not yet transitioned to delivering all the services via web browser.  To provide this to Mac clients, we use XenApp.  For those who haven’t yet met XA, it involves installing applications on a Windows server, and “publishing” them.  These published apps are accessible from multiple endpoints via Citrix Receiver- laptops, phones, tablets, ect. It’s much like VDI, but without the desktops, just the app.

Last week, I was informed that our research department would have the task of analyzing data a client had obtained from NPD.  Of course, there is no native MacOS (app or web) to work with their data, it’s provided in their proprietary format, and accessed by their Win2K era viewer app.  Reluctant to bring up 2 new local VMs for users when the real task is to access this data, I started installing it on my XenApp server.

All went normally to publish the NPD Viewer app, with a slight departure from the normal procedure because the end goal isn’t specifically the app, but the data it provides, which must be accessed through the app. That’s handled by a Command line formatted as <“path to .exe” path to data file>.  For my admin user, it all worked perfectly.

However, when the user accounts tried, the app would launch, start a gray box where the image for the splash screen would go (but never did), and halt:


(reload the page to refresh the gif animation)

I tried opening up permissions on 2 paths that NPD writes to- C:\Program Files\NPD and C:\Program Files (x86)\NPD, with no change in results. Expecting there was still a permission error somewhere, I grabbed a copy of Sysinternals Process Monitor, set up a quick filter of “company” “contains” “NPD”, started capturing, and launched the published app from an account I knew would fail.

In just a few seconds, I was showing 4,636 events of a 586,538 captured- Process Monitor will grab an overwhelming amount of data.  Not really knowing what I was seeking, I started scanning for anything that looked suspicious, learning much about what is and isn’t suspicious in such a capture along the way.  I eventually found my way to a couple of entries with a result of ACCESS DENIED.


The redacted text is the account name which installed Power Viewer

Reading the whole line, I see that the powrview.exe process, launched by User2 is trying to read C:\Users\<admin account that installed the software>\Windows\cPopMenu6.ocx.  App launched by User2 has no business trying to access that path or file, and is hitting a dead stop when default permissions appropriately say it can’t get there.  By granting read access to that folder for the few users that can access this published app, I was able to get the needed results.  It’s not pretty, but when an app does ugly things, the fixes sometimes are too.