Welcome - PixarAnimationStudios/xolo GitHub Wiki
Xolo is a software deployment and patch management system for macOS that enhances those features of Jamf Pro. It is a command-line wrapper around the manual web-app processes required to deploy, pilot, release, install, update, and report on software titles on Macs managed by Jamf Pro.
Xolo was created by Pixar Animation Studios primarily to allow in-house software developers to automatically deploy and manage their own products without needing awareness of, or direct access to, Jamf Pro or the Jamf Pro administrators. We also use it to deploy of 3rd party software.
Xolo adds these capabilities and more to Jamf Pro's :
- Management of titles and versions is scriptable and automatable, allowing developers and admins to integrate with CI/CD workflows.
- Simplifies and standardizes the complex, multistep manual process of managing titles and patches using the Title Editor and Jamf Patch Management web interfaces.
- Pre-release piloting of new versions, either manually, or automatically to specified groups
- Titles can be expired (auto-uninstalled) after a period of disuse, allowing license reclaimation
- Freezing computers to a specific version of a title
The first three points allow for the sane management of hundreds of titles, each containing many versions, sometimes added daily by automated build systems. Doing so by hand in the web interfaces would be untenable.
Xolo is the latest, renamed, version of 'd3', Pixar's original Jamf-based deployment and patch management tool. It has been rebuilt from the ground up to make full use of the Jamf Pro Patch Management system, and to work with cloud-based Jamf Pro instances, neither of which existed when d3 was first created.
The 'App Installers' feature of cloud-based Jamf Pro instances provides a way to deploy from a list of curated, pre-built software packages to managed Macs via MDM.
Xolo's primary aim is easy, automatable deployment and management of in-house software, and arbitrary 3rd party titles, without the need to access, or even be familiar with, Jamf Pro itself.
While Xolo can deploy appropriately-built packages via MDM, it primarily uses standard Jamf Pro policies and patch-policies.
Xolo works with both on-prem and cloud-based Jamf Pro instances.
Similiar to App Installers, Auto Update provides deployment and management from a larger list of curated, pre-built packages.
Also xolo on managed Macs is just a single straightforward zsh script, wrapping around the jamf policy command.
Xolo's initial release makes no attempt to automatically search and retrieve newly-available patches or updates from the internet. It works with packages you provide or create, be they in-house or 3rd party.
In version 2, we plan to implement this feature using:
- Non-xolo patch sources and the PatchSoftwareTitleUpdated webhook event
- Title Editor titles not managed by Xolo
- Titles from the Jamf App Catalog via the Jamf Pro Built-in Patch Source
- Titles from any other patch source
- A tool like AutoPkg
Nearly 40 years ago, Pixar's original NFS-based software deployment system for Unix workstations was called "depot". When it had outgrown itself, a replacement based on RPM packages was created and called "depot2", or "d2" for short. When Mac OS X arrived at Pixar in 2002, the Mac team adopted many of the Linux team's existing tools, including d2.
d2 was useful as far it went, but Macs aren't Linux, and d2 couldn't handle the installation of .pkg's, especially those requiring a reboot. To deal with those, Pixar's Mac team created PuppyTime! - a system that could install .pkgs from a server, and if they needed a reboot, would queue them to be installed at the next logout.
During logout installation, something had to be displayed on the screen, or the users would think the machine was crashed, and might force-reboot. So puppytime would display a slideshow of cute puppies to let the users know what was up, and placate their mood.
By 2008 the original developer of d2 had left, and d2's sustainability for the Macs was waning. Also, the world of Mac Sys Admins was changing to become what it is today. In 2009 the Pixar Mac team starting looking at third-party tools that might replace d2.
Nothing seemed to be an exact fit for our needs, but the Casper Suite from JAMF Software seemed promising, and offered other tools very similar to our own home-grown Mac infrastructure. We realized that with a little customization, Casper could provide the features we wanted. The first version of d3 was created in 2009-2010 to add those features.
The second version of d3, which utilized the newly-released Casper REST API, was presented at the 2012 JAMF Nation User Conference in Minneapolis. One of the first questions from the audience was "Is it open-sourced?", to which we had to say no.
Work then began on the third version of d3 with a goal of enhancing its features and refactoring the code-base for eventual open-source release. The first step towards that goal was the 2014 release of ruby-jss, a Ruby module which provides quick-and-easy access to the Jamf Pro REST APIs.
ruby-jss was created specifically as the API connection for d3, but has become useful in it's own right for all of our access to the API and is widely used by other Jamf Pro customers.
d3 itself took another 18 months before the first upload to Github.
In 2016, Jamf released its built-in Patch Management system for Jamf Pro. Jamf Patch soob became accessible via the API(s) and we started our first investigation into d3 version 4, to be built around Jamf Patch.
The underlying paradigms used by d3 and Jamf Patch are significantly different, so it quickly became obvious that this would be a complete re-write. Work sputtered on here and there, but d3 wasn't 'broken' so there was no rush to fix it.
Then in 2020 the world had this little 3+ year-long hiccup called Covid-19. Due to the need for complete WorkFromHome, we forked a local-only d3, and did some fast and drastic things to it to make it work in our new dispersed work-world. The version 4 rewrite was ignored.
By 2024 d3 was starting to show its age, espcially since Jamf Patch had matured, and there were now various unrelated Jamf features only available to cloud-bsed Jamf instances. It was time to really focus on the rewrite, and to spur us along, we gave it a new name: Xolo.
Xolo is made of three parts:
xadm is the command-line tool for managing titles and versions in Xolo. It provides:
- Adding, configuring, deleting, listing, searching of Software Titles and their versions
- Automated installation of new versions to limited 'pilot' groups before general release
- Automated installation to a wider group for general release
- Optional Self Service availability of the released version
- Manual installation of pilot, released, or deprecated versions via MDM
- Freezing computers or groups to specific versions of a title
- View the changelog for a Title and all of its versions
- Viewing patch reports for titles and versions
- All list, info, and report output is optionally available as JSON
- Most actions can take all parameters as --commandline-options, or via an interactive menu
- Administrative actions to query or control the xolo server
- Save a copy of the latest version of the
xolocommand, for deployment to managed macs. - And More!
xadm is written in ruby for use on macOS, and shares the core of its code with xoloserver. See Requirements below.
xadm only communicates with the Xolo Server via HTTPS, not with any other parts of the system.
xoloserver is the HTTPS server at the heart of Xolo. It provides:
- The interface between
xadmand the Jamf Title Editor and Jamf Pro - Local storage of configuration and metadata about titles and versions
- Authentication (via Jamf Pro account groups) for users of
xadmand xadm's server-admin commands. - Management of all xolo-related titles and patches in the Title Editor
- Management of all xolo-related objects In Jamf Pro.
- Policies, PatchPolicies, PatchSoftwareTitles, ComputerGroups, Scripts, ExtensionAttributes, etc
- A per-title changelog storing all changes to a title and any of its versions
- Automatic package signing, if desired
- Alerts via arbitrary command-line tool (e.g. a tool to send messages to a Slack Channel) or email
- Package uploads via the Jamf Pro API or an arbitrary command-line tool
- Automated cleanup of skipped and deprecated versions, nags about long-unreleased pilot versions.
xoloserver is written in ruby for use on macOS, and shares the core of its code with xadm. See Requirements below.
xolo is the command-line tool for working with Xolo titles and versions on managed macs. Fundamentally it is a wrapper around the 'jamf' binary, mostly running jamf policy -trigger ...
It can:
- Manually Install the currently released version of a title, or a specific version
- Uninstall a title, if the title is uninstallable
- Install any pending updates available via a patch policy
- List available titles, and installed titles
- Show detailed info about a title or a version
- Expire (uninstall) titles that haven't been used in a defined period of time
Initial installs are handled by regular policies, updates of already-installed titles are handled via patch policies
xolo is a single file written in zsh. A copy of it can be saved to disk using xadm and from there be deployed to all managed macs. Yes, since xolo titles are all just jamf policies under the hood, you can use Xolo to deploy xolo!
All parts of Xolo are built to run on macOS.
Since the purpose of Xolo is to build, deploy, and manage software for Macs, this makes some sense. The server needs to be able to run various package-related tools that are built into macOS, e.g. pkgbuild and productsign. Since xadm, is used to manage software for Macs, it assumes its being used by a Mac developer or Sys Admin on a Mac.
All parts have been tested with recent versions of macOS, including 13 Ventura, 14 Sonoma, 15 Sequoia, and 26 Tahoe.
The client tool xolo is a zsh script and will run in macOS with no external dependencies.
Client Macs running xolo must be enrolled in Jamf pro, since xolo is a wrapper around standardized jamf binary commands.
Note that xolo is not required for basic automated install and update functionality for Xolo titles. They will happen naturally via Jamf processes. However some functions, e.g. expiration, do require xolo.
TL;DR
xoloserverrequires ruby 2.7 or higher.xadmwill run in the OS-supplied ruby 2.6, but it is highly discouraged.
Apple announced in 2019 that Ruby, along with Python and Perl, would be removed from macOS 'in a future release'. That happened for Python a few years later, but as of macOS 26 Tahoe, old versions of Ruby and Perl are still part of the OS. Apple discourages the use of these tools for development or production purposes.
While xadm will work with the OS ruby, it is not recommended - Apple could remove it at any point.
The OS ruby will not work with xoloserver, ruby 2.7 or higher is required.
Both have been tested with ruby 3.3, but should work fine with 3.4 (the current release as of Sept. 2025)
There are many ways to install a newer ruby, the most common of which is homebrew.