mait.sh1.69.2

Private beta: features and content may change. No warranty; use at your own risk.

Docs / Launcher and command-line tools

UaaS CLI

Publish approved software artifacts, move releases between channels and verify exact downloads.

For authorized software publishers, release managers and signing-service operators.

Read from the top for the basics; the later sections go deeper.

Beta

What it doesBasics

  • Prepare draft releases and upload approved platform artifacts
  • Publish, promote, demote, withdraw and retire releases
  • Retrieve exact artifacts with integrity and signature verification
  • Inspect signing keys, request rotation and maintain the CLI

First useBasics

  1. Obtain the approved Linux amd64 or arm64 executable and verify its published digest through your distribution process.
  2. Run uaas version and uaas help; select the approved environment and credential.
  3. Run uaas product list and uaas channel list --product-id PRODUCT_ID for the approved scope.
  4. Read the full result; perform mutations only under the owner’s approved plan.
  5. Restore temporary settings afterward. A read-only trial needs no record deletion.

Everyday tasksEveryday use

Inspect the approved release scope

A publisher needs to confirm catalog identity before a write.

  1. Confirm deployment and required product permission.
  2. Run uaas product list, then uaas channel list --product-id PRODUCT_ID.
  3. Read the known release with uaas release show --product-id PRODUCT_ID RELEASE_ID; use list for its channel.

What you getThe exact product, release and intended channel are established.

How to check: Release list is capped at 200 records and some details are omitted. Absence from a list is not proof of absence.

Prepare and publish an approved build

A release owner has approved a version and platform support matrix.

  1. Create a draft with uaas release create --product-id PRODUCT_ID --version VERSION --channel edge --update-type upgrade; use full instead only when intended.
  2. Upload each approved artifact with uaas release upload --product-id PRODUCT_ID --release-id VERSION --platform PLATFORM --file ARTIFACT.
  3. Read back the draft and compare all platforms with the approved matrix.
  4. Publish with uaas release publish --product-id PRODUCT_ID VERSION.
  5. Download the exact version to a dedicated path, then follow the release owner’s installation and ordinary functional acceptance procedure.

What you getThe approved bytes are available and a real consumer operation has been verified.

How to check: Upload alone is not publication; publication alone is not installation. First publication has no previous platform set for comparison. An approved platform drop requires both --allow-platform-drop and --reason.

Expand a verified rollout

An accepted release is ready for the next more-stable channel.

  1. Record its exact ID, current channel and active status.
  2. Run uaas release promote --product-id PRODUCT_ID --version VERSION once after approval.
  3. Inspect the matching list row for the new channel and active state; use the service owner’s supported view if outside the list window.
  4. Verify required pruning separately and confirm the intended consumer offer.

What you getThe release reaches the approved channel with understood cleanup.

How to check: Promotion can succeed while pruning fails. Repeating an ambiguous promotion can advance another channel; demotion does not roll back installed machines.

Recover an interrupted artifact transfer

A large upload or exact download failed partway through.

  1. Keep the approved source file unchanged and inspect current release state.
  2. An upload at or above 100 MiB uses chunking; retry with the same file and target only after reconciliation.
  3. For download, confirm exact active version, platform and channel visibility and use a dedicated destination.
  4. Require completed size, checksum and signature verification before executing the downloaded artifact.

What you getThe intended artifact is transferred and independently accepted.

How to check: A finalized upload can still have a lost response. Old destination files and temporary download files are not success evidence; unchanged published bytes may be accepted as a no-op.

Retire content or rotate signing keys

The service owner approved a distribution or signing change.

  1. Record release state, accepted replacement and retention decision before withdrawal, archive or deletion.
  2. Run only the approved transition, then inspect the exact record and consumer behavior.
  3. For key rotation, record uaas key list, run uaas key rotate once, then verify the new active ID and prior trusted ID.
  4. Verify an approved new signature and retained old artifact with their intended consumers.

What you getThe intended catalog or key state is established and the recovery plan remains usable.

How to check: Rotation is service-wide and does not revoke old trust. Withdrawal cannot recall downloaded bytes; product deletion affects its entire catalog scope. Inspect before retrying a lost response.

