ablative docs
↑↓ move↵ openesc close
Stack Notebook ablative.com.au

Installation lifecycle

Inspect the installed deployment commands and their preconditions without changing the running service.

Open .md

Dependencies and private state

The deployment commands describe PostgreSQL, Rauthy, SpiceDB, the directory, broker, runner and proxy. Configuration and generated credentials live in the installation’s private state. Preserve that state and the recorded build when planning recovery.

Check that `PostgreSQL`, Rauthy and `SpiceDB` are ready, naming each one that is not. Prints no credential

lys identity health [OPTIONS] --config <CONFIG>
--config <CONFIG>
The deployment configuration.

This dependency check takes the deployment configuration. The public service health route answers a narrower question: whether the directory itself is serving.

Install and upgrade

Install the whole identity product for this user: a data folder under the application data path, generated keys and configuration, the compose services, the platform's client, the secrets broker and the directory service with its screens, then opens Lys's setup page. Nothing is filled from the machine. Running it again changes only what is missing and restarts only what it changed; nothing is rotated, and a build other than the one placed is refused: that is an upgrade

lys identity install [OPTIONS]

Upgrade a running install to the binaries in a folder, run with the lys built beside them: finish or put back an upgrade stopped part-way, check each binary's --version, render the new build's configuration and compose files, stop the service and the broker, keep the running binaries in bin.previous/ and the files in config.previous/, place the new ones, bring changed compose services to their new definition and start the new build. When anything does not start or become ready, the previous build is put back and started, and the failure is named. Data and credentials are never touched. An install made before builds were named is adopted

lys identity upgrade [OPTIONS] --from <FROM>
--from <FROM>
The folder holding the newly built lys-secrets and lys-identity-server, built with the lys that runs the upgrade.

Install and upgrade are different operations. The upgrade contract identifies the replacement build and preserves prior binaries and configuration for recovery. Read its complete help and the resulting receipts before claiming the new build is active.

Start and stop

Start whatever of the install is down, as the install starts it, and leave running whatever runs: the inverse of stop. A stop of everything pulled in the service stays pulled until the administrator lets agents start again

lys identity start [OPTIONS]

Turn off everything Lys started: ask the service to stop every session on every computer it drives, recording on each who pulled the cord and why; tell this computer's runner the same; stop the runner, the model proxy, the service and the broker; then stop the database, sign-in and permission services, keeping their data. Every part is done whatever an earlier part answered, and each that failed is named. Sessions are hung up and waited on until each has ended; --kill, or a second stop while sessions still run, ends them at once

lys identity stop [OPTIONS] --reason <REASON>
--reason <REASON>
Why everything is stopped, in your words; kept on every session.

Stopping the product can end sessions across the computers it drives. Its reason and receipts matter. Restarting infrastructure does not override an administrator’s stop of agent execution.

Confirm the resulting state

Read the operation receipt, the active build and the service health after maintenance. Confirm runner connections and the intended sessions separately before returning the installation to use.

Lys 0.3.1