28 lines
4.3 KiB
Markdown
28 lines
4.3 KiB
Markdown
# Remaining remote utilities and command audit
|
|
|
|
## Unit setup
|
|
|
|
`remote backend setup` renders `scripts/werkjournal-backend.service.in` for the established Hostsharing home, writes the owner-only user unit and runs `systemctl --user daemon-reload`. It requires the installed JDK/site, acquires the shared deployment lock and refuses pending deployment/restore journals or systemd drop-ins. It does not start, stop, enable or disable the service. The separate secret EnvironmentFile is only referenced by the template, never read or rewritten by setup.
|
|
|
|
If the previous unit differs, one owner-only `.previous` copy is retained. Failed daemon reload restores the previous unit and attempts to reload it again before reporting failure. Unit paths and temporary/previous paths may not be symlinks. An integration test verifies that the rendered unit satisfies the existing deployment preflight.
|
|
|
|
## Release information
|
|
|
|
`remote backend info` returns JSON with the verified manifest's version/commit, systemd state, maintenance/transition flags and separate `backendReady`/`publicReady` results. It calls only `/api/v1/info`, without login or access to tracking records. The commit comes from the verified deployment manifest; the HTTP endpoint verifies the application/version.
|
|
|
|
The internal loopback endpoint is always checked. During maintenance the public check is skipped and represented as `null`; otherwise the HTTPS endpoint is checked as well. Failed release verification, a stopped service, failed/version-mismatched HTTP response or an observed deployment/restore transition yields a nonzero exit. A successful internal check during maintenance does not claim public availability. Changes to the selected release, deployment manifest or maintenance state during the probe are reported as a transition.
|
|
|
|
## SSH shortcut
|
|
|
|
`remote ssh` opens an interactive SSH session. `remote ssh COMMAND ARG...` runs a command with separately quoted arguments, for example `remote ssh ls -l opt/werkjournal`. Shell syntax is available only when explicitly requested, such as `remote ssh sh -c '...'`. The shortcut uses the configured SSH target and existing key authentication. Every invocation opens one connection; retain the Hostsharing rate-limit spacing when issuing several commands.
|
|
|
|
## Available command coverage
|
|
|
|
The implemented command set now covers the agreed remote interface: JDK installation; first/prototype deployment; regular deployment and interrupted-deployment recovery; candidate-only upload; systemd start/stop/restart/status/enable/disable; unit setup; logs; version/readiness info; consistent private backup; confirmed restore and interrupted-restore recovery; explicit administrator recovery; and SSH. `deploy` and `upload` accept the compatibility `-y` flag before `--artifact`, without bypassing validation. Destructive restore still requires its own explicit confirmation.
|
|
|
|
Configuration uses the actual `.env.example` names (`BACKEND_SSH`, `BACKEND_DIR`, `BACKEND_JDK_DIR`, `BACKEND_PORT`, `BACKEND_URL`, `DEPLOY_TARGET`). The managed unit name is `werkjournal-backend.service`; arbitrary alternative layouts are not silently deployed. `.envrc` adds `tools` to PATH without executing `.env`. The detailed backup/restore, upload, service-control and recovery documents describe their respective gates and evidence. Broader runbook, Hostsharing-backup restore and browser/device acceptance remain separate tasks.
|
|
|
|
Validation: operations tests cover unit rendering/reload rollback, preserved secrets, pending-operation and symlink/drop-in refusal, internal/public info behavior and transitions, literal SSH arguments and deploy's `-y` argument parsing. Live Hostsharing `info` verified commit `88d5f3f` / `0.1.21-SNAPSHOT`, active service, valid manifest and both HTTP paths. The real idempotent setup command completed successfully without a service restart.
|
|
|
|
The final command audit also unified the database replacement core: operator restore and automatic deployment rollback now both call `replace_database`, which flushes a separate copy before displacing the closed live directory. A failed copy/flush leaves the live directory intact. All 68 operations tests pass, including both recovery workflows and this failure boundary. The repeated isolated JAR/H2 restore probe passed for the shared core. Live SSH also preserved a literal `$(...)` argument exactly, without evaluating it.
|