Add the deployment path: agent systemd unit and container image
The README referenced `deploy/install-agent.sh` and a `Containerfile` that did not exist, so a fresh clone had no way to actually run this anywhere. * agent: `--token-file` (and AGENT_TOKEN_FILE). The token guards hostname, mounts, disk and GPU models and process names, and argv is world-readable through `ps`, so a file has to win over the flag. Missing or empty token files are fatal — falling back to "no token" would expose the host. * deploy/install-agent.sh: creates a system user, generates the token once (re-runs reuse it, --rotate-token for a new one), stores it 0600 root-owned, and runs the agent under ProtectSystem=strict with no capabilities; --status and --uninstall included. * Containerfile: two-stage, uv.lock resolved in the builder and slim Python in the runtime. Verified with podman — the image serves /api/health as an unprivileged user and writes its history under /var/lib/dashboards. UV_PROJECT_ENVIRONMENT and --no-editable are what make the venv survive being copied into the runtime stage. * .containerignore keeps .git, .venv, data/ and .env out of the build context. 258 tests, 94% coverage; ruff and pyright clean. LLM-Generated: true
This commit is contained in:
@@ -45,14 +45,23 @@ uv run dashboards
|
||||
|
||||
```bash
|
||||
python3 host_agent.py --once # print one snapshot, exit
|
||||
python3 host_agent.py --host 0.0.0.0 --port 9120 --token … # serve, token required
|
||||
deploy/install-agent.sh # systemd unit (run with sudo)
|
||||
python3 host_agent.py --host 0.0.0.0 --port 9120 --token-file /etc/dashboards-agent.token
|
||||
sudo deploy/install-agent.sh # systemd unit + user + token
|
||||
deploy/install-agent.sh --status # unit state and /health
|
||||
sudo deploy/install-agent.sh --uninstall
|
||||
```
|
||||
|
||||
It is read-only by construction: there is no code path that writes, and the HTTP server
|
||||
only answers `GET`. Counters are reported as counters — the dashboard computes rates over
|
||||
a labelled window, so the agent never has to remember who polled it last.
|
||||
|
||||
Binding off-loopback without a token is refused (exit 2) rather than warned about. Prefer
|
||||
`--token-file` over `--token`: argv is world-readable through `ps`, and this token guards
|
||||
hostname, mounts, disk and GPU models, and process names. `deploy/install-agent.sh` creates
|
||||
a system user, generates a token once (re-runs reuse it; `--rotate-token` for a new one),
|
||||
stores it `0600` root-owned, and runs the agent under `ProtectSystem=strict` with no
|
||||
capabilities — enough to read `/proc`, `/sys` and `statvfs()` and nothing else.
|
||||
|
||||
## Configuration
|
||||
|
||||
Everything comes from the environment (see `.env.example` for the annotated list). At
|
||||
@@ -130,13 +139,19 @@ outright while the UPS is already on battery.
|
||||
|
||||
## Deployment
|
||||
|
||||
`Containerfile` builds a slim image (the agent is copied in too, so one image can serve a
|
||||
host if you want). In the deployment repo the pattern is the same as every other service:
|
||||
quadlet container + env template + nginx/SNI on the single domain.
|
||||
`Containerfile` is a two-stage build: `uv.lock` is resolved in the builder (exactly the
|
||||
versions the tests ran against) and the runtime stage is slim Python with nothing but the
|
||||
venv in it. The host agent is copied in too, so one image can monitor the box it runs on.
|
||||
In the deployment repo the pattern is the same as every other service: quadlet container +
|
||||
env template + nginx/SNI on the single domain.
|
||||
|
||||
```bash
|
||||
podman build -t dashboards .
|
||||
podman run --rm -p 8090:8090 --env-file dashboards.env dashboards
|
||||
podman run --rm -p 8090:8090 --env-file dashboards.env \
|
||||
-v dashboards-data:/var/lib/dashboards dashboards
|
||||
```
|
||||
|
||||
Keep the SQLite file on persistent storage (`-v dashboards-data:/var/lib/dashboards`).
|
||||
It listens on `0.0.0.0:8090` as an unprivileged user, and the SQLite history lives in
|
||||
`/var/lib/dashboards` — put a volume there or every restart forgets the charts. With no
|
||||
sources configured `/api/health` answers `200 {"status": "empty"}`, so the container passes
|
||||
its health probe before its env file is right instead of crash-looping.
|
||||
|
||||
Reference in New Issue
Block a user