Refactor to support pre/post scripts for Installomator and PKG items

[gilburns]

This should not break existing workflows, but it will add the ability to have a pre or post script around an Installomator item or Pkg item.

A lot of code refactored to accomplish this. Mostly just needed to refactor the 'process_scripts' function to break it out, but thought the labels and pkgs might be cleaner doing the same. Some other general things related to random error messages also addressed.

Adding the new dictionary keys (PreInstall or PostInstall) to label or pkg items would all that is needed to implement the pre/post script. The Pre/Post items don't need a DisplayName key like standard Script items, as they take on the Display Name of the item they are associated with. (As currently implemented.) Other than that one difference, they use the same function to run as a standard Script item.

The new keys use would look something like this:

	<dict>
		<key>DisplayName</key>
		<string>DockUtil</string>
		<key>Label</key>
		<string>dockutil</string>
		<key>PostInstall</key>
		<dict>
			<key>MD5</key>
			<string>18c5008486c6575fd322adb1e955005e</string>
			<key>ScriptPath</key>
			<string>/Library/Management/Scripts/dockutil_post.sh</string>
		</dict>
		<key>PreInstall</key>
		<dict>
			<key>MD5</key>
			<string>11e9b38db2ce1fb65c1d25dedf2b10f6</string>
			<key>ScriptPath</key>
			<string>/Library/Management/Scripts/dockutil_pre.sh</string>
		</dict>
	</dict>

[BenStreet365]

I would find this useful for the Wait functionality too. If installing an application from another source, having Baseline finish off any final configuration parts would be great

[BigMacAdmin]

This is a big restructuring, and will definitely take me some time to review, digest, and test. I appreciate the time you put into this, and I'm onboard with the proposed ideas. The devil will be in the details.

I've been thinking about this concept since you made this PR, and some initial questions:

• What happens if a pre-install script fails? Do we still process the item?
• What happens if a post-install script fails? Do we report it as a failed item?
• Your example doesn't include any ScriptArguments are those supported in your PR? (I assume so, since you mentioned it's the same process_scripts function, but I haven't reviewed in detail enough to know.)
• Ben brings up an interesting idea to implement this for the WaitFor items as well. Any suggestions on how to implement that? Perhaps one big "post install" run after the entire WaitFor period is done, or do we process post-installs for WaitFor items as the items come in? That timing could be tricky.
• A recent Feature Request (which I'm intent on fulfilling) is to allow certain items to run more than one time, in case of failure. We should account for this in the restructuring, and will need to make decisions like "Does the pre-install run again as well?" Any thoughts?
• One concern I have with this PR is that the configuration file will be growing so complex, that tools like iMazing will become less useful. I'm not even certain if we can have arrays within arrays like this w/out requiring the user to create a plist. Have you modified a ProfileManifest to support this?

[gilburns]

The pre/post use the exact same function as the previous script items. So everything is the same for support. The only difference is the drop of the DisplayName key and it will instead pass the DisplayName key of the item it is connected to, followed by PreInstall or PostInstall.

As written, it will continue if a script fails, but just like other failures it will be added to the list and displayed at the end of the run. Existing logging methods should also be unchanged.

I do understand that this is a lot. But I think it adds flexibility that didn't exist and opens the door to use the script function in other ways.

I think refactoring the Installomator label and package functions also makes it possible to rethink the rigid order of things. Maybe it could be that things can be reorganized to allow for the admin to define the process order. Intermixing labels and packages and scripts, instead of the set order of all the labels, followed by all the packages etc.

[gilburns]

I'll take a look at the ProfileManifest and see if it can support it. But even if it doesn't, the use of the pre and post is entirely optional and existing configuration should not break the way it is designed.

[gilburns]

I'm not currently using the waitfor at all. But I don't see why it couldn't have the post install functionality added to it. The script refactoring would easily allow for this.

[gilburns]

Confirmed that iMazing Profile Editor can support dictionary sub-keys like the proposed changes would require.

Locally edited file for testing:

Clicking the 'Choose Plist file' then will import the dictionary keys for that item. In the screenshot, I already imported a PreInstall plist.

That plist file looked like this:

<?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>MD5</key>
	<string>1234567890</string>
	<key>ScriptPath</key>
	<string>https://example.com/my_preinstall.sh</string>
</dict>
</plist>

The resulting mobileconfig created by iMazing Profile Editor looks correct and matches up to what is expected in the modified script for this PR.

[gilburns]

The modification to the iMazing Profile Editor PFM file would simply be two extra keys added to both Installomator and Packages keys: