Cross-repo documentation audit against argus-appliance's real current feature set
(v3.79.80): added a Reports Center bullet (guided JSON/CSV/HTML reporting, honestly scoped —
no PDF/scheduling/compliance templates yet) and expanded the Attack Origin Visualization bullet
with the two real additions from the appliance's Attack Operations Center follow-on (attack-type
coloring, fullscreen SOC wall mode).
Moved this changelog's own "not kept in sync" disclosure from a buried trailing note to the top
of the file, right under the title, so a reader sees it before the stale entries rather than
after — same honest content, just where it's actually useful.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The service's own comment already claimed "list/inspect/exec/restart
existing containers" capability, but ALLOW_RESTARTS was never actually set
-- restart was silently unavailable. Needed for argus-appliance#43's new
Diagnostics "Restart Container" recovery action, which is the first real
caller.
Deliberately narrow, per explicit product decision: restart only (stop/
restart/kill on an *existing* container). create/prune remain denied by
the haproxy template's own explicit deny-list regardless of this or any
POST setting. start/stop (ALLOW_START/ALLOW_STOP) deliberately left unset
-- nothing needs them yet.
Root cause of a real production failure on the first live install
(wap-proxy, 2026-07-25): DB_PASSWORD was generated with
`openssl rand -base64 24`, which can produce '/', '+', or '=' --
docker-compose.yml then naively interpolated the raw password into
postgres://postgres:${DB_PASSWORD}@db:5432/..., and a generated
password containing '/' broke the connection string outright. The API
never became healthy; log ingestion failed completely.
- install.sh now generates with `openssl rand -hex 32` (always
[0-9a-f], can't produce this class of character). Same fix applied
everywhere else openssl-rand-base64-24 was referenced.
- docker-compose.yml no longer builds DATABASE_URL by string
interpolation -- DB_PASSWORD is passed as its own var and the API
assembles the connection string safely internally using
net/url.UserPassword (proper percent-encoding), a second,
independent layer so the installer doesn't rely on the password
generator alone. See the matching argus-appliance commit for the
Go-side change and its regression test.
- backup.sh/healthcheck.sh/restore.sh/uninstall.sh still defaulted
ARGUS_INSTALL_DIR to $HOME/argus, inconsistent with install.sh/
update.sh's own /opt/argus default (changed in an earlier commit
this session) -- confirmed live on the same install: healthcheck.sh
and uninstall.sh reported "no installation found" when run from the
real, correct directory. All five scripts now agree on /opt/argus.
Corresponding argus-appliance fix (config.go's buildDatabaseURL, v3.73.1)
already built and pushed to git-cloud.weboria.eu/weboria/argus-api.
Three corrections, driven by explicit product decisions plus code
verification:
- There is no self-hosted-ANIS deployment model going forward. ANIS_URL
is now hardcoded to https://anis.weboria.eu in docker-compose.yml, not
a customer-configurable env var -- removed from env.example and the
README entirely.
- The ANIS license key is dashboard-only (Threat Intel -> ANIS
Connection, write-only there per the earlier security fix) -- never
set via .env. ANIS_LICENSE_KEY hardcoded to an empty string in
docker-compose.yml (community tier by default) rather than left as a
pass-through env var with no real path to ever being set.
- Removed ANIS_SHARE_ATTACKERS -- confirmed dead via grep, zero
references anywhere in the Go source. This was incorrectly kept as
"real" in the previous env.example cleanup pass; ROADMAP.md in the
appliance repo already documented this exact variable as dead.
ANIS_ENABLED remains the one real customer-facing ANIS toggle.
tech
