Update README.md

README.md

@@ -195,17 +195,13 @@ When the `DEBUG` variable is `1`, downloaded archives and extracted files will b
 
 When `DEBUG` variable is `2`, the temporary folder is created and downloaded and extracted files goes to that folder, as if not in DEBUG mode, but installation is still not done. On the other hand blocking processes are checked, the app is reopened if closed, and the user is notified.
 
-_Always remember_ to change the `DEBUG` variable to `0` when deploying. The installer PKG we provide has `DEBUG=0`.
-
-### Use Installomator with Jamf Pro
-
-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.'
+Debug mode 1 is useful to test the download and verification process without having to re-download and re-install an application or package on your system. Debug mode 2 is great for checking running processe and notifications.
 
-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.
+_Always remember_ to change the `DEBUG` variable to `0` when deploying. The installer PKG we provide has `DEBUG=0`.
 
+### Use Installomator with various MDM solutions
 
+In the wiki we have provided documentation on how Installomator is used in various MDM solution, like Jamf Pro, Mosyle, and Addigy.
 
 ## What it does
 
@@ -225,15 +221,7 @@ When it runs with a known label, the script will perform the following:
 
 ## Configuring the script
 
-As of now there are two settings that are meant to configured when deploying the script.
-
-### Debug mode
-
-The first is the `DEBUG` variable. When this is set to `1` the script will _not_ perform any changes to the current system. In other words, no application will be copied to the target directory and no `installer` command be performed.
-
-In addition, files will be downloaded and extracted to the Installomator project folder instead of a temporary directory and _not_ deleted when the script exits. Also archives will _not_ be re-downloaded when they already exist in the project folder. The repository's `.gitignore` file is set up to ignore the archive file extensions.
-
-Debug mode is useful to test the download and verification process without having to re-download and re-install an application or package on your system.
+We have several default settings for certain behavior and notifications inside the script, but these can be customized when calling the script.
 
 ### Blocking Process actions
 
@@ -292,119 +280,6 @@ The `REOPEN` can be used to prevent the reopening of a closed app
 - `yes`:   (default) app will be reopened if it was closed
 - `no`:    app not reopened
 
