This is our Firehouse

Firehouse is a OS X application to help manage sites within our Casper environment at Indiana University. We manage a central service for other IT departments across the University, currently around 30 sites and growing. In Casper, there are resource areas that are not site specific, so if you give Site Admins access to scripts, they could possibly use, edit, or delete another site scripts.

We wanted to prevent this from happening and shut down Site administrators access to shared areas. We would then upload and transfer scripts, packages, and printers for the Site Admins. As the service grows, we know this level of support is unsustainable for our small department. Wanting to keep the same restrictions in place, but also give our Site Admins the ability to manage their own resources we developed Firehouse.

First the name…I’m a huge Ghostbusters fan. Casper…Ghostbusters…perfect.

Poster“This place is great! You gotta try this pole!”

How it works (in a nutshell)

Firehouse manages which resources the admins can see, edit, and post. Here’s how it works.



Screen Shot 2016 05 25 at 10 32 45 AM

The first step in the login process is to check for any updates to the Firehouse application itself. This happens through a appCast mechanism.

Next the user logs in and Firehouse authenticates the user to sites by looking at which sites are available via the Casper API and then authenticates the user to their sites via Active Directory.



Screen Shot 2016 05 25 at 10 33 22 AM

We enforce a strict naming scheme in our shared environment. This is what allows Firehouse to parse out the objects and allow access to site admins. It also enforces the naming convention, you cannot upload anything not prefixed with your site name.

Here you can see admins can quickly upload and delete their scripts without the ability to effect anything but their own objects.



In the packages tab, you are presented with a list of all your sites installers. Delete will remove the package.

Screen Shot 2016 05 25 at 10 46 48 AM

Adding a packaged presents a screen that lets you configure your installers settings. The same naming conventions are enforced here. Upon clicking done, the installer is uploaded to the Root JDS via WebDav and the Installer information is posted to the JSS via the api. The installer will then replicate out to the JDS children which happens on a recurring schedule.

Screen Shot 2016 05 25 at 11 05 03 AM


In its current version, Firehouse can only upload printers that use generic ppd’s. I am currently working on updating this so fully customizable printers can be uploaded.

There are 2 primary ways to setup a printer here. You can manually enter all the information or you can import a local printer and all its detail will be entered for you.

Screen Shot 2016 05 25 at 11 12 45 AM

Tons of Open Source Code

I’ve added a ton of code to github that might be useful.

Progress Screen
A recreation of IBMs Casper Enrollment Screen demoed at JNUC 2015
Link to Code
Link to JNUC Talk

This is a simple application that launches full screen and reads the jamf.log on the machine which is used to generate a progress bar.  You can customize the webview to display your own content.

A utility application for OS X that saves and quick switches the Casper Suite Tools to JSS servers.

Link to Code and App

SwitchJSS is a small application that saves your JSS server addresses and quickly switches your Casper Suite tools to that address. No more option+clicking and retyping every time!


Link to Code

This is a native OSX Agent that will force logout users after 20 minutes of being idle. Since applications can hold up the logout process, this agent will go through all active applications and force quit them. This could be useful in a public computer lab situation where users walk away and the Mac gets locked.

Both the logout time and a application force quit exclusion list is changeable in the source code only.

Fast User Switching: If this OSX Feature is used, once the user switch has happened the previous user is forced logout after 5 minutes. This is also editable in the source.


Link to Code

User Agent that unmounts removable media when switching between users on OS X.  This is useful if you are trying to prevent OS Xs behavior of keeping any mounted drive available to all users in a multiuser environment which including keeping drives decrypted.

This is an example of how to unmount removable media when switching between user using Fast User Switching on OSX.

SwiftJSS (Mentioned before…but worth mentioning again since it’s been updated)

Link to Code

This is an example on how to leverage JAMFs Casper API using Swift in OSX. This is also an good example on how to leverage a REST API in iOS as well.

Casper Site Management Enhancement with the API

I work in a Casper environment that relies heavily on the Sites feature to deploy a unified Apple management solution across the enterprise.   Out of the box, JAMFs Casper has been a great solution for us.  There are a few things we would like to see Site admins to be able to do, amongst them, managed their own scripts and printers.  We have leveraged Caspers REST based API to give the site admins additional access and control.

Enter The Ghostbusters

The in-house tools (named after Ghostbusters) give the Site Admins the ability to manage items not normally available to that user level.  These applications were development for OS X with Cocoa and Obj-C / Swift as the primary languages. (See my SwiftJSS example) The architecture would also work with other languages,such as Ruby or Java.  

So how does this work and what does it really do?  Here’s a logic quick graph of what’s happening behind the scenes. 

My Diagram


The Site Admins belong to a Active Directory Organizational Unit associated with their site.   In this case, I use the OpenDirectory Framework to authenticate and lookup users Site credentials. It’s then cross referenced with the API by correlating the OU information with the proper Sites. 

 Middleman API / Behind the Scenes

Once we have the user authenticated to the proper site, a middleman API only account is used to get and push content to/from the JSS.  You could just give the user the API permissions and use that account for the API calls.  I opted for a 3rd Party account that I control that can be deactivated and cut off all application access. This also allows me to control their API access and force them to use my tool which enforces our naming rules.

