mtan93/Installomator
1
0
Fork 0
mirror of https://github.com/mtan93/Installomator.git synced 2026-03-08 05:31:53 +00:00
Code Issues Packages Projects Releases Wiki Activity

added FAQ to ReadMe

Browse Source
This commit is contained in:
Armin Briegel
2020-05-15 11:51:44 +02:00
parent 7420292fec
commit 5c0cb98f69
1 changed files with 47 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
README.md
View File

@@ -283,4 +283,51 @@ 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
## Frequently Asked Questions
### What if the latest 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 and 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 should 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.