Files
ubuntu-post-install/services
Claude 2e6f14f17d Support remote Authelia and remote/central CrowdSec LAPI
Both let the DO droplet lean on services already running on a
homelab instead of duplicating them locally, per the RAM-budget
discussion (Authelia+Redis and a second CrowdSec LAPI+DB add up).

crowdsec.sh: new step lets this agent register against a remote LAPI
(cscli lapi register -u <url>) and disables its own local API server
by removing the api.server block from config.yaml (backed up first;
verified the exact block boundaries against CrowdSec's actual default
config.yaml from upstream before writing the awk removal). Parsers,
scenarios, and the firewall bouncer still run locally regardless —
only banning decisions centralize, and only after the registration is
approved with `cscli machines validate` on the central machine, which
this script can't do since that's a different box. The final restart
step is skipped with an explanation when registration is pending,
instead of showing a misleading "failed to restart" for an expected
state.

asterisk-do.sh: when no local Authelia is installed, the web-admin
Caddy step now offers a remote Authelia option instead, building the
same forward_auth block inline (authelia.sh's shared Caddy snippet
only exists for local installs) targeting either a bare host:port
(e.g. a NetBird mesh IP) or a full https:// URL. Documents that this
couples web-admin availability to the remote instance's reachability,
while SIP/calling on the droplet stays unaffected either way.

Both changes verified: the config.yaml block-removal awk logic tested
against CrowdSec's real upstream default file structure, the remote
Authelia forward_auth block construction tested in isolation, and
full regression runs confirm the default (declined) path through both
new prompts is unchanged.
2026-07-19 11:42:40 +00:00
..