In no particular order...

• Package Signing
  • Don't forget to Sign Your Apps!
• Pilot, Release, and Excluded Groups
  • Pilot Groups
  • Release Groups
  • Excluded Groups
• Releasing to all computers
• Self Service
• Freezing and Thawing
• MDM deployment
• Changelog
• JSON output
• Xolo Server API
• Uninstallation
• Expiration
• Automated Cleanup
• Improved Handling of Third Party Titles Coming in v2

The Xolo server can be configured to automatically sign .pkg files uploaded to it, unless it is already signed with a valid signature (by you or the publisher). Doing so will use the same keychain and identiry that it uses to sign the xolo-client-data.pkg.

NOTE: While it may seem insecure to allow the server to sign pkgs, consider:

• Users of xadm are authenticated and authorized to use the server (see 'admin_jamf_group' server config)
• You don't need to distribute your signing certificates to a wide group of individual developers.
• While you need to trust your xadm users not to upload a malicious pkg, this would be true even if you deployed the certs to them, so keeping the certs on the server is more secure.

If this feature is enabled folks using xadm do not need to sign their .pkgs. However...

While Xolo will sign your .pkg files, it cannot do anything with the contents of those packages.

If you are installing any apps or other executables that require signing, you probably need to sign them with an appropriate Application signing identity. Xolo will also not sign any embedded component packages. While signing component packages may not be totally necessary, it helps ensure secure package deployment.

[ ToC ]

Versions can be configured with one or more 'pilot-groups', Jamf computer groups that will automatically have the version installed as soon as you've created it, before you release it. You can use different groups for different versions.

By default, a new version will inherit the pilot groups from the previous verson.

This can be useful if you have multiple simultaneous branches of development for your software, and want to test them on different groups of Macs at the same time.

When a new version is added, and its status is pilot, the scope-target of the initial auto-install policy is set to the pilot group(s). For those with the title already installed, the scope targets of the patch policy is also set to the pilot group(s). Macs in these groups should get the new version at the next checkin.

The pilot groups only define which Macs will get the new version automatically and immediately. It can be manually installed for piloting on any Mac that isn't excluded, using either xadm deploy [title] [version] [computer ...] from your own Mac, or sudo xolo install [title] [version] on the desired Mac.

Release groups can be assigned per title.

When a version is released the scope-target of the initial auto-install policy is changed to the release group(s). Macs in these groups that do not already have the title installed should get it at the next checkin.

The release groups only affect the automatic initial installation of a title. All computers that are not excluded can have any version of any title manually installed, either via Self Service (if enabled for the title) or xadm deploy or sudo xolo install

Since this is available on all computers that are not excluded, if you need to limit where it can be installed, be sure to exclude them.

For those with the title already installed the release group doesn't matter. The scope targets of the patch policy is also set to all computers, meaning all computers with an older version installed will get the update. Macs running newer, pilot versions should be unaffected. This happens regardless of the release groups.

Excluded groups can be assigned per title.

Computers in these groups will never have any version of the title installed via the Xolo-maintained policies.

It will not be available for manual or self service installation.

In addition to the excluded groups defined per title, the Xolo server can be configured with a single group that is always excluded from everything in Xolo.

Computers that are 'frozen' for a title are also excluded from all policies related to the title (see below).

[ ToC ]