Settings to decideAdvanced

Confirm the assigned environment
MAIT_CHANNEL selects stable, beta or edge for release builds; saved installation selection can otherwise apply. Correct configuration warnings before a write: fallback can select stable. Deployment selection and release-channel entitlement are separate.
Choose the intended credential
UAAS_CREDENTIALS_PATH takes precedence even when empty; a nonempty CREDENTIALS_PATH otherwise applies before user/system discovery. Unset an unwanted override. Optional settings use ~/.mait/uaas.yaml or /etc/mait/uaas.yaml; there is no arbitrary service-URL flag.
Restore the session deliberately
Record non-secret settings before changes. Restore temporary overrides afterward; do not remove shared credentials, grants or cache directories as routine read-only cleanup.
Account for request and notification timing
Administrative requests allow 600 seconds each; a transfer can span several requests and retries. UAAS_UPDATE_COOLDOWN defaults to 600 seconds. UAAS_UPDATE_TIMEOUT does not change this CLI’s request deadline, and re-execution/grace settings do not enable installation of staged updates.

CommandsAdvanced

$ uaas version
$ uaas help
$ uaas login
$ uaas doctor
$ uaas update

Problems and fixesHelp

What you seeCheckFix
Sign-in works but administration is refusedConfirm environment, product permission and current service authority.A usable credential and healthy service do not grant every operation. Current access can be denied or temporarily unverifiable; resolve that with the service owner. An interrupted response does not undo a committed write.
A mutation failed or its result is unclearRead the exact product, release or key state before retrying.Nonzero status does not prove no change. Product create/show and key rotate may omit details; read product or key list. Repeating rotation or promotion can perform another change.
Publication rejects the artifact setCompare the draft with the approved support matrix and latest active release.Supply missing approved builds. Use the paired platform-drop override and reason only for an approved retirement; do not withdraw an existing release to evade the comparison. Use `upgrade` or `full` for `--update-type` despite the stale help hint.
Transfer or verification failsConfirm the unchanged source file, release identity, channel and expected checksum.Chunk retry can resume a matching session, but expiry or finalization failure may require a fresh transfer. Do not execute incomplete downloads or bypass signature/checksum checks; an older destination can remain after failure.
The update is staged but the version is unchangedInspect the complete result and ask the installation owner to apply the release.uaas update requires an interactive terminal when an offered update needs approval; there is no force flag. A late cache-write failure can leave stage files. Startup does not install them; confirm version and an authorized read after replacement.
What you see
Sign-in works but administration is refused
Check
Confirm environment, product permission and current service authority.
Fix
A usable credential and healthy service do not grant every operation. Current access can be denied or temporarily unverifiable; resolve that with the service owner. An interrupted response does not undo a committed write.
What you see
A mutation failed or its result is unclear
Check
Read the exact product, release or key state before retrying.
Fix
Nonzero status does not prove no change. Product create/show and key rotate may omit details; read product or key list. Repeating rotation or promotion can perform another change.
What you see
Publication rejects the artifact set
Check
Compare the draft with the approved support matrix and latest active release.
Fix
Supply missing approved builds. Use the paired platform-drop override and reason only for an approved retirement; do not withdraw an existing release to evade the comparison. Use `upgrade` or `full` for `--update-type` despite the stale help hint.
What you see
Transfer or verification fails
Check
Confirm the unchanged source file, release identity, channel and expected checksum.
Fix
Chunk retry can resume a matching session, but expiry or finalization failure may require a fresh transfer. Do not execute incomplete downloads or bypass signature/checksum checks; an older destination can remain after failure.
What you see
The update is staged but the version is unchanged
Check
Inspect the complete result and ask the installation owner to apply the release.
Fix
uaas update requires an interactive terminal when an offered update needs approval; there is no force flag. A late cache-write failure can leave stage files. Startup does not install them; confirm version and an authorized read after replacement.

All UaaS CLI problems and fixes →

Good to knowHelp

  • Sign-in does not grant every administrative permission. Inspect the full result and resulting state.
  • Uploading, publishing and successful customer installation are separate results.
  • Updates are staged; this CLI does not install them on the next launch.