The application then goes out and gathers the information needed for the user.  This is usually categories and whatever object the app is designed to edit, like Scripts. 

 Matching Objects to Sites

We enforce a strict naming scheme in the shared areas of Casper.  SITENAME-LABEL.  Since the scripts and printers specific for each site is prefaced with the site name, we are able to parse only the objects belonging to the users site. On the posting side, the script name is auto-magically prefaced with the site name before posting.

 XML Generation

A easy to use UI is presented to the user.  They enter the information and the application generates the proper XML for posting. Easy peasy. 


Here’s a look at what the completed Script management app looks like, called Egon. 


Screen Shot 2015 03 17 at 1 17 03 PM


That’s it in a nutshell.


Use JAMFs Casper API with Swift

I have updated JAMFs Cocoa example with a Swift version I am using internally at work.  The code is up on GitHub for anyone to use.  This example counts and displays the number of managed machines in a JSS. Pretty simple.

I have been slow to get on the Swift train.  Now that I’m here….full steam ahead.  I am really enjoying it.  I had been so stubborn to code outside of Objective-C.  

Just one important code note.  The JSS will sometimes return JSON instead of XML.  You can always force XML with this code.  This was not part of the original SDK example. 

  let theRequest = NSMutableURLRequest(URL : NSURL(string:urlWithPath)!)

        theRequest.timeoutInterval = 60;

        theRequest.addValue(“application/xml”, forHTTPHeaderField:“Accept”)




The Return of QWing


Qwing is an iOS application that I have been working on and off for over a year.  Before the switch to coding full time (new job, woot!)  this was a learning project I dream’t up to get my skills up.  Now that there is WAY more free time than I was ever used to, development for Qwing is once again pushing forward on a near daily basis.  My time is still spit between the job that keeps the light on and this project of love.

I am opening up the development process here to solicit feedback and keep everyone informed about its release.

So what is Qwing?  In a nutshell, Qwing is an offline note taking tool that persists Qlab data.   Well…what does that actually mean, you ask? The application was conceived during my time as an Audio & Video Supervisor. There were several day to day trends sound designers seemed to fall into.

  1. Most designers no longer create paperwork before building cues.  The cues themselves become the documentation.
  2. There is a need for an offline reference, especially in a preview scenario, when notes are needed.
  3. There is currently no quick reference to previous versions of the Workspace.
  4. The current note workflow during shows often times is:  iOS Notepad —> copy / paste Email.

Here is how Qwing begins to address some of these currently.  The images below are from the current state.  The UI is unrefined at this point.  Much of the work has been going on behind the scenes on the Data Model and Controller programming.  What is being shown today works, this is not a mock up.  While designed initially for the iPhone, the app is currently being developed for all iOS screen sizes.










Importing Workspaces: The first image on the right is a placeholder for what will eventually be a document picker that will also be able to sync between devices with iCloud.  For now, you can see that Qwing will allow you to carry multiple shows with you at all times.  The text here is pretty generic and will allow for some customization down the road.  The color scheme is currently black and grey, with white text.  Blue is an indicator of important information and/or buttons.

The middle image is of the project detail, which still needs some UI customization to conform to the rest of the app.  Here you can jump to the notes for the show, view all the saved workspaces, or import a Qlab Workdspace.  The far right image is where you will select a workspace to import.

Screen-Shot-2015-02-17-at-1.10.32-PM.png Screen-Shot-2015-02-17-at-1.11.46-PM.png Screen-Shot-2015-02-17-at-1.13.08-PM.png








 Cue Structure: The cue structure follows the standard structure in Qlab.  Select the workspace, cue list, cue, cue detail.  The image on the far left should give you and idea how the Workspaces are stored. While I imported these back to back for the sake of this post, the import times and machine names could be different. You can even mix and match other workspaces that comprise a single project.  The triangle icon there is a stand-in, I’m pretty bad at the graphics creation.

The Note+ button allows you to immediately take a note on that object. A window with the cue details, flags, and a text block allow you to quickly make a note that will always reference back to the exact item you were looking at.

Search: Search works like you’d expect. You can quickly find the cue you’re looking for.

The Cue List  quickly shows relevant cue data.  At a glance, the colors help you quickly identify the cue types.  Blue for a Group Cue, Grey for Audio, and Orange for Video. The other cue types all have distinct colors as well.

You can “drill down” Group Cues to see the contents.

Screen Shot 2015 02 16 at 12 03 10 PM







The Cue Card above is the cue detail, this is the early version of the Audio cue.  Here you will be provided with even more info about the cue.  Cues like Fade and Video will have relevant details in place of this.  The faders on the bottom scroll left to right to display all of the output settings.

On Deck for Development:

Notes: While the notes do actually work currently, I am not happy with how they are currently working. This is at the top of the list and should be ready soon.  I intend the notes to be easy to use and share.

UI: Icons / graphics, layout, colors, all need some help.

Thanks for stopping by.  Leave me a comment or shoot me an email, I would love to hear from you.