KNEL/PFVCluster
6
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

answered

Browse Source
This commit is contained in:
reachableceo
2026-09-03 23:12:37 -05:00
parent 6173be60b7
commit c0f71756ee
1 changed files with 28 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
questions-v10.md
+28
View File
@@ -23,31 +23,45 @@ from v9 carried at the bottom. One-line answers fine.
ruling, matching PFVCluster's class. OK, or flip some/all private ruling, matching PFVCluster's class. OK, or flip some/all private
(one-click each; say which)? (one-click each; say which)?
A: public is fine
**OQ2 (legacy overlaps).** Old repos `TSYS-CA` and `KNELSecretsManager` **OQ2 (legacy overlaps).** Old repos `TSYS-CA` and `KNELSecretsManager`
overlap the new `ca` / `secrets`. Archive them into the new scheme overlap the new `ca` / `secrets`. Archive them into the new scheme
(redirect README), or leave as-is? (redirect README), or leave as-is?
A; port them both to the new respective repository as it makes sense
**OQ3 (apt-satellite design).** Recommend: start with a flat pinned-mirror **OQ3 (apt-satellite design).** Recommend: start with a flat pinned-mirror
(the #758 tsys-ca pattern), graduate to aptly when the fleet grows. (the #758 tsys-ca pattern), graduate to aptly when the fleet grows.
Approve? Approve?
Yes
**OQ4 (Prometheus placement).** Recommend: Prometheus + Alertmanager on **OQ4 (Prometheus placement).** Recommend: Prometheus + Alertmanager on
tsys-librenms alongside LibreNMS (same vantage, no new VM); Grafana stays tsys-librenms alongside LibreNMS (same vantage, no new VM); Grafana stays
on Cloudron. Approve, or name a host? on Cloudron. Approve, or name a host?
No. Stay on cloudron.
**OQ5 (Kuma window automation).** `~/.creds/uptime-kuma.env` exists — may I **OQ5 (Kuma window automation).** `~/.creds/uptime-kuma.env` exists — may I
wire it into `pve-snapshot.sh` so rollbacks auto-create the maintenance wire it into `pve-snapshot.sh` so rollbacks auto-create the maintenance
window (and close it after), instead of the current manual reminder? window (and close it after), instead of the current manual reminder?
Yes
**OQ6 (preprod ownership).** The 531xx preprod lane on tsys5: is THIS lane **OQ6 (preprod ownership).** The 531xx preprod lane on tsys5: is THIS lane
the driver for vendor-version soak (~1wk, then promote), with per-domain the driver for vendor-version soak (~1wk, then promote), with per-domain
chats consulted? Or per-stack? chats consulted? Or per-stack?
Hmmm. Not sure. I think this lane we map it out and test . And develop the proxsss and run the promotions / soak per stack . Analyze and report / retort please.
**OQ7 (GLPI changes during converge loops).** Until GLPI change-control is **OQ7 (GLPI changes during converge loops).** Until GLPI change-control is
ruled (#705/#741): sectestbed playbook iterations stay Redmine-ticket-only, ruled (#705/#741): sectestbed playbook iterations stay Redmine-ticket-only,
exception requests noted in the ticket. OK, or start logging GLPI Changes exception requests noted in the ticket. OK, or start logging GLPI Changes
now? now?
Start now
**OQ8 (pfv-bms → KNELBMS rename).** Deferred per your golden rule (HA chat **OQ8 (pfv-bms → KNELBMS rename).** Deferred per your golden rule (HA chat
active). Confirm the rename lands with the HA chat once you bless it — this active). Confirm the rename lands with the HA chat once you bless it — this
lane will not touch it. lane will not touch it.
@@ -57,18 +71,28 @@ lane will not touch it.
**PQ5 (native PMG cluster?).** Recommended: yes — config + quarantine **PQ5 (native PMG cluster?).** Recommended: yes — config + quarantine
replication between .1.11/.1.10, managed strictly serial. OK? replication between .1.11/.1.10, managed strictly serial. OK?
Yes.
**PQ6 (TLS from fleet CA #697?).** Recommended: yes for the two admin **PQ6 (TLS from fleet CA #697?).** Recommended: yes for the two admin
UIs; SMTP stays opportunistic. UIs; SMTP stays opportunistic.
Yes
**PQ7 (notify address).** Confirm `coo@turnsys.com` for PMG alerts + **PQ7 (notify address).** Confirm `coo@turnsys.com` for PMG alerts +
held-mail notices? held-mail notices?
Yes . For all root and postmaster etc mail
**PQ8 (VIP specifics).** Confirm VIP 192.168.3.249 + `smtp.knel.net` + **PQ8 (VIP specifics).** Confirm VIP 192.168.3.249 + `smtp.knel.net` +
dhcpd host-decl pin (VRRP MAC 00:00:5e:00:01:0a)? dhcpd host-decl pin (VRRP MAC 00:00:5e:00:01:0a)?
Yea
**PQ9 (outbound cutover staging).** Serial staged: PVE hosts + PBS first **PQ9 (outbound cutover staging).** Serial staged: PVE hosts + PBS first
(verify a week), then VM postfix. OK? (verify a week), then VM postfix. OK?
Yes
**PQ11 (Cloudron relay user — founder side).** Create `pfv-relay@turnsys.com` **PQ11 (Cloudron relay user — founder side).** Create `pfv-relay@turnsys.com`
for PMG submission, or point me at who does? Fallback: PMG delivers direct for PMG submission, or point me at who does? Fallback: PMG delivers direct
to recipient MXs. to recipient MXs.
@@ -76,10 +100,14 @@ to recipient MXs.
**PQ12 (k8s submission port).** :25 unauthenticated from trusted LAN as **PQ12 (k8s submission port).** :25 unauthenticated from trusted LAN as
default; :587+auth later if wanted. OK? default; :587+auth later if wanted. OK?
Yes
**PQ10 (side findings — ticket placement).** (a) tsys-ucs-02 root alias **PQ10 (side findings — ticket placement).** (a) tsys-ucs-02 root alias
blackhole; (b) Wazuh alerting never configured (#335). Ride-alongs in #696 blackhole; (b) Wazuh alerting never configured (#335). Ride-alongs in #696
or separate sub-tickets? or separate sub-tickets?
As you wish. I don’t have an option either way. Get outbound mail working everywhere.
## Carried from v6 — still open ## Carried from v6 — still open
**Q4. Second human approver in gitea?** Blocks access-roster merges by **Q4. Second human approver in gitea?** Blocks access-roster merges by