The Dockerfile COPYs scripts/vpn-diagnostics.sh and
scripts/dns-whitelist.sh into the image, but the vendor-file-copying
step in both asterisk.sh and asterisk-do.sh never copied (or
downloaded, in the GitHub-fallback branch) that scripts/ directory —
only Dockerfile, entrypoint.sh, coturn-entrypoint.sh, and the
management script. Every real install hit "docker compose up -d
--build" failing with:
failed to compute cache key: ... "/scripts/dns-whitelist.sh": not found
Confirmed live on a deployed droplet. vendor/easy-asterisk/scripts/
already has both files — this was purely a missed copy step, not a
vendoring gap. Fixed in both files identically (mkdir scripts/, copy
or curl both scripts, chmod +x alongside the existing executables).
Verified at the filesystem level: after a full install run, both
files land in the build context with correct executable permissions,
resolving the exact COPY instructions that were failing. Full
docker build verification wasn't possible in this sandbox (a separate,
unrelated network restriction blocks pulling the ubuntu:24.04 base
image here), but the missing-file root cause is directly fixed.
Real-world failure: configure_caddy_for_service's own domain prompt
defaults to "<subdomain>.${SITE_DOMAIN}", which only equals
$DOMAIN_NAME if SITE_DOMAIN happens to be set to match. In practice
SITE_DOMAIN is never set when this service is run by name (e.g.
`sudo ./setup.sh asterisk-do`), since that path skips setup.sh's own
site-defaults wizard — so the reconstructed default silently came out
wrong/blank, and a user had to guess whether to type the SIP domain or
something else at a bare "Domain [ ]:" prompt.
There's exactly one correct domain for this site block — $DOMAIN_NAME,
the same one already used for SIP — so it's no longer asked for at
all. This inlines the same Caddyfile-writing logic
configure_caddy_for_service uses (backup, dedup check, reload; local
and remote-Caddy modes both preserved) but targets $DOMAIN_NAME
directly. The only remaining question is a plain yes/no to proxy it.
Verified the block-generation logic directly against a real Caddy
directory + domain (produces the exact expected Caddyfile entry), plus
a full end-to-end regression run.
Typing out keyword names (e.g. "netbird backup") was more friction
than necessary. Now a numbered list (1-6), answered as comma-separated
digits with an example shown ("Example: 5,6"), translated internally
back to the same space-separated keyword string every existing
dispatch check (authelia/ntfy/watchtower/wg-easy/netbird/backup) was
already matching against — so none of those call sites needed to
change. Handles spaces after commas and silently ignores invalid
entries rather than erroring. Verified the number-to-keyword mapping
in isolation across normal input, spacing variants, invalid digits,
and blank, plus a full end-to-end regression run.
Naming a service directly (sudo ./setup.sh asterisk-do) bypasses
setup.sh's own first-run base step entirely — essential packages, SSH
key import, disabling password auth. Docker still gets installed
either way (asterisk-do's own require_docker handles that), but the
SSH-hardening part of this setup's security story was silently
skipped on a genuinely fresh droplet unless the user knew to run
`base` separately first.
Checks the same marker setup.sh itself uses for "is base installed"
(command -v ncdu) and offers to run install_base directly if not —
same cross-service-call pattern already used for Caddy/CrowdSec/etc.
Verified end-to-end in a real sandbox run: base actually installed
packages, and execution correctly continued through the rest of the
asterisk-do flow afterward.
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.
Adds a 'netbird' keyword to the existing extras prompt, dispatching
services/base.sh's _base_setup_netbird helper — a plain function like
any other once setup.sh sources every services/*.sh file, despite its
underscore-prefixed, not-independently-registered naming. Its own
prompt already defaults to enabling NetBird's built-in SSH server
(--allow-server-ssh), which is what makes the 'backup' extra usable
against a home machine without port-forwarding a router: install
NetBird here and on that machine, join both to the same network, and
Borg's SSH remote target becomes the home machine's mesh IP instead of
a public address. Skips cleanly if NetBird's already installed.
README's Optional extras section documents the pairing.
Extends the self-contained pattern from Caddy/CrowdSec to five more
services, offered through one consolidated "Install:" prompt instead
of five separate interruptions:
- authelia: only offered if Caddy is present (it's useless without
Caddy's forward-auth snippet); dispatched right where Caddy's state
is already known.
- wg-easy: installed alongside the other firewall rules so its port
lands with them. Only 51820/udp (the VPN handshake) goes on the
public firewall — the web UI (51821) is deliberately left closed,
documented as reachable via SSH tunnel instead, since exposing a
VPN's own admin panel publicly is a real foot-gun.
- ntfy, watchtower: independent, dispatched after CrowdSec. Watchtower
section is explicit that it only benefits coturn (a pulled image) —
Asterisk is a local Dockerfile build with no registry tag to check.
- backup (borg-backup): dispatched last. Documented clearly as a
config/data backup to a local machine or SSH remote, not a full
droplet image — the alternative to DO's paid Droplet Backups.
Every sub-install this calls does its own `cd` into ~/docker/<name>;
each call site restores `cd "$EA_DIR"` afterward so the later bare
`docker compose up -d --build` still targets the right directory.
Verified in isolation (mocked cd side effects) since driving five
real interactive sub-installs through piped stdin isn't practical.
README updated with an "Optional extras" section covering all five.
Self-contained by default now: if Caddy or CrowdSec aren't already on
the box, asterisk-do offers to install them itself (calling their
install_ functions directly — setup.sh sources every services/*.sh up
front, so they're already in-process during a wizard run). Standalone
single-file runs get a manual pointer instead, since those functions
don't exist outside the full repo checkout.
Also fixes the confusing "Configure Caddy reverse proxy for Asterisk
Web Admin" domain prompt: it used to ask for a second, independent
domain, which silently breaks the TLS cert sync if it doesn't match
the SIP FQDN exactly (Caddy only holds a cert for the domain it's
actually serving). It now always reuses the SIP FQDN automatically —
reconstructing configure_caddy_for_service's subdomain default so the
common case (SIP domain is a subdomain of SITE_DOMAIN) needs zero
extra input, with clear wording either way. FQDN prompt, README, and
final summary updated to match.
Vendor's logger.conf only sent Asterisk's security-level log lines
(auth failures, SIP registration scanning) to the console, i.e.
Docker's stdout — not a file CrowdSec could tail. asterisk-do.sh now
patches its copy of entrypoint.sh (vendor/ untouched) to also write
those events to /var/log/asterisk/full, which is bind-mounted to
~/docker/asterisk-do/logs/full on the host.
crowdsec.sh now detects that directory and, if present, installs the
crowdsecurity/asterisk collection (asterisk_bf + asterisk_user_enum
scenarios) with a matching log acquisition — mirroring the existing
Caddy detection pattern. Order-independent: asterisk-do's install
summary tells the user to rerun crowdsec if it's already installed,
since detection only runs during crowdsec's own install step.
DigitalOcean doesn't provision swap by default and the $4/mo (512MB)
droplet has little headroom once Docker + Asterisk + coturn are
running. The installer now detects RAM <=2GB with no existing swap and
offers to add a persistent 2GB swapfile before doing anything else, so
that tier is safe to use instead of risking an OOM kill under load.
README updated with the corrected sizing table.
Duplicates services/asterisk.sh (left untouched) into a DO-specific
variant: auto-detects the droplet's public IP/ID via the DO metadata
service, always assumes a public FQDN (no LAN/VLAN prompts), offers to
provision a matching DigitalOcean Cloud Firewall via doctl (never
touching one that's already attached), and documents droplet sizing,
firewall rules, and Sipnetic client setup in the generated README.
Claude