Hi All. Back in September this year I started up another short series on getting started with DeployStudio (aka a 101 style workshop). After a bit of self-promotion on Facebook, I received a valid comment from Graham Gilbert.
Now for those that are not aware, Graham has recently been working on and has developed a solution to replace the majority of DeployStudio’s functionality with an Open Source system that does not require a Mac Server.
It’s a python application that runs within a NetBoot set (or a NetInstall set with the Python tools installed) and pulls it’s data from a web server (HTTP or HTTPS) in an almost identical way to Munki. And yes, you can host your Imagr files on the same web site / server as your Munki Repo. This is something I’d encourage, as it’ll potentially allow you to reuse some of your installers.
There are as number of reasons for Imagr’s existence, and I’m sure Graham himself can add to the list, but from my viewpoint, I see this as:
1. DeployStudio is closed source, meaning that should the developer not have sufficient time or resource to develop fixes or new features, no outside personal, such as the Mac Admin community, can step in and assist.
2. Mac deployment has moved (is moving?) away from full, monolithic imaging, into a more modular methodology, using such tools as Casper, Munki and Absolute Manage. In the same way, Imaging itself has moved away from large workflows, deploying all the required software – towards a laying down of a basic OS and the local agents / tools to bootstrap the device, with the main deployment system taking over after the first boot. This reduces the need for a complex (and potentially more buggy) imaging solution.
3. As Apple no longer produce a rack-able server product, with hardware redundancies, many Mac Administrators are looking to utilise non-Apple hardware to provide deployment and imaging solutions for Mac devices. Imagr simply requires a NetBoot image and a Web server.
I’ve built a working setup a few times in lab environments and I feel I’ve gathered enough understanding to share some of my knowledge!
The current plan is to produce and ‘publish’ a number of posts getting you from a standard Mac Server to a proof of concept Imagr solution in as straightforward a way as possible. As with many a 101-style blog, this will mean some sacrifices. This blog is designed for those who’ve had no previous Imagr experience and have an interest in getting a leg-up on the solution.
This ‘part 1’ blog looks to cover the information around Imagr, and a refreshing on getting your NetBoot service up and running. ‘Part 2’ looks to cover the configuration of the OS X web server. ‘Part 3’ should cover the creation of the Netboot set using AutoImagrNBI. ‘Part 4’ will cover populating the Imagr repo with content and building a workflow. ‘Part 5’ will look at some possible use cases for Imagr with the current popular management tools.
OS Used: OS X El Capitan (10.11.1)
Server App Used: 5.0.15
Imagr Used: 0.0.4
Recommended knowledge (but not required):
- Apple NetBoot server configuration
- Auto[X]NBI (such as AutoCasperNBI or AutoImagrNBI)
- Editing XML files (or OS X plist files)
I’m also assuming you’ve got a fully working Mac OS X server setup and running.
I will often be using “Repo” as shorthand for “Repository” throughout this series.
Right, lets start at the beginning, where can you go to find out information regarding Imagr (other than this blog!).
Fire up a web-browser and navigate to https://github.com/grahamgilbert/imagr
This will show the main project page for Imagr as well as some general information.
Switch to the Wiki page (https://github.com/grahamgilbert/imagr/wiki) to get a ton more information direct from the developers.
Finally, there are two mailing lists where you can ask questions of the developers and other users:
And don’t forget the Mac Admins Slack channel #imagr (accessible via http://macadmins.org)
Configuring the NetBoot Service
Anyone who has seen my previous set of blogs on DeployStudio (specifically this one – Steps 1 – 9) will have seen this before. For completions sake, it’s a clone of that section, so if you’ve already setup your NetBoot service, you can skip this section.
1. On your Mac server, open up your Server.app either from the Dock or from the Applications folder.
2. The NetInstall service is under the “Advanced” section of the Server.app. Click the “Show” label next to the section to show these.
3. Once expanded, click the “NetInstall” service. This is where you can configure NetInstall and NetBoot images and was previously called the “NetBoot” service.
4. The next step is to configure the storage location for both the NetBoot / NetInstall images, and the cache data that clients will write and read whilst the internal Hard Drives are imaging. Click the “Edit Storage Settings…” button.
5. You will see a dropdown window appear, showing a list of connected volumes that could be used. I would highly recommend keeping both the image and client data off the server boot drive; as these can grow large, as well as requiring a lot of I/O that may slow the server down, therefore affecting the imaging speed. I would also recommend using a faster internal drive, or an external hard drive connected over Thunderbolt. This will ensure the fastest possible speeds for imaging.
In this example, I’ll be using the “Data HD” drive. Click the drop down menu next to this and select “Images & Client Data”.
6. Once done, click “OK”.
7. You’ll not see any change in the main NetInstall window, however on your chosen storage volume, two new directories will be created:
- “/Volumes/Data HD/Library/NetBoot/NetBootClients0”
- “/Volumes/Data HD/Library/NetBoot/NetBootSP0”
8. The “NetBootClients0” directory is where a client device’s cache data is stored and will usually look after itself without any maintenance.
9. The “NetBootSP0” directory is where the NetBoot / NetInstall images should be copied (the entire “.nbi” folder).
And that’s it for now. You have setup the core of your NetBoot service. Not a massive task but a start.
Next time, we look at configuring the web service to host your Imagr files
As always, if you have any questions, queries or comments, let us know below and I’ll try to respond to and delve into as many as I can. I’m especially eager to hear any feedback on this new series.
While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. Amsys will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.