@peternbevan You can actually accomplish this without a manifest file. You do not need to create a custom manifest, your package just needs to be built as a distribution package. If you are unfamiliar with distribution packages, or with packaging in general, may I suggest this fine book from @arminBriegel - Packaging for Apple Administrators.
I use a folder structure with a build script for doing my packaging. As part of the workflow I create a package, convert the package to a distribution package, and then sign the package:
#!/bin/bash
args=("$@")
pkgName="${args[0]}"
echo "Supply the package name and version: build.sh <pkgname> <version>"
# get date for package name
myDate=`date +%Y%m%d`
# Name of the package.
NAME="${pkgName}"
# Once installed the identifier is used as the filename for a receipt files in /var/db/receipts/.
IDENTIFIER="com.yourcompany.$NAME"
# Package version number.
VERSION="${args[1]}"
# Remove any unwanted .DS_Store files.
find ROOT/ -name '*.DS_Store' -type f -delete
find scripts/ -name '*.DS_Store' -type f -delete
# Build package.
/usr/bin/pkgbuild
--root ROOT/
--scripts scripts/
--identifier "$IDENTIFIER"
--version "$VERSION"
"Output/$NAME-$VERSION-$myDate.pkg"
# Build Distribution Package
/usr/bin/productbuild
--package "Output/$NAME-$VERSION-$myDate.pkg"
"Output/$NAME-$VERSION-$myDate-dist.pkg"
productsign --sign '<yourdevelopercertname>' "Output/$NAME-$VERSION-$myDate-dist.pkg" "Output/$NAME-$VERSION-$myDate-dist-signed.pkg"Folder structure:
Place your folder structure in the ROOT folder, any pre or post scripts in the scripts folder, and then run the Build.sh script (contents above) with something like: /path/to/build/template/Build.sh <packagename> <version>. If you keep the package signing bit in you will be prompted for credentials. That will output a file like: packagename-version-date-dist-signed.pkg along with 2 other packages. I'm lazy and haven't added the bits to clean out the other 2 package files.
For example, if I wanted to package Jamf Connect for distribution during PreStage (which I do), the folder structure might look like this:
Placing any logos I need for Jamf Connect, or anything else, in the logos folder. Obviously adjust that folder path to wherever you might store your company logos and such.
The postinstall script simply calls the Jamf Connect installer:
#!/bin/zsh
TMP_PATH=/tmp
LOGIN_FILENAME=JamfConnect.pkg
installer -pkg "$TMP_PATH"/"$LOGIN_FILENAME" -target $3
/usr/local/bin/authchanger -reset -JamfConnect -Notify
exit 0And I'd call that by changing into that folder in Terminal and running:
./Build.sh JamfConnect 2.1.2
And the output would look like this:
Again, I'm lazy and haven't re-written the script to get rid of the .pkg and -dist.pkg files.
As far as DEPNotify we use it quite heavily for provisioning and we also use it for longer Self Service installs, like installing an entire set of Adobe products. It just gives us a nice way of providing feedback to the end user.
IMO, the "DEPNotify-Starter" script should be used as a template, or as a proof of concept for how it can work. The script is way more complicated than it needs to be for basic provisioning. I would suggest you grab DEPNotify, run it on your machine locally, and throw text into the depnotify.log file so that you can see in real time what is going on. once you've figured out how it works and what you want, then build your own script to trigger.
Because our organization is quite large and quite complicated (over 300 different business units) we had to get very tricky with our provisioning. Currently our team provisions for over 100 different business units and each business unit might have up to 4 different builds that are snowflakes from the other business units. So we potentially have 400 different builds (it's not that high but you get the picture). Because of that I had to write a custom Python script that uses a JSON file as a data file containing all of the permutations of our builds.
We were originally using cocoaDialog to ask for some key information from the techs that were building computers (country, city, agency, building, email, asset tag) because we utilize that information to build the computer name and to determine which build. We are in the process of converting this over to use the Okta information (gleaned from Jamf Connect on first login) for the user and then only asking for things we do not have using the Register function of DEPNotify.
My point being, look at the DEPNotify-Starter script, pick out the pieces that you might want to re-use (the policy loop to install policies from a trigger array is one that I highly suggest grabbing), play around with DEPNotify on your machine, and then go experiment with your own provisioning scripts.
Just my 2 pennies...