-### Adding applications/label blocks
-
-#### Required Variables
-
-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"
-    ;;
-```
-
-The four required variables are
-
-- `name`:
-The display name of the installed application without the `.app` extensions.
-
-- `type`:
-The type of installation. Possible values:
-     - `dmg`: application in disk image file (drag'n drop installation)
-     - `pkg`: flat pkg download
-     - `zip`: application in zip archive (`zip` extension)
-     - `tbz`: application in tbz archive (`tbz` extension)
-     - `pkgInDmg`: a pkg file inside a disk image
-     - `pkgInZip`: a pkg file inside a zip
-     - `appInDmgInZip`: an app in a dmg file that has been zip'ed
-
-- `downloadURL`:
-The URL from which to download the archive.
-The URL can be generated by a series of commands, for example when you need to parse an xml file for the latest URL. (See `bbedit`, `desktoppr`, or `omnigraffle` for examples.)
-Sometimes version differs between Intel and Apple Silicon versions. (See `brave`,  `obsidian`, `omnidisksweeper`, or `notion`).
-
-- `appNewVersion` (optional, but recommended):
-Version of the downloaded software.
-If given, it will be compared to installed version, to see if download is different.
-It does not check for newer or not, only different.
-Not always easy to figure out how to make this. Sometimes this is listed on the downloads page, sometimes in other places. And how can we isolate it in a genral manner? (See `abstract`, `bbedit`, `brave`, `desktoppr`, `googlechrome`, or `omnidisksweeper`).
-
-- `packageID` (optional, but recommended for pkgs without an app)
-This variable is for pkg bundle IDs. Very usefull if a pkg only install command line tools, or the like that does not install an app. (See label `desktoppr`, `golang`, `installomator_st`, `odrive`, or `teamviewerhost`).
-
-- `expectedTeamID`:
-The 10-character Developer Team ID with which the application or pkg is signed and notarized.
-
-  Obtain the team ID by running:
-
-   - Applications (in dmgs or zips)
-     `spctl -a -vv /Applications/BBEdit.app`
-
-   - Installation Packages (pkg)
-     `spctl -a -vv -t install ~/Downloads/desktoppr-0.2.pkg`
-
-
-#### Optional Variables
-
-Depending on the application or pkg there are a few more variables you can or need to set. Many of these are derived from the required variables, but may need to be set manually if those derived values do not work.
-
-- `archiveName`: (optional)
-  The name of the downloaded file.
-  When not given the `archiveName` is set to `$name.$type`
-
-- `appName`: (optional)
-  File name of the app bundle in the dmg to verify and copy (include the `.app`).
-  When not given, the `appName` is set to `$name.app`.
-  This is also the name of the app that will get reopned, if we closed any `blockingProcesses` (see further down)
-
-- `targetDir`: (optional)
-  dmg or zip:
-    Applications will be copied to this directory.
-    Default value is '`/Applications`' for dmg and zip installations.
-  pkg:
-    `targetDir` is used as the install-location. Default is '`/`'.
-
-- `blockingProcesses`: (optional)
-  Array of process names that will block the installation or update.
-  If no `blockingProcesses` array is given the default will be:
-    `blockingProcesses=( $name )`
-  When a package contains multiple applications, _all_ should be listed, e.g:
-    `blockingProcesses=( "Keynote" "Pages" "Numbers" )`
-  When a workflow has no blocking processes, use
-    `blockingProcesses=( NONE )`
-
-- `pkgName`: (optional, only used for `dmgInPkg` and `dmgInZip`)
-  File name of the pkg file _inside_ the dmg or zip.
-  When not given the pkgName is set to `$name.pkg`.
-
-- `updateTool`, `updateToolArguments`:
-  When Installomator detects an existing installation of the application,
-  and the `updateTool` variable is set then
-     `$updateTool $updateArguments`
-  Will be run instead of of downloading and installing a complete new version.
-  Use this when the `updateTool` does differential and optimized downloads.
-  e.g. `msupdate` (see various Microsoft installations).
-
-- `updateToolRunAsCurrentUser`:
-  When this variable is set (any value), `$updateTool` will be run as the current user. Default is unset and
-
-- `CLIInstaller`:
-- `CLIArguments`:
-  If the downloaded dmg is actually an installer that we can call using CLI, we can use these two variables for what to call.
-  We need to define `name` for the installed app (to be version checked), as well as `installerTool` for the installer app (if named differently that `name`. Installomator will add the path to the folder/disk image with the binary, and it will be called like this:
-     `$CLIInstaller $CLIArguments`
-  For most installations `CLIInstaller` should contain the `installerTool` for the CLI call (if it’s the same).
-  We can support a whole range of other software titles by implementing this.
-  See label adobecreativeclouddesktop.
-
-- `installerTool`:
-  Introduced as part of `CLIInstaller`. If the installer in the DMG or ZIP is named differently than the installed app, then this variable can be used to name the installer that should be located after mounting/expanding the downloaded archive.
-  See label adobecreativeclouddesktop
-
 ### Configuration from Arguments
 
 You can provide a configuration variable, such as `DEBUG` or `NOTIFY` as an argument in the form `VAR=value`. For example:
@@ -430,17 +305,13 @@ Providing all the variables this way might be useful for certain downloads that
 
 ### 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.
+Short answer: That depends on if labels will know what the latest version will be.
 
 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.
+- Labels without this will re-download and re-install the latest over the existing installation.
+- Labels with this info will only install the app if the version is different than the one installed.
+- Labels that can use update tool will use that for the update (if the version is different)
 
 ### Why don't you just use `autopkg install`?
 
@@ -470,7 +341,7 @@ Please don't misunderstand this as me saying that AutoPkg is a bad or poorly des
 
 But it is not suited as a client install automation tool.
 
-### Why don't you just use brew?
+### Why don't you just use brew or MacPorts?
 
 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.