Commit graph

2 commits

Author SHA1 Message Date
Local Dev
bbef07c825 prometheus: 200 MiB upload cap + Caddy block fix for the "<" error
Two bugs under one roof.

The visible one: a publisher uploading anything over 10 MB on the live
site got "Network error — Unexpected token '<'" in the browser console.
Cause: the Caddy block I wrote for prometheus.x had
`request_body { max_size 2GB }` nested inside the handle block, where it
is a syntax Caddy parses but does not apply, so Caddy's own 10 MB
default was still the gate. Any oversize POST got Caddy's HTML 413 page,
which the browser's JSON parser choked on at the leading `<`.

Fix: moved `request_body { max_size … }` to the top of the prometheus.x
site block (outside `handle`), where Caddy actually honours it. The live
Caddyfile on p2pexchange is already patched + reloaded; a 50 MB upload
verified through the end-to-end path (Caddy → service → clamd → signed
scan report).

The scope one: 2 GiB was more than Prometheus should offer to publishers
at launch. Mobile apps are usually ~100 MB and even most desktop
installers come in well under 200 MiB. Dropping to 200 MiB:

  - Fits every Android APK and most desktop installers.
  - Shrinks the operator's Sia storage bill (fewer accidental Steam-size
    uploads).
  - Keeps the "publishers of larger binaries self-host and submit a
    manifest with the external URL + SHA" escape hatch — the scanner
    still fetches the URL and checks the hash, so a 5 GB game isn't
    locked out, Prometheus just doesn't eat its storage.

Changes:
  service/uploads.js       MAX_FILE_BYTES default: 2 GiB → 200 MiB
  service/pages.js         /submit step-1 subtitle: "any size up to
                           2 GiB" → "up to 200 MiB"
  deploy/prometheus-x.conf (unused angie fallback) 2g → 200m
  deploy/apps-silentmode-st.conf (unused angie fallback) 2g → 200m

PROMETHEUS_MAX_UPLOAD_BYTES env still overrides per-instance.
2026-10-22 23:20:19 +03:00
Local Dev
40bf5fc641 prometheus: deploy — systemd unit, angie vhost, TLS pin, deploy recipe
Everything the VPS needs to run Prometheus is in Prometheus/deploy/:

  prometheus-service.service   systemd unit, Node on 127.0.0.1:3700,
                               ReadWritePaths narrowed to the dirs the
                               service actually writes (db, uploads, keys,
                               build). Hardened with NoNewPrivileges,
                               PrivateTmp, ProtectSystem=strict,
                               ProtectHome. Reads /etc/default/prometheus
                               for instance env (admin name, VT key,
                               payment config) so the repo carries no
                               per-install secrets.

  prometheus-x.conf            angie vhost for the BNS name's apex.
                               TLS-terminated with a self-signed cert that
                               the on-chain `tls` record pins (no CA
                               involved). Reverse-proxies / to the Node
                               service, 2 GiB client_max_body_size for
                               POST /api/upload, proxy_request_buffering
                               off so large uploads do not spool to disk.

  make-tls-cert.sh             ECDSA P-256, 10-year expiry (the on-chain
                               pin is what actually expires, not the cert
                               metadata). Prints the DER sha256 that goes
                               in the `tls` record. Idempotent — rerun to
                               rotate.

  README.md                    First-time install recipe (useradd →
                               rsync → npm install --omit=dev → make-tls
                               → angie reload → systemctl enable --now),
                               the matching Argus register.js command for
                               the record change, update + rollback.

Execution — the deploy itself, the record change, enabling payments —
is the operator's call, not something a script here runs on its own.
2026-10-08 21:53:40 +02:00