Skip to main content

TISC Editor — history & operations

Dated operations for srv-tisc-editor (LXC 123 on rumba), newest first. Current state is on the TISC Editor page.

2026-09-18 — migrated off marcellus, published, AUTH_URL fixed​

The service moved from the legacy Infomaniak VPS marcellus (tisc.isc-vs.ch / tisc.isc-vs.dev, external VPS) to its own guest on the rack — the first item closed on that host's decommissioning list.

  • Guest: LXC 123 srv-tisc-editor already existed on rumba with the Docker stack (tisc-app-prod / tisc-docs / tisc-nginx / tisc-db) running and healthy, nginx bound to 192.168.88.36:8082. net0 was moved from a plain DHCP lease to a static 192.168.88.36/24; a MikroTik DHCP reservation for the guest's MAC was added on the CCR2004 so the address cannot be handed to another device, and static internal DNS records srv-tisc-editor / srv-tisc-editor.isc3 → 192.168.88.36 were added there too.
  • Public DNS: tisc.isc-vs.ch CNAME'd to rumba.isc-vs.ch at Infomaniak (self-service in the isc-vs.ch zone, TTL 300). A first attempt pointed at the wrong target (marcellus.isc-vs.ch, itself a stale alias to the legacy VPS) and was caught and corrected before the Caddy vhost went live, by checking the CNAME with DNS-over-HTTPS ahead of time — the standing trap (this network intercepts port 53, and an enabled vhost against a non-resolving/wrong name burns Let's Encrypt's failed-validation limit).
  • Reverse proxy: vhost added to provisioning/web/Caddyfile — tisc.isc-vs.ch { reverse_proxy srv-tisc-editor:8082 }, by internal DNS name rather than IP (see the standing caution). Pushed with the same manual steps deploy.sh uses (pct push + caddy validate + systemctl restart caddy on srv-web01); Let's Encrypt issued a certificate for tisc.isc-vs.ch immediately once the vhost loaded against a resolving name.
  • marcellus.isc-vs.ch decommissioned: the DNS records at Infomaniak referencing the legacy VPS by that name were removed the same day — now NXDOMAIN.
  • AUTH_URL bug: the app came up with AUTH_URL=http://192.168.88.36:8082 in /root/tisc-editor/.env (baked in by whoever first ran publish_new_version.sh on this guest — the script only defaults to https://tisc.isc-vs.dev when AUTH_URL is unset). Auth.js builds every login redirect from that value rather than from the request's X-Forwarded-* headers, so every visitor — VPN or not — got Location: http://192.168.88.36:8082/login...; only VPN clients could actually follow it, which is what made the symptom look network-related rather than configuration. Fixed by editing .env (AUTH_URL=https://tisc.isc-vs.ch, plus AUTH_TRUST_HOST=true) and re-running ./publish_new_version.sh with no --db — rebuilds and recreates tisc-app-prod / tisc-docs / tisc-nginx, tisc-db and its data untouched. Verified afterwards: Location now says https://tisc.isc-vs.ch/login..., confirmed both through normal DNS resolution and by hitting the public IP directly with curl --resolve (proves it for any visitor, VPN or not). Old .env kept as /root/tisc-editor/.env.bak-2026-09-18 on the guest.