Posted on 11th February 2016 by Darren Wallace

Imagr 101: Use Cases and Advanced Options

Hi All, and welcome back to the final (for now) part on configuring Imagr. This time, I’ve taken a brief look at some specific use cases and some more advanced options to consider.

 

Use Case: Casper Enrolment Workflow

I am aware of some Casper Mac Administrators that utilise DeployStudio to image and enrol their Mac devices into Casper.

As part of its intention as a DeployStudio replacement, Imagr is perfectly sorted to replace this solution.

I’d recommend grabbing a Quick Add package for your Casper solution, and use the below workflow settings:

  1. Computer Name task
  2. Image task – deploying your clean, unbooted OS image
  3. Package task – Installing your Quick Add package, and set with the ‘first boot’ option enabled.

This should laydown a clean OS, name the device as required, then run the Quick Add package, enrolling the device into your Casper solution.

 

Use Case: Munki Enrolment and Bootstrap Workflow

A fair few Munki Administrators do use DeployStudio to ‘enrol’ their devices into Munki (by installing the Munki tools, and configuring the client plist file) and set off the Munki bootstrap process.

Again, Imagr is perfect to replace DeployStudio in this role.

I’d recommend packaging up your initial Munki configuration plist file from the client device (typically located at ‘/Library/Preferences/ManagedInstalls.plist’, but sometimes at ‘/private/var/root/Library/Preferences/ManagedInstalls.plist’) and use the below workflow settings for this example:

  1. Computer Name task
  2. Image task – deploying your clean, unbooted OS image
  3. Package task – Installing the Munki Tools packages.
  4. Package task – Install the Munki configuration plist file package
  5. Script task – Run a script to `touch` the Munki bootstrap file. Alternatively, package this file up and replace this task with a ‘Package’ task. Another alternative is a community provided script task to set the bootstrap file, which can be found here.

This should lay down a clean OS, name the device as required, then run the three Munki packages (the tools, the configuration file and the bootstrap file) causing the device to check in and run the installations as configured in your Munki Repo.

 

Use Case: Clean Install

(Credit to Ben Toms for this one)

One issue with using Casper Imaging to deploy a Mac is that they will always get the local Casper tools installed. Sometimes you’ll want to wipe and deploy a clean OS quickly, but without any local management tools. An example would be to prepare a Mac for resale outside of the company / institute.

The workflow for this could (simply) be:

  1. Image task – deploying your clean, unbooted OS image

 

Advanced Options: Multiple Workflows

Imagr supports the use of multiple workflows that the technician can select, dependant on the specific needs of the device they are working with.

This is achieved by adding a second (or more!) dictionary items, into the workflows array.

Before:

Imagr 101 blog - part 5 - blog pic 1

 

After:

Imagr 101 blog - part 5 - blog pic 2

 

This second workflow will then show up in the dropdown menu of the Imagr local application.

 

Advanced Options: Included Workflows

Imagr also supports the use of included workflows (the ability to call other workflows as part of the selected workflow).

A use case for this maybe to have a main workflow that will deploy an OS and install the Munki tools, and then use a further workflow per Munki manifest that calls the first workflow, and then installs a custom Munki configuration plist file package.

These workflows are called by the name of the workflow so ensure not to change any names without checking any included workflow tasks. Also, there is no loop checking (e.g. it is possible to have ‘workflow A’ call ‘workflow B’, that then calls ‘workflow A’ again and loops until quit) so ensure to check the contents of any workflow that calls another.

This is simply a case of adding another workflow task called “included_workflow” with a key for the name of the workflow to call. An example of this can be found on the Imagr wiki at https://github.com/grahamgilbert/imagr/wiki/Workflow-Config#included-workflow

 

Advanced Options: Hidden Workflows

Imagr supports the ability to hide (but still run) workflows from the technician using the Imagr client application. This is useful when utilising the ‘Included Workflows’ option, but you don’t want a technician running the workflow outside of the specified workflows.

This requires the key ‘hidden’ to be added to the workflow with the value of true. This should be added in the same area as the name, description, workflow restart options etc. An example of this can be found on the Imagr wiki at https://github.com/grahamgilbert/imagr/wiki/Workflow-Config#hidden

 

Further Ideas

So you’ve got Imagr up and running and you’re happy with how it works. What now?

Well from my side of things, I’m a little unhappy with using Mac Servers for my deployment tasks. I’d much rather use something that can be virtualised, run off 10GB+ Ethernet and have hardware resources assigned easily and quickly.

There’s two areas you’d need to consider and investigate to meet these aims; NetBoot Image / Service and the Imagr Repo.

 

Further Ideas: NetBoot

Mac Admins are very lucky at the moment, as the open source community has created a solution that will allow a non-Apple NetBoot server.

Take a look (and maybe have a go) at BSDPy, an Apple NetBoot implementation in Python, thereby allowing the NetBoot solution to run on CentOS and virtualised!

If you’re not as confortable with this, you could also use JAMF’s free NetSUS appliance (running Ubuntu) to run the NetBoot service. Although supplied by JAMF, it does not have to be used to host a Casper NetBoot image, and so could be used to host your Imagr NetBoot Image!

 

Further Ideas: Imagr Repo

The Imagr Repo (much like the Munki Repo) is purely a web server that is hosting and serving files across HTTP / HTTPS. As a result, the choices of what to host this on are virtually endless.

Take a look at migrating your Repo to a Linux server running Apache or Nginx or even a Windows server running IIS.

 

Summary

There you go! I’ve given you some possible Imagr use-cases, advanced options as well as further ideas to try. Go out and play!

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.

The usual Disclaimer:

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.