Recently, I looked at leveraging the CrashPlan Pro REST API to extend the functionality of what can be done with CrashPlan Pro. It just so happens that I’m not quite done talking about CrashPlan Pro just yet. Now that you are off to the races with the API, it’s time to look at pushing that client you’ve got out en masse. Our good friends at JAMF software have been kind enough to publish a white paper that is pretty darn awesome to get ya’ started. But let’s look at what, other than setting the server address and registration key, that you can do.
There are a few files embedded in the installer package. Most importantly, these include a default.service.xml file and a userInfo.sh. The userInfo.sh looks at the system the package is installing on and figures out some variables to populate the default.service.xml file with. The default.service.xml file ends up with some other settings (ie – host name, registration key, etc) that are static in the file rather than dynamically loaded based on the output of the userinfo.sh.
To get started building your deployment package, open the Install CrashPlanPRO installer package and then copy the Custom-example folder, naming the new instance simply Custom (or rename Custom-example to Custom given that you can always redownload). Then find the commented out section for <!– <authority address=”hostname:port”/> –> and uncomment it, changing the address variable so that the hostname:port reflects the actual address and port combination of your server. For example, if your server name were backup.krypted.com and you were running CrashPlan Pro on the default port (4282) then the address to use would be backup.krypted.com:4282.
You also need to choose whether or not the server address will be shown to users, the registration key of the organization that your user will be placed into and choose how to handle the username and password. These are done using the hideAddress, RegistrationKey, username and password variables. If you wish to hide the server address from end users, once the package has been deployed, then the hideAddress variable would be true; otherwise it would be false. Each organization in your server will have a registration key. Use the quoted form of the registration key for the organization (or parent organization) that the package should join in the registrationKey field. If the username is to be dynamically loaded from the userInfo.sh then you should leave username=”${username}” and the password can be set to deferred or statically assigned as might be common with new deployments.
If this seems like a lot, the authority section should read as follows:
<authority address=”backup.company.com:4282” hideAddress=”true” registrationKey=”ABCD-EFGH-IJKL-MNOP” username=”${username}” password=”${deferred}” />
The above would suit most deployments. But the real flexibility comes in with userInfo.sh. Given that userInfo.sh is a shell script, you can go way beyond what CrashPlan intends. By default, the uncommented lines of the script include the following:
startDesktop=true
userHome=”$HOME”
user=”$USER”
userGroup=`id -gn “$user”`
userEmail=”$user”
The startDesktop variable defines whether the desktop application will open following the installation of the package. The $USER variable gives you the opportunity to build out the user that will be used based on a number of variables. One of which is the computername for those environments that use the user name in LDAP as the computer name. For example, a line to set a username might instead be:
user=`scutil –get ComputerName`.
Or the user name might be pulled in from a user fillable field in Apple Remote Desktop:
user=`defaults read /Library/Preferences/com.apple.RemoteDesktop Text1`
The reason for the focus on pulling the user name out of something other than the currently logged in user here is that many will want to push out a lot of computers en masse without logging in as the user who will get the systems for each one…
Of course, user isn’t the only thing we’ll want… The userGroup variable doesn’t seem to do anything, so we’re not going to be worried about that one. But the userEmail can often be looked up using dscl based on whatever LDAP attribute you might be storing it in… Oh, and then there’s the userHome. Well, what exactly do you want to back up on the machine? Just the home or /Users or /Volumes/MyBigOldXsan?
One very interesting aspect of the userInfo.sh script is that you can kill the package at this point and throw an error. For example, if the server is not accessible then the installer will complete but the package will not be useable. he banner for port 4282 isn’t easily programatically checked, although performing a quick check of the port is a good start for this (and becomes one of the ways you can monitor that CrashPlan Pro is running):
“`/Applications/Utilities/Network Utility.app/Contents/Resources/Stroke backup.krypted.com 4282 4282 | awk ‘{print $1}’`”
If the port isn’t open then let’s just:
else
killall Installer
fi
Or something like that… If you’re going to be pushing a package out then it’s not very likely that you’re going to worry too much about customizing how the installer actually looks. But, if you’re going to allow users to install it then you might want to. Basically, there are a number of images in a directory in your new custom folder called skin. In here, you can edit the images that make up those that appear throughout the package when it is run manually.
