-
Notifications
You must be signed in to change notification settings - Fork 0
Glossary
- Jamf Pro
- Patch Management
- Title
- Version or Patch
- Patch Source
- Title Editor
- Requirements, Components, Capabilities
- version-script
- app-name and app-bundle-id
- Version Status
- standalone
- killapp
Below are some definitions of terms used throughout Xolo. The definitions are geared towards former users of d3, but are good to know for everyone. For folks familiar with Jamf pro, some of them are obvious.
The Apple Device Management service underlying xolo. Xolo is 'merely' an automation wrapper around Jamf Pro's patch-management system. A product of jamf.com
The awareness & reporting of software already installed on managed Macs, and the acquisition & deployment of updates to that software.
In Jamf's world, initial installation of software is a different thing, done via other parts of Jamf Pro, not the Patch Management System.
Xolo, like d3, manages both aspects: initial installs, and updates.
The same as 'basename' in d3, the name of a piece of deployed software, like 'filemaker' or 'google-chrome'
A specific version of a title. Titles can have many versions. The words 'version' and 'patch' are often used interchangeably, though xolo itself uses 'version'
Not exactly the same as a d3 'edition' as Jamf (and therefore Xolo) doesn't use 'revisions'. Since 'revisions' no longer exist, if you need to make changes to a .pkg for a version you can use xadm edit-version --pkg-to-upload to upload the changed package to an existing version. Xolo will automatically re-deploy it to all Macs with that version currently installed.
A service external to Jamf Pro which provides it with info about available titles and versions. All Jamf Pro instance can see the built-in Patch Source provided by jamf.com
(often called 'TEd' or 'ted' in Xolo code and docs)<br> A cloud-based Patch Source for custom, internally-developed titles, also provided by jamf.com
You may see these words in error messages from the Title Editor. Here's what they mean:
- Requirements: a set of criteria, defined in a title, which identify a computer that has any version of this title installed.
- Components: a set of criteria, defined in a version, which identify a computer that has this version of the title installed
- Capabilities: a set of criteria, defined for a version, which identify computers are capable of running, and thus installing, this version
A script that runs on managed Macs and reports the currently installed version of a title.
Required if the title doesn't install a .app that defines its version in its Info.plist
In Jamf Pro and the Title Editor, these are stored in 'Extension Attributes'
The name of a double-clickable .app, and the CFBundleIdentifier value from its Info.plist e.g. 'Google Chrome.app' and 'com.google.chrome'.
Used by the OS and Jamf Pro to determine which version of an app is installed on a Mac. Using these is preferable to using a version-script, when possible.
As a version spends time in Xolo, its status will change. Here are the statuses and a brief description of each.
When a version is first added to Xolo, it's considered to be 'in pilot'. Pilot versions are not yet approved for general deployment, but can be manually or automatically installed (i.e. 'piloted') on some machines for testing purposes.
The primary purpose of piloting is not to test the software being installed, but to test the deployent and installation process itself. It is very unwise to automate the release of newly added versions without at least a few pilot installs first.
Each version can be assigned one or more 'pilot-groups'. The version will automatically be installed or updated on group members as soon as the version is added (usually at the next 'checkin').
By default, new versions inherit the pilot groups of the previous version, but they don't have to, each version can have different pilot groups.
Even without a pilot group, any pilot version can be manually installed on a non-excluded Mac via MDM using xadm deploy (if the package type is correct) or via a policy by ssh'ing to the target machine, and running sudo xolo install title version
Once a package has been piloted and is ready for general deployment, it is released, making it available to the general population of Macs (all those not excluded). A title can have only one released version at a time.
The version will automatically be updated on all machines eligible as soon as the version is released (usually at the next 'checkin').
If a machine doesn't yet have the title installed, but is a member of the title's 'release-groups' then it will be automtically installed.
NOTE:
Xolo's concept of 'released' is different from that between Jamf Pro and its Patch Sources (like the Title Editor).
Whenever Jamf Pro becomes aware of a new version being available from a patch source, it may call that 'released', as in 'released from the publisher'.
However when that happens to a Xolo version, it's status in Xolo us 'pilot', until someone runsxadm release
A version that was once released, but has been superceded by a newer version of it's title being released.
Deprecated versions are still installable, and you can even re-release them (called 'rolling back') though that may be unwise depending on the software itself.
Deprecated versions will be automatically deleted after some period of time, by default 90 days after deprecation.
A version that is older than the currently released one for its title, but was never released itself.
Skipped versions will be automatically deleted within 24 hours, but while they exist, you can roll back to them.
A boolean value, which is true if the installer .pkg for a version can be installed on its own, and does not require an earlier version already be installed.
An application that cannot be running when the .pkg for a version is installed. Identified by both the app's name ('Google Chrome.app') and the app's bundle identifier ('com.google.chrome').
The equivalent of a "prohibiting process" in d3