I am a big fan of instaDMG.
During the two years that I have actually been working as a OSX admin I have used it countless of times and it is still a very important tool for me.
I have to say that the move that the community is taking to a more granular and less monolithic image deployment does make sense in alot of scenarios, but in our case being such a big university with tons of deployments I do not see the moment of moving away from a fully restored computer in just under 10mins.
Sometimes when I need to include some software or some new update to the current images I feel the struggle of needing to create a custom installer to accomplish a quite simple task. But this is one of the downsides of instaDMG itself, it can do just a handful of things but it does them well and fast. Other tools such as Munki (I’m a bit fan of this one too) or Puppet can do them, but it is nice to get a block copy when it comes to deployment.
For example when I have to install a new version of Google Earth into the image and we’d like to include the internet plug-in too. By default instaDMG handles the .app bundles with no pain but does not have a method to handle internet plugins. In this occasion is when a one liner pkgbuild come in handy for the hassle of building a custom .pkg that instaDMG would understand.
In my case, I download the desired version, put everything in place in my test machine and run:
1 2 3 4
Voila! a pkg that you can hash and put into your catalog with no pain :)
Hopefully for the next release of
pkgbuild Apple will include the option of specifying different destinations in one line and handle non-bundle folders and files, the same way that makepkginfo -file does in Munki, but meanwhile for this extra bits you can dive into The luggage