mait.sh1.69.2

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

Docs / Launcher and command-line tools

LaaS CLI

Administer approved accounts, product grants, activation codes and organizational placement.

For authorized account administrators and custom-deployment certificate custodians.

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

Beta
All components

What it doesBasics

  • Inspect accounts and grants, issue activation codes and verify recipient access
  • Maintain organizational groups and withdraw approved access
  • Prepare local certificates for explicitly trusted custom targets
  • Diagnose credentials and stage a verified CLI update

First useBasics

  1. Obtain the approved Linux amd64 or arm64 executable and verify its published digest through your distribution process.
  2. Run laas version and laas help; select the approved environment and credential.
  3. Run laas customer show CUSTOMER_ID for the known account and inspect the returned identity.
  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 an approved account

You need to confirm a known account for product access before changing it.

  1. Confirm the environment, account ID and required permission.
  2. Run laas customer show CUSTOMER_ID and inspect the returned ID.
  3. Use the approved inventory interface when you need enabled state or a complete customer or license list.

What you getThe intended account is identified before any mutation.

How to check: A zero exit or missing display field is insufficient; page-number options do not traverse the server’s cursor-based customer list.

Provision and verify a recipient’s access

An approved recipient needs a defined product grant.

  1. Read the known customer and establish the full existing grant set through the approved inventory interface.
  2. Apply only the approved product and feature map with laas license add, then read the returned license ID.
  3. Issue a bounded activation code with laas credentials issue --customer-id CUSTOMER_ID --expiration-minutes 1440 --max-uses 1 only when those limits match the plan.
  4. Deliver the code securely; the recipient runs laas login using their own intended credential destination.
  5. Have the recipient complete the product’s approved harmless operation.

What you getStored grants, recipient custody and actual access match the plan.

How to check: Do not share the administrator’s bundle. A code may be consumed before a local save fails; reconcile before replaying it.

Change organizational placement

A customer needs an approved group membership or hierarchy change.

  1. Read the group and customer before laas group assign --customer-id CUSTOMER_ID --group-id GROUP_ID.
  2. Confirm the resulting membership through the approved account interface; assignment adds to existing memberships.
  3. Refresh credentials when required and verify the intended operation.

What you getThe intended placement is confirmed without inferring extra permissions.

How to check: Unassign clears every membership, not one group. Omitted parent updates do not make a child a root; group placement is separate from access grants.

Withdraw access deliberately

The account owner has approved a grant revocation or suspension.

  1. Read the exact license before laas license revoke --customer-id CUSTOMER_ID --license-id LICENSE_ID --reason APPROVED_REASON.
  2. Retain the reason in the approved change record and read the resulting status.
  3. For account suspension, use the separately approved customer disable task and confirm state through the account interface.
  4. Verify the intended access cessation at the actual consumer.

What you getThe approved server change and consumer behavior are established.

How to check: Revocation does not erase offline credentials; the service does not preserve the CLI revoke reason in its revocation event. Deletion is a separate decision.

Prepare a certificate for a custom trusted target

A test or custom deployment explicitly trusts the chosen issuer.

  1. Use a private working directory, approved signer and fresh output paths.
  2. Use laas help cert to choose server or credential generation with the target’s exact identity and feature requirements.
  3. Inspect the resulting bundle, then use the target’s verifier and intended operation.
  4. Use laas cert export-p12 only when the destination requires it and OpenSSL is available on PATH.

What you getThe exact target accepts the intended artifact under its own trust policy.

How to check: Local generation does not add a new issuer to existing MAIT trust. Inspection is not signature or key-match validation; keep issuer keys separate and account for partial output files.

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
LAAS_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/laas.yaml or /etc/mait/laas.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.
Choose when renewal is attempted
LAAS_RENEWAL_THRESHOLD_MINUTES defaults to 10080; larger values start attempts earlier. LAAS_RENEWAL_GRACE_AFTER_EXPIRY_SECS defaults to 2592000. Neither extends the certificate’s validity or grants permissions; login --check attempts renewal separately.

CommandsAdvanced

$ laas version
$ laas help
$ laas login
$ laas doctor
$ laas update

Problems and fixesHelp

What you seeCheckFix
The command exits zero but access failsRead the full response and verify the intended operation.Administrative HTTP rejection can accompany exit zero. Credential validation can print a positive headline for a negative decision; neither is an acceptance test.
A list or group display looks incompleteRead a known ID and use the approved complete-inventory interface.Customer page numbers do not advance the service cursor; license list reads one response window. Version 0.5.36 can omit group relationships from its results; the current development version improves lookup but still omits organizational paths. Do not infer missing records or replay grants from partial output.
Login or renewal failed after submissionPreserve active and backup paths without printing secret contents.Activation may consume a code before local persistence fails, and restoration is not guaranteed. login --check attempts renewal; use it only when that attempt is intended. Resolve the failed phase before retrying.
PKCS#12 conversion failsConfirm OpenSSL, the approved certificate/key pair and input format.Export needs an unencrypted PKCS#8 PRIVATE KEY block and complete LF-terminated PEM markers. A counted key or successful inspection does not prove compatibility. Protect passwords in command arguments and do not import partial output.
A staged update does not change the running versionCheck laas version and the installation owner’s replacement process.Staging is not installation and the next launch does not apply it. For an authorized unattended download use laas update --force; force does not skip verification. Confirm an authorized read after replacement.
What you see
The command exits zero but access fails
Check
Read the full response and verify the intended operation.
Fix
Administrative HTTP rejection can accompany exit zero. Credential validation can print a positive headline for a negative decision; neither is an acceptance test.
What you see
A list or group display looks incomplete
Check
Read a known ID and use the approved complete-inventory interface.
Fix
Customer page numbers do not advance the service cursor; license list reads one response window. Version 0.5.36 can omit group relationships from its results; the current development version improves lookup but still omits organizational paths. Do not infer missing records or replay grants from partial output.
What you see
Login or renewal failed after submission
Check
Preserve active and backup paths without printing secret contents.
Fix
Activation may consume a code before local persistence fails, and restoration is not guaranteed. login --check attempts renewal; use it only when that attempt is intended. Resolve the failed phase before retrying.
What you see
PKCS#12 conversion fails
Check
Confirm OpenSSL, the approved certificate/key pair and input format.
Fix
Export needs an unencrypted PKCS#8 PRIVATE KEY block and complete LF-terminated PEM markers. A counted key or successful inspection does not prove compatibility. Protect passwords in command arguments and do not import partial output.
What you see
A staged update does not change the running version
Check
Check laas version and the installation owner’s replacement process.
Fix
Staging is not installation and the next launch does not apply it. For an authorized unattended download use laas update --force; force does not skip verification. Confirm an authorized read after replacement.

All LaaS CLI problems and fixes →

Good to knowHelp

  • Sign-in does not grant every administrative permission. Inspect the full result and resulting state.
  • Local certificate generation does not add trust to MAIT services.
  • Updates are staged; this CLI does not install them on the next launch.