Skip to content

v0.9.46-alpha — Fed Hub co-location guard + split remote-server hardening

Choose a tag to compare

@takwerx takwerx released this 07 Jun 12:36

Headline: two areas, both surfaced by a field-reported split (two-server) deployment.

Federation Hub — no co-location with TAK Server

Running Federation Hub on the same OS as TAK Server means two JVMs + two databases on one box: the hub's JVM + MongoDB contending with TAK Server's JVM + Postgres for RAM (MongoDB alone defaults to ~50% of system memory), and a single outage takes down both.

  • The Deployment Target page now disables the "this machine (local)" option and forces a separate SSH target when TAK Server is installed on the box, with a clear explanation.
  • A dedicated console host with no TAK Server still deploys the hub locally (e.g. a box stood up just to run Federation Hub).
  • An already-deployed local hub is grandfathered with a "migrate to a separate host recommended" notice — nothing breaks.
  • The gate is enforced in the backend (config coercion + deploy refusal), not just the UI. A separate VM on the same physical host is a valid target — the rule is only "not the same OS as TAK Server."

Split remote DB — Health Agent reachable on private-LAN splits

On a two-server deployment where the console and the database talk over a private/provider LAN, the Guard Dog Health Agent could sit yellow/red forever.

  • The remote DB server's :8080 UFW rule was pinned to the configured server_ip, but the console's actual source IP toward the DB box can differ (private-LAN egress) — so the health poll was silently denied. It's now scoped to the IP the DB box actually observes from the console ($SSH_CLIENT) ∪ server_ip.
  • UFW rule-ORDER fix: UFW appends rules and is first-match-wins. A pre-existing deny <port>/tcp from an earlier deploy sat above a freshly-added scoped allow, so the deny kept winning. The deploy now deletes the deny first, adds the scoped allow, then re-adds the deny last. (This was the fix that turned the field reporter's Health Agent green.)

Security — Postgres 5432 and Fed Hub UI 8080/9100 closed to the internet

Earlier builds could leave these ports ALLOW Anywhere:

  • Remote Postgres 5432 — the TAK database reachable from the public internet (a scoped allow was added in a prior release, but the legacy broad ALLOW Anywhere was never deleted, and UFW first-match-wins kept it open). Now the broad allow is deleted and the port is scoped to the core + denied to the world, with the scoped allow added first so TAK never loses its database. (Note: the takserver-database package rewrites postgresql.conf/pg_hba.conf to listen_addresses='*' on every upgrade — UFW is the durable protection, and the hardened rule survives upgrades.)
  • Federation Hub UI 8080 (HTTP) / 9100 (HTTPS) — the hub admin UI, including plaintext 8080, was internet-reachable. Now scoped to the console (Caddy) source IP and denied elsewhere; federation peer ports 9101–9103 stay open by design.
  • The Fed Hub firewall now re-converges on every console restart (a startup migration), so an exposed hub is closed without a disruptive .deb Update — no hub restart, no federation drop.

Guard Dog DB-auth — XML-entity passwords + real errors

  • The DB-auth check read the martiuser password from CoreConfig.xml and used it verbatim. If a TAK-generated password contained an XML-special character (&/</>/"/'), CoreConfig stores it escaped (&amp;…) — TAK's JDBC decodes it, but the check didn't, so auth false-failed even though TAK was connected. It now html.unescape()s the password like JDBC does.
  • The check no longer hides the PostgreSQL error: it now surfaces the real reason (password authentication failed vs no pg_hba entry vs missing database) instead of a blanket "rejected".

Cosmetic

  • Remote VACUUM/REINDEX no longer leak a harmless-but-alarming could not change directory to "/root": Permission denied warning (the command always ran; the SSH session just landed in /root). The remote path now cd / first, matching the local path.

Validation

Field-validated on three dev boxes (test6/test8/test12, ~95-minute soak on the final SHA, zero console errors, no regressions through a full TAK Server RELEASE8→43 upgrade) and on the original field reporter's split deployment (DB-auth, Health Agent, and VACUUM all confirmed green on the box that actually had the bugs).