Posted 2020 April 18
One of the reasons I got involved with the AutoPkg project early on was because I was using DeployStudio as my core deployment tool, which was built around images and package installers. Since Munki users didn’t need to turn drag-and-drop apps into packages to deploy them, a number of products lacked pkg recipes. So I started filling the gaps for the products I used. As I wrote these pkg recipes, I realized that I could have AutoPkg copy these packages directly to the Packages folder of the DeployStudio repository, automating even more of my work. Thus, the .ds recipe type was born. That was 2014.
#RIPDeployStudio
Almost 6 years later, almost all Mac admins have abandoned DeployStudio for deployment in favour of more installation-centric tools.[1] I am one of those abandoners, so I started thinking about retiring — or at least deprecating — my .ds recipes. I concluded that, although DeployStudio is dead, the .ds recipe family had two modern uses, so this week I cleaned up all my .ds recipes and related documentation to reflect that.
Since .ds recipes are, at their core, a simple copy step at the end of a pkg recipe (stripping version info from the filename where applicable), one can still use these recipes to maintain a local repository of the latest version of the software you deploy. Because I’ve had this set up for a long time now, I still find ways to use it, even as we delegate most of our deployment to the management system we are now using. Mostly, this is where I go when I want to find the latest version for testing or uploading to the management system, or when I need to use Apple Remote Desktop to do an emergency install.
Long Live (M)DS
But there is one other use that I think has a broader appeal. My current workflow for (re-)deploying our Lab computers involves using MDS to install macOS plus a few minor apps and drivers, then have the management system do the rest. So I wondered if the current version of MDS would support the same kind of methodology I used for DeployStudio. That is, can I make certain that MDS always has the latest version of the packages I want it to deploy? Here’s what I found.
In MDS, when you request a Save to Volume…, MDS parses the folders you specified in your workflows in order to make any adjustments or additions it needs to create what MDS needs on the target volume. In this case, we’re interested in the contents of any Package & Apps Folders we specify. For every pkg in such a folder, MDS will do one of two things: if it is a distribution pkg, it will copy it directly to the target volume; if it is not, it will convert it to a distribution pkg[2], stow the original safely in a uniquely-named subdirectory, then copy the distribution pkg to the target volume.
Because it does this check every time you Save To Volume, using .ds recipes to populate/update the contents of a folder you use in an MDS workflow will work just as well as it did for the Packages folder in a DeployStudio repository. It doesn’t matter if your AutoPkg recipe generates a distribution package or not, since MDS will correct for it each time you Save To Volume.
The caveats:
- You need to be using MDS 2.0 or later (I tested this on 2.1 and 2.2 beta).
- Not every pkg installer works with MDS, even after a conversion — that is the case for AutoDMG as well — but some common packages that didn’t work in 1.x seem to be working for people in 2.x, so don’t be afraid to test or re-test.
- The .ds recipes are destructive by design. Unless you have a backup (or have old packages hanging around the AutoPkg Cache), you can’t revert to the previous package once AutoPkg copies the (new) package over.
I rename my overrides with a suffix of .mds, but I do not intend to adopt that suffix in the recipes themselves. You can use my updated template to write your own recipes or you can use Recipe Robot.
So there is some life left in those .ds recipes after all. But now I think “Deploy Stick” when I see that suffix.
[1] To be fair, DeployStudio was underrated for its ability as an installation tool (as opposed to an imaging tool) for (re-)deployment. My final use of DeployStudio was a workflow where I had MDS install the OS and a few minor things, then ran a DeployStudio workflow that set settings, ran scripts, and installed over 40 packages. No system image was ever copied. [Return to main text]
[2] MDS will prompt you in the GUI that it is going to make this conversion. You can suppress that notification with a preference in that dialogue box. Tim Perfitt wrote more about how MDS does the conversion in a post on the MacAdmins Slack earlier this year. [Return to main text]