feat(oam): codify garage-pdu-relay snmpd extend + timeout hardening [#733]
Deployed manually on tsys-librenms 2026-09-02 (founder relay ruling); codified same-day rule. snmpget -t2 -r1 so a dark PDU answers in ~2s. Deployed target: tsys-librenms:/usr/local/bin/garage-pdu-relay. Detail: https://projects.knownelement.com/issues/733
This commit is contained in:
@@ -0,0 +1,69 @@
|
||||
# Questions — v9 (current round)
|
||||
|
||||
v8's open items are now settled by the founder's 2026-09-03 chat
|
||||
ruling: **OUTBOUND ONLY** — all PFV hosts (k8s included) send via the
|
||||
gateway; no inbound ever; no DNAT, no MX cut-over (that scope is
|
||||
dropped from #696). Robustness is a stated requirement (VIP pair,
|
||||
queueing, cluster, monitoring). Map + target architecture updated in
|
||||
place: [Discourse t/322](https://community.turnsys.com/t/322).
|
||||
|
||||
## PMG round — resolved
|
||||
|
||||
**PQ1 (backend).** Cloudron VPS `mail.knownelement.com`
|
||||
(152.53.37.179); public MX already points there; fleet delivers
|
||||
direct today; knel.net zone has no MX (and never needs one now).
|
||||
|
||||
**PQ2 (inbound path).** ✅ N/A by ruling — outbound only. No DNAT, no
|
||||
MX work, ever.
|
||||
|
||||
**PQ3 (outbound smarthost).** All hosts through the gateway VIP.
|
||||
|
||||
**PQ4 (placement/sizing).** Pair already exists: VM 604 tsys6
|
||||
(192.168.1.11) + VM 711 tsys7 (192.168.1.10), PMG 9.1.0, unclustered.
|
||||
|
||||
**"Old relay in postfix?"** None — `relayhost` empty fleet-wide.
|
||||
|
||||
## PMG round — still open (one-line answers fine)
|
||||
|
||||
**PQ5 (native PMG cluster?).** Recommended: yes — config + quarantine
|
||||
replication between .1.11/.1.10, managed strictly serial. OK?
|
||||
|
||||
**PQ6 (TLS from fleet CA #697?).** Recommended: yes for the two admin
|
||||
UIs; SMTP stays opportunistic (all flows are internal + to Cloudron).
|
||||
|
||||
**PQ7 (notify address).** Pair already forwards to `coo@turnsys.com`.
|
||||
Confirm for PMG alerts + any held-mail notices?
|
||||
|
||||
**PQ8 (VIP specifics).** Confirm **VIP 192.168.3.249** + name
|
||||
`smtp.knel.net` + dhcpd host-decl pin (VRRP MAC 00:00:5e:00:01:0a)?
|
||||
Or name your preferred slot/name.
|
||||
|
||||
**PQ9 (outbound cutover staging).** Recommended: serial staged — PVE
|
||||
hosts + PBS first (verify a week), then VM postfix set. OK?
|
||||
|
||||
**PQ11 (Cloudron relay user — founder side).** Recommended pattern:
|
||||
PMG authenticates to a dedicated Cloudron mail user (e.g.
|
||||
`pfv-relay@turnsys.com`) over :587 submission, so fleet mail exits
|
||||
with Cloudron's rDNS/reputation. Will you create that user (or point
|
||||
me at who does)? Fallback if you'd rather not: PMG delivers direct to
|
||||
recipient MXs (same egress as today, no deliverability gain).
|
||||
|
||||
**PQ12 (k8s submission port).** Recommended: :25 unauthenticated from
|
||||
trusted LAN (pod traffic SNATs to node IPs) as the default; optional
|
||||
:587+auth later if you want app-level credentials. OK as default?
|
||||
|
||||
**PQ10 (side findings — sub-ticket placement).** (a) tsys-ucs-02 root
|
||||
alias blackholes to `systemmail@unassigned-hostname...`; (b) Wazuh
|
||||
alerting never configured (stock example smtp). Ride-alongs in #696
|
||||
or separate sub-tickets? They get tickets either way — just say where.
|
||||
|
||||
## Carried from v6 — still open
|
||||
|
||||
**Q4. Second human approver in gitea?** "Planned for very near
|
||||
future"; until then KNEL/access-roster merges are impossible by
|
||||
design. Does not block code/deploy work.
|
||||
|
||||
## Superseded
|
||||
|
||||
v7 PQ wording and v8 PQ10 ordering are superseded by the rulings
|
||||
above; v7/v8 files remain in git history.
|
||||
Reference in New Issue
Block a user