For a long time, Mac Admins have been relying on the wonderfully useful tool DeployStudio. This free tool has been the mainstay of many deployment strategies, and has been my old faithful for years.
Despite its utility and functionality, it has some issues. Some of its functionality is almost black-box opaque, and we have to make some guesses and assumptions, and do some wrestling to make it work the way we want. The biggest issue, of course, is that it’s OS X-only, meaning that Mac deployment relies on having a Mac in a data-center environment. This makes many network administrators unhappy, as Apple does not offer an enterprise-level Mac anymore, not since the 2009 XServe was discontinued. Putting Mac Minis in the data center has raised eyebrows among the server purists and network neckbeards, but no one could deny how useful DeployStudio is. But since it’s not open-source, there’s not much the Mac admin community can really do about it.
Finally, that’s about to change – thanks to Graham Gilbert and his incredible work on his tool called Imagr. Imagr is an open-source deployment tool that runs in a NetInstall environment and makes running scripts, restoring images, and installing packages easy.
Imagr is in its early stages of development, so there’s obviously lots of rough edges and work to be done. Improvements are being made constantly, and by many contributors, so you can get an idea of the excitement of the community around an open-source tool to do deployments with.
Despite Graham’s excellent work at the wiki, getting a chance to play with it may be a bit foreboding to admins who aren’t sure where to start.
I’d like to get into a bit more detail so that future admins who want to test can investigate this thoroughly.
You need four things to test out Imagr:
- A NetBoot server.
The easiest way to accomplish this is with an OS X Server running the NetBoot service. If you have an existing DeployStudio server running on OS X Server, that would be a perfect choice. See Greg Neagle’s post above for how you can use Imagr with existing DeployStudio NBIs. I’ll be referring to this as the “Netboot server.”
- A target device or VM to test with.
I highly recommend using VMWare Fusion’s NetBoot compatibility to make testing faster, but if you’ve got a physical machine you’re willing to blow away, that works just fine too. I’ll be referring to this as the “client.”
- A web server.
OS X Server running a Web service will work just fine. I’m using my existing Munki repo. I’ll refer to this as the “web server.” If you want to use OS X Server 4’s default web server, just place all relevant files in /Library/Server/Web/Data/Sites/Default/.
- A machine to generate your NBIs on, preferably running 10.10.3 build 14D136 (to be compatible with all current Apple hardware).
This could also be the OS X Server if you’re using one, as long as it’s fully updated to the latest version of OS X. I’ll be referring to this as the “admin computer.”
In this post, I’m going to use my existing 10.9.5 OS X Server 3 to serve out NetBoot (since it’s already used for DeployStudio). I’m using my own workstation as the admin computer, running 10.10.3 build 14D136 to generate the NBIs. I’m testing with a VMWare Fusion 7 Pro VM as client that will be NetBooting.
Preparing Your NBI:
Note: pre-step zero: download the latest Yosemite installer from the Mac App Store. I’ll be using the default path:
/Applications/Install OS X Yosemite.app in this example.
- Create a file called
imagr_config.plistthat is hosted on your Web server.
I’m hosting it on my munki repo in a folder called ‘imagr’, so it can accessed at http://munki/repo/imagr/imagr_config.plist. We’ll fill the contents of this file shortly. For now, just make sure it’s accessible.
- On the admin computer, download or clone Imagr from the GitHub page:
git clone https://github.com/grahamgilbert/imagr.
- Create a file called
config.mkin the same directory as the “Makefile” that is included with the Imagr clone (
~/Applications/imagr/config.mkwould be the path in my example).
config.mkfile is going to be used to override the variables. Change the URL, which should be the accessible URL of your “imagr_config.plist” file. Additionally, if you have existing NBIs (from DeployStudio, for example), make sure you choose an index that does not collide with an existing one. The default is 5000:
URL="http://munki/repo/imagr/imagr_config.plist" APP="/Applications/Install OS X Yosemite.app" OUTPUT=~/Desktop/ NBI="Imagr-Testing" ARGS="-e -p" # Enable Netboot set, include python INDEX=5000
From inside the imagr directory, run this command:
- At the end of the lengthy command run, you should have a file located in your OUTPUT folder (in this example, on the Desktop) called “Imagr-Testing.nbi”.
- This NBI needs to be copied to your NetBoot server. If you’re using OS X Server as your NetBoot server, you need to place this file in
- Launch Server.app and go the NetInstall section. You should see it show up:
- Select your “Imagr-Testing” boot image and click on the gear icon to get its properties and details:
- First, make sure that the index it chooses (by default, 5000) does not collide with other NBI indexes. If it does, change the index number here (and then change your
config.mkto build NBIs using a different index).
- By default, the NBI only makes itself available to compatible Mac models. This is great for actual deployment, but if you want to do testing with a VM, you might need to turn this off. Change the availability so that it’s open for “all Mac models”:
- If you’re doing testing with a VMWare Fusion VM, you’ll also need to make sure that the “Imagr-Testing” NBI is the Default netboot image, as Fusion only works with the default. Select the image, click the gear icon, choose “Use as Default Boot Image.”
- Verify on your clients. You should be able to see the “Imagr-Testing” netboot image in the Startup Disk pane of the System Preferences.
Creating a Workflow:
Now that the NBI is ready, we need an actual Imagr deployment configuration so that it can be tested. This workflow information is stored in the
imagr-config.plist file we created on the Web server earlier. The workflow structure is documented on the wiki.
You can use any text editor to create this plist. For visual completeness, I’ll also include screenshots of Xcode’s visual plist editor.
Here’s the starting empty plist:
First, we need a password. On any computer with Python (such as the Admin computer):
python -c 'import hashlib; print hashlib.sha512("YOURPASSWORDHERE").hexdigest()'
Copy the long hash string and set that as the value of the Password key at the root of the plist:
Now it’s time to fill out a workflow. This basic workflow is going to install a live package (i.e. not at first boot). This package is a CreateOSXInstallPkg package for 10.10.3 build 14D136. It needs to be accessible via HTTP somewhere, so it’s a prime candidate for going into the “imagr” directory on the Web server I already created.
The package installation can be described like this:
In this workflow, we’re specifying a
restart_action value of
restart, which forces Imagr to reboot when the workflow completes (successfully).
components key lists the actual process for things we want to do. Here, we’re just using a component of type
package, which installs a package. We specify the
url to the package, and we’re installing this package live, not at first boot, thanks to the value of
Note that the
url key points to a disk image, not a package itself. CreateOSXInstallPkg produces a bundle package, not a flat package, and thus it must be wrapped in a disk image. If you aren’t sure how to do that, follow these steps:
mv InstallYosemite-10.10.3.pkg InstallYosemite-10.10.3/
/usr/bin/hdiutil create -srcfolder InstallYosemite-10.10.3 InstallYosemite-10.10.3.dmg
- Copy the resulting disk image to the location where it can be served via Web.
All this workflow accomplishes is installing the CreateOSXInstallPkg package, and then restarts.
Read the documentation to see how you can also leverage Scripts and Image cloning in addition to package installs. The workflow is fairly extensible.
Testing Out Imagr:
We have a NBI image we created, serving out NetBoot from the NetBoot server. We have a workflow in our
imagr_config.plist file to install a package. Now it’s time for an actual test.
- Boot up a VM or physical device (the client device) to the NetBoot image called “Imagr-Testing” (or whatever you named it).
- Log in using the password you specified (in my example, it was “YOURPASSWORDHERE”).
- Run your workflow!
Testing it out again, and then again
If you want to make any changes to your NBI (or are testing out new forks/updates to Imagr), you need to rebuild the NBI each time.
make updateto rebuild the NBI without needing to build from scratch. This will save time (hat tip to Erik Gomez and Clayton Burlison).
- Copy it to your NetBoot server into
- Change index number if necessary (which you should do by specifying a unique index number in
- Change the models to “All Mac models” if booting into a VM.
- Set the boot image as default.
- Reboot the client machine.
- Rinse, wash, repeat!