Some titles need to be deployed to all computers (that aren't otherwise excluded).

To do so, set the --release-groups to 'all'

HOWEVER...

The server can be configured to only allow a specified group of people to do this.

If so, and you try to set a title's --release-groups to "all" you'll get an error telling you to contact those folks, and explain why you think this title should be automatically installed on every managed Mac. That team can then, if they approve, set the release-groups to 'all'

NOTE: Items in Self Service are available to all except the excluded groups, and do not require approval.

[ ToC ]

Titles can be made to appear in Self Service using xadm, in a specific Category and with an icon.

When a title is configured to be in Self Service, only the currently-released version is availble. If no versions are released yet, it won't appear in Self Service.

It will be visible to all computers that are not excluded, so if you need to limit who can see it, be sure to exclude all who should not see it.

[ ToC ]

To 'freeze' a computer or computer group for a title, you use xadm freeze [title] and provide the names of the computers or groups.

Once frozen, whatever version they have currently installed will remain - all updates of the title will be ignored until they are 'thawed' for that title. This means if you freeze a computer that doesn't have the title installed yet, it will never get installed.

This is useful when one or more teams using your software need to be locked in to a specific version for some time, while you continue to develop, pilot, and release new versions to the rest of the organization.

[ ToC ]

If the .pkg uploaded for a version is a 'distribution package' (a.k.a. 'product archive'), then xadm (on your own machine) can be used to install it on any managed anywhere on the internet. See xadm help deploy. This uses Jamf Pro's ability to send the InstallEnterpriseApplication MDM command, to install the package.

Using xadm deploy is all about doing manual initial installs on machines that would not normally have a thing automatically installed. It means that instead of ssh'ing to the target computer and typing sudo xolo install [title] [version] you stay at your own machine and type xadm deploy [title] [version] [computer ...]

The MDM command to install the package will be queued up by Jamf Pro, and will happen whever the target computer comes online, anywhere in the world. This is useful when the target machine is not on the local network and you have no way to ssh into it.

Note: Any automatic installations will already happen anywhere on the internet, without the need for MDM deployment, be that initial installation via membership in pilot or release groups or updates on any machine with a title already installed

[ ToC ]

The Xolo server maintains a change log of all changes to a title and its versions. See xadm help changelog

[ ToC ]

When using xadm to display info, reports, or lists of any kind, use the --json global option to get formatted JSON output, rather than text for human eyes.

This can be useful when automating the use of xadm.

[ ToC ]

While xadm is the preferred way to interact with the Xolo server, all that interaction is done via an HTTPS API, by exchanging JSON data with specific endpoints on the server. Even though this has many similarities to a REST API, it wasn't developed with the standards of REST in mind, so we refrain from calling it that.

There may be times when you want to access the server using those endpoints yourself, rather than using xadm, for example, on a Continuous Integration node where you don't have ruby installed, and can't use xadm.

While doing so is not explicitly supported, the API documentation should help you do that if needed.

Since you'll be replicating some of what xadm does, feel free to look at the xolo-admin code, to see how it does its thing.

[ ToC ]

Jamf Pro sorta-mostly no longers supports un-installing the pkgs it installs via a policy action, scripts are recommended.

Xolo can be made to do so using Jamf-based scripts and a custom policy-trigger. There are two ways to do this:

• A hand-written script that will run on the client machine.

  It's up to you to do whatever is needed to remove the title. This is useful when the title has it's own uninstaller that gets installed with the title.

• Provide the title with one or more 'uninstall-ids'.

  These are package-identifiers in the OS's package DB, as shown in the output of pkgutil --pkgs.

  Xolo will use the identifiers to create a zsh script that uses pkgutil to identify and delete every file installed by the identified packages. Folders that have any contents after deleting the installed files, are not deleted, which might leave odd droppings.

  WARNING
  This is only recommended for very simple packages. Please test very carefully before using these scripts widely. Look at the script that is generated in Jamf Pro to see what it does.

In either case. the end result of the uninstall script should be that the title's app-name and app-bundle-id are no longer on the machine, or if the title uses a version-script, it returns no installed version.

NOTE: While uninstallation is required for a title to be 'expirable', for the most part, uninstall scripts are not needed. Please be sure it is needed before adding one.

[ ToC ]

Like its predecessor d3, Xolo can uninstall titles when they haven't been used in some period of time.

To enable expiration:

• Add an uninstall script to the title (see above)
• Set an expiration period (number of days of disuse) for the title with --expiration
• Set one or more paths to executables that must be used within the expiration period, with --expire-paths

Xolo's definition of 'usage' is based on the OS's kMDItemLastUsedDate which is the last time a thing was opened via LaunchServices (double-click, the 'open' command, a URL, etc). This might be problematic for folks who never quit Apps, so beware.

[ ToC ]

Every night, the xolo server automatically cleans up old versions like so:

• Delete any version that was skipped
  • Skipped means: never released, but older than the current release
  • This happens the night after any new release
• Delete any version that has been deprecated for more than some number of days
  • Deprecated means: was released, but now older than the current release
  • The exact number of days can be configured on the server, but defaults to 90
• Nag about old pilots
  • When a version has been in pilot for more than some number of days, monthly emails will be sent to the title's contact address asking someone to release it or delete it
  • The exact number of days can be configured on the server, but defaults to 180

As you can see from What Xolo Does, for each Title and Version, there are many objects kept in Jamf Pro: policies, packages, scripts, and more.

In order to avoid bogging down the Jamf server with excess cruft, please delete any versions, or entire titles, if the are not needed anymore.

[ ToC ]

While Xolo's primary aim is to help in-house software developers automate their workflows, it can also be used for any third-party titles - you just need to acquire or create an installer.pkg, and add the title and version to Xolo.

Eventually, our plan is to make such third-party titles even easier to use with Xolo.

While we don't yet know exactly how this will look, our ideas include:

• Integrating a tool like AutoPkg to automate the acquisition of .pkgs and creation of new versions in Xolo
• Making the xolo server respond to PatchSoftwareTitleUpdated webhook events from other Patch Sources defined in Jamf Pro, either Jamf's built-in one, or any other.
• Or a combination of the two
• Possible integration with Jamf's 'App Installers'. Since we don't currently use a cloud-instance of Jamf Pro, we have no way to properly dig into this. Perhaps some day.

[ ToC ]