Update CHANGELOG.md

Add option to prompt user and finally kill

CHANGELOG.md

@@ -0,0 +1,28 @@
+## v0.4 - 2020-10-19
+
+- you can now set script variables as an argument in the form `VARIABLE=value`. More detail on this in the README file, 'Configuration from Arguments.' (#26, #50, #72, and #73)
+- change `downloadFromGit` to match file types better (#58)
+- implemented a workaround for changed behavior of `xpath` in Big Sur (#80)
+- added an option `prompt_user_the_kill` to `BLOCKING_PROCESS_ACTION` which will kill the process after the third unsuccessful attempt to quit (#78, thanks Patrick Atoon @raptor399)
+- added several new labels for total of 116
+
+
+## v0.3 - 2020-07-23
+
+- added several new labels for total of 98
+- removed the powershell labels, since the installer is not notarized
+- when run without any arguments, the script now lists all labels
+- changed how zips are expanded because this was broken on Mojave
+- improved logging in some statements
+- several more minor improvements
+
+## v0.2 - 2020-06-09
+
+- many fixes for broken URLs and other bugs
+- the `pkgInDmg` and `pkgInZip` now search for a pkg file in the archive in case the file name varies with the version
+- notification on successful installation can be suppressed with the `NOTIFY` variable
+- Apple signed installers and apps that don’t have a Team ID are verified correctly now
+improved logging
+- several new applications: count increased from 62 in 0.1 to 87 in 0.2
+
+## v0.1 - 2020-05-12

LICENSE

@@ -186,7 +186,7 @@
       same "printed page" as the copyright notice for easier
       identification within third-party archives.
 
-   Copyright 2018 Armin Briegel, Scripting OS X
+   Copyright 2020 Armin Briegel, Scripting OS X
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.

Labels.txt

@@ -1,25 +1,58 @@
 1password7
+8x8
+adobereaderdc
+adobereaderdc-install
+adobereaderdc-update
+airserver
+alfred
+amazonworkspaces
+apparency
+appcleaner
+aquaskk
 atom
+autodmg
+autopkgr
 aviatrix
 bbedit
+bettertouchtool
+boxdrive
+brave
+camtasia
 citrixworkspace
+code42
 coderunner
 cyberduck
 depnotify
 desktoppr
+detectxswift
+dialpad
 discord
+docker
 dropbox
+egnyte
 eraseinstall
 firefox
+firefoxesrpkg
+firefoxpkg
 githubdesktop
 googlechrome
 googlechromepkg
 googledrivefilestream
+googlejapaneseinput
 grandperspective
 handbrake
+icons
+istatmenus
 iterm2
+jamfmigrator
+jamfpppcutility
+jamfreenroller
+karabinerelements
+keepassxc
+krisp
 malwarebytes
 microsoftautoupdate
+microsoftcompanyportal
 microsoftdefenderatp
 microsoftedgeconsumerstable
 microsoftedgeenterprisestable
@@ -30,29 +63,54 @@ microsoftonedrive
 microsoftonenote
 microsoftoutlook
 microsoftpowerpoint
+microsoftremotedesktop
 microsoftsharepointplugin
+microsoftskypeforbusiness
+microsoftteams
 microsoftword
 netnewswire
+nomad
 omnifocus3
 omnigraffle7
 openvpnconnect
 pacifist
 plisteditpro
+postman
 privileges
+r
 resiliosynchome
+ringcentralapp
+ringcentralmeetings
 royaltsx
+santa
+sfsymbols
+signal
+sizeup
+skitch
 slack
+snagit2020
 sonos
+sonoss1
+sonoss2
 sourcetree
 spotify
+sublimetext
 suspiciouspackage
+swiftruntimeforcommandlinetools
 teamviewer
 textmate
 things
+torbrowser
 tunnelbear
+tunnelblick
+umbrellaroamingclient
+virtualbox
 visualstudiocode
 vlc
+vscodium
 webexmeetings
 webexteams
 whatsapp
+wwdcformac
+yubikeymanagerqt
 zoom

README.md

@@ -4,6 +4,27 @@ _The one installer script to rule them all._
 
 ![](https://img.shields.io/github/v/release/scriptingosx/Installomator) ![](https://img.shields.io/github/downloads/scriptingosx/Installomator/latest/total) ![](https://img.shields.io/badge/macOS-10.14%2B-success) ![](https://img.shields.io/github/license/scriptingosx/Installomator)
 
+This script is in the "we find it useful, it is working for us" stage.
+
+Your production and deployment environment will be different, please test thoroughly before rolling it out to your production.
+
+I have put a lot of work into making it stable and safe, but I cannot - of course - make _any_ promises that it won't break in some not yet encountered edge case.
+
+## Support and Contributing
+
+Discussion, support and advice around Installomator happens in the `#installomator` channel in the [MacAdmins Slack](https:/macadmins.org). Go there for support questions.
+
+Do not create an issue just when you have a questions, but do file an issue or pull request for bugs or wrong behavior. When in doubt, ask in the above Slack channel.
+
+If you have added a new label, then please file a pull request. (and Thank you!)
+
+## More reading
+
+There are a few interesting post on Installomator on my weblog:
+
+- [Introducing Installomator](https://scriptingosx.com/2020/05/introducing-installomator/)
+- [Using Installomator with Jamf Pro](https://scriptingosx.com/2020/06/using-installomator-with-jamf-pro/) by Mischa van der Bent
+
 ## Background
 
 As a system engineer at [an Apple Authorized Enterprise Reseller](https://prowarehouse.nl), we manage a lot of Jamf instances.
@@ -12,23 +33,30 @@ Some of these instances are tightly managed, i.e. the versions of the operating
 
 Installomator was _not_ written for these kinds of deployment.
 
-If you are running this kind of deployment, you want [AutoPkg](https://github.com/autopkg/autopkg).
+If you are running this kind of deployment, you want to use [AutoPkg](https://github.com/autopkg/autopkg) and you can stop reading here.
 
 There are other kinds of deployments, though. In these deployments the management system is merely used to "get the user ready" as quickly as possible when they set up a new machine, and to offer software from a self service portal. In these deployments, system and software installations are 'latest version available' and updates are user driven (though we do want to nag them).
 
-These are mostly 'user controlled' Macs and we mostly just want to assist the user in doing the right thing. And the right thing is (often) to install the latest versions and updates when they are available.
+These deployments are
 
-The Mac App Store and software pushed through the Mac App Store follow this approach. When you manage software through the App Store — whether it is on iOS or macOS — neither the MacAdmin nor the user get a choice of the application version. They will get the latest version.
+- user driven
+- low control
+- minimal maintenance effort
 
-In such deployments, keeping the installers hosted in your management system up to date is an extra burden that often feels unnecessary. Instead of downloading, re-packaging, uploading application installers to the management system, it is often easier to run a script which downloads the latest version directly from the vendor's servers and installs it.
+These are mostly 'user controlled' Macs and we (the admins) just want to assist the user in doing the right thing. And the right thing is (often) to install the latest versions and updates when they are available.
+
+The Mac App Store and software pushed through the Mac App Store follow this approach. When you manage and deploy software through the App Store — whether it is on iOS or macOS — neither the MacAdmin nor the user get a choice of the application version. They will get the latest version.
+
+In such deployments, keeping the installers hosted in your management system up to date is an extra burden. AutoPkg can, well, automate much of the download/re-package/upload/stage cycle, but it still requires oversight and maintenance. Instead of downloading, re-packaging, uploading application installers to the management system, it is often easier to run a script which downloads the latest version directly from the vendor's servers and installs it.
 
 There are obviously a few downsides to this approach:
 
 - when your fleet is mostly on site and many will install or update at the same time, they will reach out over the internet to the vendor's servers, possibly overwhelming your internet connection
 - when you download software from the internet, it should be verified to avoid man-in-the-middle or other injection attacks
-- there is no control over which version the clients get
+- there is no control over which version the clients get, you cannot "hold back" new versions for testing and approval workflows
+- some application downloads are gated behind logins or paywalls and cannot be automated this way
 
-Some of these disadvantages can be seen as advantages in different setups. When your fleet is mostly mobile and offsite, then downloading from vendor servers will relieve the inbound connection to your management server, or the data usage on your cloud server. Software vendors are pushing for subscriptions with continuous updates and feature releases, so moving the entire team to the latest versions quickly can make those available quickly. Also being on the latest release includes all current security patches.
+Some of these disadvantages can be seen as advantages in different setups. When your fleet is mostly mobile and offsite, then downloading from vendor servers will relieve the inbound connection to your management server, or the data usage on your management system's cloud server. Software vendors are pushing for subscriptions with continuous updates and feature releases, so moving the entire team to the latest versions quickly can make those available quickly. Also being on the latest release includes all current security patches.
 
 Because this is an attractive solution for _certain kinds_ of deployment, there are already many scripts out there that will download and install the latest version of a given software. And we have built and used quite a few in-house, as well. Most importantly, [William Smith has this script](https://gist.github.com/talkingmoose/a16ca849416ce5ce89316bacd75fc91a) which can be used to install several different Microsoft applications and bundles, because Microsoft has a nice unified URL scheme.
 
@@ -58,7 +86,7 @@ Installomator can work with the following common archive and installer types:
 
 When the download yields a pkg file, Installomator will run `installer` to install it on the current system. 
 
-Applications in dmgs or zips will be copied to `/Applications` and their owner will be set to the current user, so the install works like a standard drag'b drop installation.
+Applications in dmgs or zips will be copied to `/Applications` and their owner will be set to the current user, so the install works like a standard drag'n drop installation.
 
 (I consider it a disgrace, that Jamf, after nearly 20 years, _still_ cannot deal with 'drag'n drop installation dmgs' natively. It's not _that_ hard.)
 
@@ -83,12 +111,12 @@ There is a debug mode and one other setting that can be controlled with variable
 As of this writing, Installomator knows how to download and install more than 50 different applications. You can add more by adding a block to the _long_ `case` statement starting on line 160. Some of them are more elaborate, but most of them just need this information:
 
 ```
-    googlechrome)
-        name="Google Chrome"
-        type="dmg"
-        downloadURL="https://dl.google.com/chrome/mac/stable/GGRO/googlechrome.dmg"
-        expectedTeamID="EQHXZ8M8AV"
-        ;;
+googlechrome)
+    name="Google Chrome"
+    type="dmg"
+    downloadURL="https://dl.google.com/chrome/mac/stable/GGRO/googlechrome.dmg"
+    expectedTeamID="EQHXZ8M8AV"
+    ;;
 ```
 
 When you know how to extract these pieces of information from the application and/or download, then you can add an application to Installomator.
@@ -128,7 +156,7 @@ Other than the version arguments, the argument can be any of the labels listed i
 
 ### Debug mode
 
-There is a variable named `DEBUG` which is set in line 21 of the script. When `DEBUG` is set to `1` (default) no actions that wousld actually modify the current system are taken. This is useful for testing most of the actions in the script, but obviously not all of them.
+There is a variable named `DEBUG` which is set in line 21 of the script. When `DEBUG` is set to `1` (default) no actions that would actually modify the current system are taken. This is useful for testing most of the actions in the script, but obviously not all of them.
 
 Also when the `DEBUG` variable is `1`, downloaded archives and extracted files will be written to the script's directory, rather than a temporary directory, which can make debugging easier.
 
@@ -138,6 +166,8 @@ _Always remember_ to change the `DEBUG` variable to `0` when deploying.
 
 In Jamf Pro, create a new 'Script' and paste the contents of `Installomator.sh` into the 'Script Contents' area. Under 'Options' you can change the parameter label for argument 4 to 'Application Label.'
 
+Remember to set `DEBUG` to `0`.
+
 Then you can use the Installomator script in a policy and choose the application to install by setting the label for argument 4.
 
 ## What it does
@@ -180,6 +210,14 @@ There are four options:
 
 The default is `prompt_user`.
 
+### Notification
+
+The `NOTIFY` variable controls the notifications shown to the user. As of now, there are two options: `success` (default) and `silent`.
+
+- `success`:   notify the user after a successful install
+- `silent`:    no notifications
+
+
 ### Adding applications/label blocks
 
 #### Required Variables
@@ -187,12 +225,12 @@ The default is `prompt_user`.
 The script requires four pieces of information to download and install an application:
 
 ```
-    spotify)
-        name="Spotify"
-        type="dmg"
-        downloadURL="https://download.scdn.co/Spotify.dmg"
-        expectedTeamID="2FNC3A47ZF"
-        ;;
+spotify)
+    name="Spotify"
+    type="dmg"
+    downloadURL="https://download.scdn.co/Spotify.dmg"
+    expectedTeamID="2FNC3A47ZF"
+    ;;
 ```
 
 The four required variables are
@@ -220,7 +258,7 @@ The 10-character Developer Team ID with which the application or pkg is signed a
    - Applications (in dmgs or zips)
      `spctl -a -vv /Applications/BBEdit.app`
 
-   - Pkgs
+   - Installation Packages (pkg)
      `spctl -a -vv -t install ~/Downloads/desktoppr-0.2.pkg`
 
 
@@ -267,4 +305,72 @@ Depending on the application or pkg there are a few more variables you can or ne
 - `updateToolRunAsCurrentUser`:
   When this variable is set (any value), `$updateTool` will be run as the current user. Default is unset and 
 
+### Configuration from Arguments
+
+You can provide a configuration variable, such as `DEBUG` or `NOTIFY` as an argument in the form `VAR=value`. For example:
+
+```
+./Installomator.sh desktoppr DEBUG=0 NOTIFY=silent
+```
+
+Providing variables this way will override any variables set in the script.
+
+You can even provide _all_ the variables necessary for download and installation. Of course, without a label the argument parsing will fail, so I created a special label `valuesfromarguments` which only checks if the four required values are present:
+
+```
+./Installomator.sh name=desktoppr type=pkg downloadURL=https://github.com/scriptingosx/desktoppr/releases/download/v0.3/desktoppr-0.3.pkg expectedTeamID=JME5BW3F3R valuesfromarguments
+```
+
+The order of the variables and label is not relevant. But, when you provide more than one label, all but the _last_ label will be ignored.
+
+Providing all the variables this way might be useful for certain downloads that have a customized URL for each vendor/customer (like customized TeamView or Watchman Monitoring) or are local downloads.
+
+
+## Frequently Asked Questions
+
+### What if the latest version of the app is already installed?
+
+Short answer: Installomator will re-download and re-install the latest over the existing installation.
+
+Longer answer:
+
+Installomator will try to find a currently installed app to log the version. When Installomator finds an existing app (any version) and the `updateTool` variable is set, then Installomator will _not_ download and install, but run the `updateTool` instead.
+
+However, there is no simple generic method to actually determine the latest version of an application or installer.
+
+We deploy Installomator usually for user initiated installations from Self Service, so re-installs don't really 'hurt' and may be a useful troubleshooting step.
+
+When you want to have automated installations, you can use smart groups based on the app version to limit excessive re-installations.
+
+### Why don't you just use `autopkg install`?
+
+Short answer: `autopkg` is not designed or suited for this kind of workflow
+
+Long answer:
+
+The motivation to not re-invent the wheel and use and existing tool is understandable. However, `autopkg` was not designed with this use case in mind and has a few significant downsides.
+
+First, you would have to deploy and manage autopkg on all the clients. But to do its work, `autopkg` requires recipes. So, you have to install, and update the recipe repos on the client, as well. For security reasons, you _really_ should only run trusted recipes, so you need to install and update your personal recipe overrides as well.
+
+The recipes you use are probably spread across multiple community provided recipe-repos, so we have `autopkg` itself, several recipe-repos, and your overrides that we need to manage, each of which may need to be updated at any time.
+
+The community recipe-repos contain several recipes for different applications. When you add a recipe-repo for an app you want, you will also install all the other recipes from that repo.
+
+The `autopkg install` does _not_ require root or even administrative privileges. _Any_ user (even standard users) on the system can now install any of the random recipes that came with the community repos.
+
+To prevent users installing random apps from the community repos, you can curate your own recipe-repo from the community repos and push that to the clients. At this point, you are managing autopkg, your curated repo, your recipe overrides on the clients and handling the additional work of curating and updating your recipe-repo and the overrides.
+
+In addition, a really savvy user (or a malicious attacker) could build their own recipe and run it using the pre-installed `autopkg` you installed.
+
+And then consider what your CISO department (if you have one) would say about the `autopkgserver` and `autopkginstalld` daemons running on all the clients...
+
+At this point it would be easier to use AutoPkg the way it was intended: on a single admin Mac, and let it upload the pkgs to your management system, which deploys them. Each tool is doing what it is designed for.
+
+Please don't misunderstand this as me saying that AutoPkg is a bad or poorly designed tool. AutoPkg is amazing, powerful, and useful. The [Scripting OS X recipe-repo](https://github.com/autopkg/scriptingosx-recipes) is one of the older repos. AutoPkg is valuable tool to help admins with many apps that cannot be automated with tools like Installomator, and with deployment strategies that require more control.
+
+But it is not suited as a client install automation tool.
+
+### Why don't you just use brew?
+
+Read the explanation for `autopkg`, pretty much the same applies for `brew`, i.e. while it is useful on a single Mac, it is a un-manageable mess when you think about deploying and managing on a fleet of computers.