How to use DeployStudio when you can’t have a Mac in the data centre

UPDATE: Ben Toms’ excellent AutoCasperNBI is the perfect tool for helping you create an NBI that you can use with this guide. Go get it here!

I have created a script to do some post processing to the AutoCasperNBI created NBI, however it is extremely site specific so there is no point in me sharing it. However, to achieve a basic DeployStudio Server running inside a NetBooted client as I have described in this post. Just use AutoCasperNBI to create a NBI and then follow the steps below:

• Create your NBI with AutoCasperNBI.

• Mount the DMG and install the DeployStudio Server package to the mounted NBI.

• Now you will need to edit the DeployStudio plist to add the extra items (I’ve listed them in the original post below) it should end up looking like this  (You will need to change the login username and password to the username and password you want, note that the password is encrypted and you need to use DeployStudio Assistant to create a new plist in to get the password. I’ve been unable to work out what encryption DS uses to generate the password)

• Remove the LaunchAgent for Casper Imaging (/Library/LaunchAgents/com.AutoCasperNBI.CasperImaging.plist)

• Replace it with your own that triggers your script which should be similar to what I have shown you below.

• Essentially your script should mount your DS_Repository from your fileserver using whatever logic you need to do this. It could be as simple as hard coding the IP address. Then once mounted start DeployStudio via launchctl.

• Finally open up the DeployStudio Runtime! It should autologin and you’re set!

So we all know and love DeployStudio. BUT the main problem for using it in some enterprises or educational sites is that we have to run the DeployStudio Server on Mac OS X, which require Mac hardware.  For some sites having Mac hardware in the data centre is never going to happen.

I was in this exact position and there  was absolutely no chance that I could get a Mac into the data centre or out to our remote sites to act as the DeployStudio Server.

That doesn’t leave many other options available for super easy and slick netboot based imaging for our Macs.

Then I had an idea. The machines that we are netbooting are Macs…. So why can’t we run the DeployStudio Server from the NBI? Then we just have the Runtime application connect to itself at 127.0.0.1:6080 and away we go.

So I went ahead and created a netboot image that had DeployStudio server installed on it and configured it to access a local repository at /Volumes/DS_Repo.

The reason I told DS to use a local file repository instead of a network share is because if I specified a network share, then that address is hardcoded into the com.deploystudioserver.plist on the NBI. I have multiple remote sites and would rather have just one NBI that I can shove out to the remote sites, I can then have a script that runs at boot thanks to launchd and mounts the correct file share repository based on IP address. We know that at each remote site we have a file server at x.x.x.20 so it is trivial to get our IP address strip off the last octet and replace it with 20 and then use that IP address to mount our network share into /Volumes/DS_Repo ready for DeployStudio to access.

Here is an example of the script that I use, I also enabled ARD as it can be handy for troubleshooting especially at remote sites.

#!/bin/bash
## Build and set our variables
## Get our IP address and knock off the last octet
baseip=`ifconfig en0 | awk '/inet[ ]/{print $2}' | cut -d "." -f1-3`

fileserver=$baseip.20 ## Now we create our file server address
usrname=ladmin # username to access our fileshare
password=admin # password to access our fileshare
mntpoint=/Volumes/DS_Repo # mount point on the filesystem to place our share
share=DS_Repo # Name of our sharepoint

## Script Actions
mkdir $mntpoint # Go ahead and create a folder to put our sharepoint in

## Mount the share
/sbin/mount_smbfs //$usrname:$password@$svrip/$share $mntpoint

## Now start DeployStudio Server
## This should be run as root
/bin/launchctl load -F /Library/LaunchDaemons/com.deploystudio.server.plist

## Oh lets start ARD for the fun of it as well
# Enable ARD for user
enabled_ard_user="ladmin"

# Enable for user and give all privileges
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -users $enabled_ard_user -access -on -restart -agent -privs -all
# Allow access for all users
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -allowAccessFor -specifiedUsers

# Finally open DeployStudio Runtime
/Applications/Utilities/DeployStudio\ Admin.app/Contents/Applications/DeployStudio\ Runtime.app/Contents/MacOS/DeployStudio\ Runtime.bin

I also modified the deploystudio server launchdaemon in order to prevent it from starting the server automatically at boot. Instead we will get our script that mounts the network share to start DS after it has successfully mounted the network share.

The DeployStudio Server launchdaemon exists at : /Library/LaunchDaemons/com.deploystudio.server.plist

To prevent the server from starting automatically we need to edit this line

<key>RunAtLoad</key>
<true/>

to

<key>RunAtLoad</key>
<false/>

So now we have a netboot image that boots up, checks to see what IP address it has and then connects to its local file server and mounts our DS_Repository share. Then it goes ahead and starts the DeployStudio server process, and opens up the Runtime application which is configured to access 127.0.0.1:60080

This is done by editing the /Library/Preferences/com.deploystudio.plist file and ensuring these keys are present

<key>server</key>
 <dict>
 <key>url</key>
 <string>http://127.0.0.1:60080</string>

Awesome.

But how do we update the workflows, scripts and packages?

Easy.

I run a DeployStudio Server instance in a VM, this accesses a local file share for its DS_Repository which we call the master then if I need to make changes to a workflow, these changes are saved into this master DS_Repository file share.

All we to do is have our master DS_Repository sync up to our remote sites DS_Repository file shares and the netbooted clients will pick up all the changes. We have a pretty tricky way of doing this via SCCM, but for smaller sites this could be a simple rsync script that synchronises the repositories over night.