59. Verbose mode: see everything a run did
This guide describes Lawliet 1.6.3.b (the current release, a beta: earlier releases are beta. The first stable release will be 2.0.0). Screens, commands and procedures may change in later versions; the usage guide is updated with each release. Check the version your server runs under Settings > Platform or with ./lawliet version, and see the Releases page for what changed.
Every run in Lawliet normally shows a status: executing, completed, failed. Verbose mode expands each status into the run's whole story - every command the server sent, when it was signed, delivered and started on the host, what the host printed, the exit code, the line of output that decided a verdict, every skip and refusal with its reason, and who approved. It exists so that you never have to guess what happened on a host.
There are two switches:
- in the console, Verbose in the header (59.1 - 59.4);
- on the server,
./lawliet --verbose <command>(59.5).
Secrets are removed the way the diagnostics archive (7) removes them, from every line of a timeline (titles, reasons, quoted output lines, outputs) and from every download: passwords, tokens, keys, licence material, private key blocks and URL credentials by their shape; this server's own secret settings; and every credential the database holds - agent tokens, deployment credentials, sealed command parameters, firewall, vSphere and AWS credentials. A stored credential stored or changed through Lawliet itself (the console, the API, enrolment) is removed from the first refresh after it is saved, whichever server process saved it; one written into the database by other means is removed within 5 minutes. The sealed parameters of every command a timeline shows are read with it, whatever its age. A short, word-like stored password (for example lawliet) is not replaced wherever the word appears, exactly as in the archive.
| Task | Permission | Four-eyes |
|---|---|---|
| Turn verbose on or off (for yourself) | any signed-in user | no |
| See a run's verbose timeline | the permission of the screen the run is on (table in 59.3) | - |
| See a command's raw output in an agent's timeline | also the permission of the module that sent it (59.3) | - |
| Download a whole output | as for seeing it | - |
./lawliet --verbose | root on the server | no |
59.1 Procedure: turn verbose on or off#
- In the console header, next to the theme switch, click Verbose (on a phone: the scroll icon). It turns blue when on.
- Click it again to turn it off.
The setting is yours: it is saved with your account on the server (and in this browser), so it follows you to another browser and does not change what anyone else sees. With it off, every screen is exactly as before.
59.2 What a timeline shows#
With verbose on, each run screen shows a Verbose panel under the run's own view:
| Screen | Where the panel is | Shows |
|---|---|---|
| Hardening, one run | Hardening > a run (the side panel) > under Steps | per step: the fix, validation and rollback commands; each command queued, signed (valid until), delivered, running, finished with its exit code, stdout, stderr and the agent's own log lines; the validation's raw output and the line that decided ("the last output line 'FAIL' ends with FAIL"); whether the control was marked compliant; waiting for and after a restart; restore errors of a rollback; who requested and who approved |
| Hardening, a batch | Hardening > Batches > a batch (open it) | the same for every host, plus the batch's request, approval, and every control each host skipped or refused, with the reason |
| Compliance scan | Compliance > a scan | per host: checks queued, sent, answered, timed out, still in flight; per check: the verdict and why (the deciding line, the exit code, or the not-assessed reason such as a timeout or a clock behind the server), the result as stored, the NOT_APPLICABLE rule, the raw output |
| DLP scan | DLP > Discovery > Recent scans (the newest; Detail on a row for another) | the scan command's lifecycle; files walked, inspected (read and evaluated by the content worker) and skipped by reason (excluded, not included, permission denied, larger than the inspection limit, unreadable) with sample paths; files not inspected because the content worker did not answer, each with why; whether the scan stopped at its file or time limit; the content worker's state (in process, running, back-off with the reason); per file: matches and rules, the snippet redacted; errors |
| Agent | Environment > Hosts > an agent (the side panel), at the bottom | every command sent to the host, newest first, with its lifecycle, result and output |
| Remote deployment | Environment > Hosts > Deploy agents remotely > a deployment | per host: connecting, preflight (every check with its explanation and fix), copying and running the installer with its output, waiting for enrolment, enrolled or failed with the step and reason |
| Platform updates | Settings > Platform updates, under the panel | each update check (what the feed offered, or why it failed), each upload and staging (version, digest, verified, or why it was refused), each discard, and the result of the last ./lawliet update (succeeded, or failed with the step it stopped at) or ./lawliet rollback on the server (newest first); refreshed after each Check, upload or staging |
| Agent upgrades | Environment > Agent versions > under Upgrade history (pick one) | the upgrade command's lifecycle, then each stage the agent reported with its time: downloading, verifying the signature and digest, swapping in the new binary, running (after the restart), and the version the agent then reports |
Each line has its time (your browser's clock zone), the host, a coloured dot (green done, amber a warning or a skip, red a failure) and, where there is one, the raw output. Use Filter to keep lines that mention a word (a host, a control), and Problems only to keep warnings and failures.
Live. While a run is running, its panel refreshes every 3 seconds, and less often (up to 30 seconds) while nothing changes; while it waits for a person (an approval, a maintenance window) every 30 seconds; when the run has finished it stops asking. Only open panels ask, and a browser tab in the background asks nothing until it is shown again.
Long runs. A timeline shows 100 lines a page (Previous / Next); an agent's commands 50 a page.
59.3 Procedure: read a command's whole output#
What is kept. The server keeps each command's stdout and stderr whole up to 65,536 characters. A longer one is kept as its first 8,192 and last 57,344 characters, with a line ... N characters omitted ... between them, so the end - where the errors and the verdict line are - is never lost. Agents from 2.2.0.b send the same head and tail (compliance checks, hardening, and operator commands); older agents send only the first 10,000 characters of each (20,000 for an operator command).
What a timeline shows. The last 1,536 characters of each output (from the start of a line) and "last part shown" when there is more. A task's structured result is shown only on the command itself, never in an agent's list.
- Open the output (stdout, stderr, agent log, result data).
- Click Show all to see the whole output as the server keeps it, in place; or Download full stdout (or the stream you want) for the same text as a file. Both are redacted the same way.
Who sees what:
| Timeline | Needs |
|---|---|
| Hardening run, batch | View hardening |
| Compliance scan | View compliance |
| DLP scan | View DLP |
| Agent, one command | View agents |
| Agent upgrade | Manage agents |
| Platform updates | Manage platform updates |
| Remote deployment | Manage deployment credentials |
In an agent's timeline every command shows its lifecycle, but its output only when you also hold the permission of the module that sent it (a hardening fix needs View hardening, a compliance check View compliance, a DLP scan View DLP, an upgrade or operator command Manage agents); otherwise the line says the output needs that permission. A recovery-key result is never shown to anyone. The sandbox login sees only sandbox runs.
59.4 The agent's own log lines#
Agents from 2.2.0.b attach to each result the lines they logged while running that command (at most 40, each at most 300 characters) - for example "WARNING sysctl exited 1" from inside a hardening fix. They appear as agent log under the result. Older agents send none; the rest of the timeline is the same.
59.5 ./lawliet --verbose#
sudo ./lawliet --verbose update lawliet-1.5.16.s.tar.gz
sudo ./lawliet doctor -v
sudo LAWLIET_VERBOSE=1 ./lawliet backup--verbose (or -v, anywhere on the line, or LAWLIET_VERBOSE=1) works with every command - install, update, rollback, doctor, backup, restore, tls, agent-upgrades and the rest. It adds:
- a time on every step line:
[14:02:11] OK Backend restarted: agent upgrades are on; - every
docker,docker composeandcurlcommand the step runs, as[14:02:09] $ docker compose -f docker-compose.yml up -d backend, followed by its exit code; - the output of those commands that the step would normally throw away, indented with
|.
Output the command uses itself (a database dump written to the backup file, a value it reads) is not copied to the screen. Passwords, tokens, keys, licence keys, password hashes, URL credentials and private key blocks are masked as <redacted> in everything it prints. The verbose lines are written to the terminal's error stream, so ./lawliet -v update ... 2>update-verbose.log keeps them in a file while the normal output stays on screen. Without the flag the output is exactly as before.
59.6 How long the step history is kept#
The steps that only verbose keeps - agent upgrade stages, remote deployment steps and the console's update steps - are kept for RETENTION_AGENT_COMMAND_DAYS (90 days by default, as the commands they explain), at most 200 per upgrade or deployed host (the latest 200 for platform updates), and are deleted with their upgrade, host, deployment or agent.