mrcharles
412d706abd
Session-start note (ground truth + design questions): https://projects.knownelement.com/issues/696#note-4086 No duplicate ticket: #696 (child of umbrella #694) already covers PMG deploy + MX cut-over; session gated on #696.
3.3 KiB
Questions — v7 (current round)
Round v6 carried below (badge Q4 still open). New this round: the Proxmox Mail Gateway pair (#696, child of #694) design questions PQ1–PQ7. Recommended defaults are stated per question — answering "defaults fine" (or naming exceptions) is enough.
PMG round (#696) — awaiting answers
PQ1. Mail domains + backend target?
Which domains' mail should flow through the PFV PMG pair (e.g.
knownelement.com, turnsys.com, thefnf.net)? And what sits behind PMG
as the delivery target — the Cloudron VPS in Reston VA? If so, which
hostname should PMG smarthost to (e.g. mail.<domain>)?
Ground truth: the internal Technitium knel.net zone has no MX
records; public MX lives at OVH/Cloudron (founder DNS).
PQ2. Inbound path from the internet? Recommendation: edge DNAT of SMTP :25 → both PMG nodes (LAN IPs), PMG filters then relays to the Cloudron backend. Which edge does the DNAT live on today — the rrinfra Cisco (existing), and are there any existing mail port-forwards I should be aware of?
PQ3. Outbound smarthost? Should LAN/Tailscale systems (hosts, VMs, appliances) relay outbound mail through PMG? If yes, confirm authorized source subnets for the allowlist. And Cloudron's own outbound: keep it direct (as today) or route it back through PMG too?
PQ4. VM placement + sizing? Recommendation: 2 VMs, each 2 vCPU / 4G RAM / 32G system disk (PMG is light). PMG-01 on tsys4, PMG-02 on tsys6 — honoring the standing ruling that tsys6/7 use USB storage only (PMG disks are small, fits fine). VMIDs: next free in the production range unless you want specifics. OK?
PQ5. Native PMG cluster or independent pair? Recommendation: PMG native clustering (config + quarantine DB replicates between the two), managed strictly serial with a health gate between hops per the blue/green house rule. OK?
PQ6. TLS from the fleet CA (#697)?
Recommendation: issue certs for pmg-01.knel.net / pmg-02.knel.net
from the tsys-ca intermediate for the admin UIs; SMTP keeps
opportunistic TLS (external senders never see our internal CA, so no
interop risk). OK?
PQ7. Quarantine + admin notifications? Defaults I'd apply unless you say otherwise: quarantine retention 7 days, daily quarantine digest to your admin address — which address should receive quarantine reports and PMG alerts?
Carried from v6 — still open
Q4. Second human approver in gitea? A (from v6): Founder: "planned for very near future." Until granted + named, KNEL/access-roster merges are IMPOSSIBLE by design (fail-safe). Does not block code/deploy work.
Carried from v6 — resolved
Q1. Door actuator path? Same 2018 hardware — usbrelay strike on pfvsvrpi (16c0:05df); usbrelay tool install is ticket-gated #356.
Q2. Reader model + badge format? Both readers = 13ba:0018 PCPlay PCP-BCG4209; pfvsvrpi aarch64/event0, ultix-field x86_64/event15; 24-byte records; 10-digit decimal + Enter.
Q3. Badge whitelist home? HA-side whitelist, materialized as separate repo KNEL/access-roster (see Q5).
Q5. Two-approval gate on roster home? RESOLVED 2026-09-02 — founder ruling: roster is 100% separate. Built: KNEL/access-roster (private, PR-only + two human approvals); holds roster/badges.yaml. doorman code repo de-gated. HA consumption owned by the pfv-bms session.