Thanks to all who participated in the Packaging Lab yesterday at MacTech Conference.
Copies of the slides are available here.
Some other (hopefully) helpful links:
The Luggage:
AutoPkg:
MunkiPkg:
A few days ago I made a simple tool for building packages available: munkipkg.
https://github.com/munki/munki-pkg
I got many comments and suggestions for additional features and all sorts of cool additions. Some have even been added to the tool already. But I would like to keep munkipkg a pretty simple, basic tool.
The Luggage (https://github.com/unixorn/luggage) has been around for a while; if munkipkg is too simple for your needs, please have look at that.
I also suggested to several people that if they had more complex needs than munkipkg could handle, it might make more sense to use autopkg, which supports very complex, customizable workflows.
I could tell by the awkward silence that my suggestion was confusing to some — that they had trouble grokking how to use autopkg to build packages “from scratch”, using files and scripts on the local disk.
So I created a GitHub repo demonstrating how to use autopkg in this manner. It’s here: https://github.com/gregneagle/autopkg-packaging-demo
munkipkg comes with three demo package projects. Two of the packages install files, the third is a “payload-free” package that simply runs a script when installed. The autopkg-packaging-demo duplicates these packages, but uses autopkg to build them instead of munkipkg.
(One could also imagine building these packages using either tool: the payload and scripts directories would be the same — in other words, you could have both a build-info.plist for munkipkg and a recipe for autopkg in the same package project directory.)
Assuming you have autopkg installed, you can `git clone` the repo, or download and expand the zip file, and run the autopkg recipes within.
I hope this clears up some confusion, and sparks some new ideas!
https://github.com/munki/munki-pkg
munkipkg is a simple tool for building packages in a consistent, repeatable manner from source files and scripts in a project directory.
Files, scripts, and metadata are stored in a way that is easy to track and manage using a version control system like git.
Another tool that solves a similar problem is Joe Block’s The Luggage (https://github.com/unixorn/luggage). If you are happily using The Luggage, you can probably safely ignore this tool.
Though this tool may eventually be added to the set of tools installed with the Munki command-line tools, it’s not currently tied to Munki and can be run completely standalone.
Learn more here.
…are available here.
…are available here.
Imagr requires a web server (or servers) to get its workflows, images to restore, and packages to install.
In an earlier post, I described setting up an existing DeployStudio NBI for Imagr testing.
If you are testing Imagr, or even better, hoping to help with its development, you’ll need to configure a test server.
You’ll need a web server, and a way to get some files on it. I just used my existing Munki repo web server. I created a new folder called “testing” and copied a few packages into it. (For first-boot install, Imagr currently supports only flat packages. For immediate install, bundle packages are OK if they are at the root of a disk image/.dmg file.).
Next, create a configuration plist. There’s an example here: https://github.com/grahamgilbert/imagr#the-configuration-plist. Here’s another:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>password</key>
<string>40e78b0d11c553be61645796fdb9438271a23ed8b4aadb253a9222c6e4c861e2dbc75139000b0709fc0c5ad66b0f2573e38a72a8f629e270e59530fc3159d8e4</string>
<key>workflows</key>
<array>
<dict>
<key>name</key>
<string>Munki Bootstrap</string>
<key>description</key>
<string>Installs the required pkgs to begin a Munki bootstrap on restart.</string>
<key>components</key>
<array>
<dict>
<key>type</key>
<string>package</string>
<key>url</key>
<string>http://munki/repo/testing/DA_adminaccount_1.5.pkg</string>
<key>pre_first_boot</key>
<true/>
</dict>
<dict>
<key>type</key>
<string>package</string>
<key>url</key>
<string>http://munki/repo/testing/DisableSetupAssistant.pkg</string>
<key>pre_first_boot</key>
<true/>
</dict>
<dict>
<key>type</key>
<string>package</string>
<key>url</key>
<string>http://munki/repo/testing/munkitools-2.2.4.2431.pkg</string>
<key>pre_first_boot</key>
<true/>
</dict>
<dict>
<key>type</key>
<string>package</string>
<key>url</key>
<string>http://munki/repo/testing/munki_kickstart.pkg</string>
<key>pre_first_boot</key>
<true/>
</dict>
</array>
</dict>
</array>
</dict>
</plist>
The password is a hash for “LETMEIN”; you can certainly generate your own as explained here: https://github.com/grahamgilbert/imagr#password
The various URLs point to the pkgs I copied into the testing folder in my Munki repo share. Adjust as needed.
I saved this plist in the same folder as the testing pkgs as “testing.plist”. (Boring, I know.)
Make sure you can open it in a web browser before you continue — in my case it’s available
at http://munki/repo/testing/testing.plist
We are now done with the server config.
Boot a test client into the DeployStudio NBI that was configured as in my earlier post.
Open the Terminal.app.
We need to tell Imagr how to find the configuration plist, so:
defaults write com.grahamgilbert.Imagr serverurl http://munki/repo/testing/testing.plist
Make sure you replace the URL with the actual URL to the config plist you created.
Now launch Imagr:
/private/var/tmp/DSNetworkRepository/testing/Imagr.app/Contents/MacOS/Imagr
And bask in your success (or grumble at your failure…)
The prolific Graham Gilbert is working on a new tool: https://github.com/grahamgilbert/imagr
Imagr is an application designed to be run from a NetInstall environment. It is able to restore a disk image and install packages on a target volume.
Though Graham claims it is not intended to be a replacement for DeployStudio, I think in time it could very well be exactly that, at least for many people/organizations.
Some exciting things about Imagr:
Graham has posted detailed instructions on how to build a NetBoot image that contains Imagr. But if you just want to take a look and play with the tool, and you have an existing DeployStudio NBI with Python support included, you can play with Imagr without needing to build a new NBI. More importantly, you can test new versions (or work on the code yourself and test new versions you build) without having to build a new NBI each time.
Managing OS X 