While every organization has its own unique environment for automating software deployment, here are some general points about automating things with xadm

As with any installation of xadm, it must be running in a fairly recent version of macOS preferrably with Ruby 2.7 or higher installed.

• Configuring xadm
  • Service Accounts
  • Non-GUI mode
• Running xadm
  • proxy-admin
• Don't fully automate xadm release

When a human uses xadm, that person needs to have an account on the Jamf Pro server (standard or Directory Service based) and be part of a Jamf account-group (standard or Directory Service based). The xoloserver passes the user's credentials on to the Jamf Server, which confirms they are correct and the user is in the desired account-group.

When xadm is used in an automated setting, it's wise to create a special 'service account' in Jamf specifically for this purpose.

NOTE: Support for API Clients and Roles coming in v2

These accounts are only used for authentication, and need no actual permissions or access to Jamf Pro. The xoloserver has it's own credentials for accessings and managing objects in Jamf Pro.

Before using xadm for automations, you must run xadm config on the automation host, providing the name and password for the Jamf service acct created for this purpose.

When a human uses xadm it is almost always in the context of a terminal session on the Mac where xadm is installed. This GUI context gives xadm access to their login keychain, which is where it stores their xadm login credentials.

Most automations do not run in such a GUI context, and don't have access to an already-unlocked keychain. In these cases, when running xadm config you should set the 'Non-GUI mode' option to true.

Doing so means you can set the password to be:

• A command prefixed with '|' that will be executed to get the password from stdout. This can have any CLI options and arguments you need to get the password. This is useful when using a secret-storage system to manage secrets.
• A path to an executable file that returns the password to stdout. No arguments are passed, the file is just executed. The file must have only rwx permissions for the user running xadm, i.e. mode 0700.
• A path to a readable file containing the password, which must have only rw permissions for the user running xadm, i.e. mode 0600.
• Or the password itself, which will be stored in the xadm config file, which always has mode 0600.

Any of these methods eliminate the need for an unlocked keychain, but all may be somewhat less secure. Be careful when storing secrets in files.

The account running xadm is recorded in the xoloserver logs as well as in the changelog for each title.

If this is a service account, that usually isn't very helpful. Who triggered the automation to do something with the service account?

When scripting the use of xadm in an automated setting, you should use the --proxy-admin global option.

Here is the snippet about that option from xadm help

  -p, --proxy-admin=<s>    Used for automated workflows that connect to the xolo server using a
                           service account, not a user account. Most such automations have a way to
                           ascertain the identity of the user triggering the automation. They can use
                           that name here, and then it will be used on the server combined with the
                           actually authenticated service acct name for use in logging and status.
                           
                           For example, if you have a CI/CD job that runs xadm commands, it will
                           connect to the xolo server using a service account such as 'xolo-cicd-runner'.
                           That job can get the name of the user triggering the job from an environment
                           variable, (or elsewhere) and pass that as the value of this option, like so:
                           
                             xadm --proxy-admin $CICD_USER_NAME add-version my-title 1.2.3 [options...]
                           
                           On the xolo server, the user will be recorded as
                           
                             cicduser-via-xolo-cicd-runner
                           
                           which will be used as the "added_by" value for the new version, and will show up
                           in the various logs.

The reason Xolo distinguishes between a pilot status and a released status (See the Glossary ) is because it is imporant to test not just the software being deployed, but the deployment process itself.

A poorly-built package can cause havoc on a computer, even if the software being installed is flawless. When that package is auto-installed on large numbers of computers, the havoc can become a disaster.

Becuase of this, it is very unwise to fully automate using xadm release on a version.

Options include:

• A human must run xadm release from their own Mac when its time.
• If your automation system allows it, define a 'release' task that requires a manual trigger, like a button-click in a web page.

See the related section of the xadm-General-Usage page: Re-uploading .pkg files