The Oxford University Challenge

Last September (2014 for those in the far future from when i’m typing this), I was invited to interview for an IT role at Oxford University. Highly prestigious place and job, so they were going to set a challenge to see who was best.

I can tell you right now it wasn’t me. Close but no cigar. I know how well I did, but I don’t think I can divulge how close I came. Read into this what you will. Their technical interview challenge was complicated and required both Casper API and unix scripting skills. The following tasks required were as follows:

1) A way to create via a script a Casper Site, with an attached smart group that looked for OS X clients that were running Yosemite.

2) A way to store the SSH public keys of an OS X client into the JSS.

3) Programming the known hosts file with ssh keys avoiding the need to manually add computers to it.

Bonus Challenge: Restoring those SSH keys back at imaging time.

All of these require the storage and retrieval of information into the JSS. All except for the 2nd challenge use the API that JAMF provide. Let’s start with the first challenge.


This is a bit of a cheat 😉 The JSS help will handily help you format the correct xml data. Once you have that in place, this script takes advantage of BASH substitution to place the correct data in the correct place. By specifying the required site name when calling the script, that is then passed both to the smart group name (ensuring a unique-ish name) as well as placing the smart group in the correct site.

The other “cheat” is how to upload that information back to the JSS API. Turns out that if you’re doing things in bash as I am, it’s just easier to write the xml to a file and use the curl command to upload it. Place your files in /var/tmp and they’ll disappear at next boot.

One piece of supplied info having two effects. Well I thought it was neat 😉 Anyway next challenge.

Second challenge is easily done though the Casper JSS extension attributes. For those who’ve never dealt with them, they’re a way of executing scripts and having them report directly to the JSS the information they’ve gathered. Three EA’s for three different public key files. Simple. I’m not dealing with the private keys: i’ll let the OS take care of those.


Third challenge. Let’s start by using the Casper API to pull the names of every single computer stored in it. I am not happy with what I came up with but there was significant time pressures to which I was working. I read every single computer name into an array, then loop around that array using the ssh-keygen and ssh commands to pull the required info from the remote computer and putting it into the known_hosts file.


The significant issue with this method is when a particular computer isn’t online. This will timeout after a significant amount of time and multiplied by the amount of computers in your JSS would be a very non optimal method.

I was also marked down for copying the file to all existing users on the system. That’s a methodology thing, rather than a technical issue.

Bonus challenge: restore the keys at imaging time. The script here takes advantage of running in a Casper Imaging environment. We’re using the Casper API again to grab the current computer’s inventory record and reading out the keys we stored in the extension attributes. Writing those back into files then giving the correct permissions is easy at that point.


Now can anyone can find the deliberate mistake in the code … 🙂