mrcharles
041d311d1c
Answers landed 2026-09-03: Bitwarden/Vault = cred SoR (.creds bootstrap-only); this chat = COO/C2-only (PM/policy/enablement), agent stack lives here; docker(988) verified on all 7 TSG*/COS* officer accounts.
136 lines
7.0 KiB
Markdown
136 lines
7.0 KiB
Markdown
> Working ask-file; knowledge docs live on Discourse: https://community.turnsys.com/c/vp-techops (audit log: https://community.turnsys.com/t/298)
|
||
# questions-09022206.md — consolidated open asks (2026-09-02)
|
||
|
||
> Merged from `questions-v2.md` (repo root) + `HomeAssistant/needfromcharles.md`
|
||
> per founder request; both source files since removed (history in git).
|
||
> Answer inline; agent checks before asking again.
|
||
|
||
## HA / monitoring (was needfromcharles)
|
||
|
||
### 1. Minisplit (Midea/Carrier) — blocks #614
|
||
Login `charles@turnsys.com` rejected by all three Midea cloud backends.
|
||
- [ ] Exact app name on your phone that controls the minisplit:
|
||
- [ ] Account email that app uses:
|
||
|
||
### 2. Govee — blocked on hardware path (#620/#683)
|
||
Integration live (key+account+MQTT); account has ZERO cloud devices = BLE-only.
|
||
- [ ] Sensor model numbers (decides BLE dongle vs hub):
|
||
- [x] API key — received + configured (2026-09-02)
|
||
|
||
### 3. HomeKit codes — blocks #619 pairing (ecobee multicast-reachable NOW)
|
||
- [ ] ecobee 8-digit code:
|
||
- [ ] Lock brand/model: (verdict 2026-09-02: BLE-only — DHCP can't name it)
|
||
- [ ] Lock HomeKit code:
|
||
|
||
### 4. Emporia Vue 3 — blocks #623 (BTU loop)
|
||
- [ ] Ordered? ETA:
|
||
|
||
### 9. iDRAC — RESOLVED 2026-09-02
|
||
[x] Creds worked; both SNMP agents live; tsys6 `public` accepted by founder.
|
||
|
||
### NEW (2026-09-02)
|
||
### 10. DVR → MotionEye (#711)
|
||
- [ ] DVR login (any user):
|
||
- [ ] Channel count:
|
||
(Night Owl; RTSP format documented on #711)
|
||
|
||
### 11. DIRIGERA Matter code (#712) — when you're back at the house
|
||
- [ ] IKEA app → hub → integrations → share via Matter (11-digit code)
|
||
|
||
### 12. WiZ bulb→room mapping (#712) — Friday onsite
|
||
2 bulbs reserved (pfv-wiz-bulb-1/2 @ 192.168.1.150/.151); map MACs→rooms, then
|
||
HA WiZ entries by host + we identify the other ~11 lights' integration.
|
||
|
||
## General (was questions-v2)
|
||
|
||
### Q7. Close #167 (old garage UPS rebuild, superseded)? — still open
|
||
### Q9. Session-start gate relaxation — superseded by scope-alignment gate
|
||
### Q10. Git flow: keep direct-push for PFVCluster? — still open (default: keep)
|
||
(Q8 Friday order — moot, that Friday passed)
|
||
|
||
## Founder decisions pending
|
||
- #626 Cloudron HA access architecture (a/b/c on ticket — recommend proxy)
|
||
- #684 PBS session scheduling (+ drive-rotation target design)
|
||
- TasmoAdmin uninstall (stopped+disabled 2026-09-02 — full uninstall?)
|
||
- Govee disabled dup entry: one-click delete in HA UI
|
||
|
||
### 13. Cloudron API token (#685/#727) — unblocks API-first access
|
||
The #685 perf investigation ran over raw SSH (root@my.knownelement.com) because
|
||
no panel API token exists. A token (read scope minimum) lets the agent use the
|
||
Cloudron API (apps/configs/backups) instead of shell — cleaner audit trail and
|
||
the path for AWX/Ansible modules. Also tracked in KNEL/cloudron
|
||
questions-v1.md (https://git.knownelement.com/KNEL/cloudron).
|
||
- [x] Create token (panel: my.knownelement.com → profile → API access) — received 2026-09-02
|
||
- [x] Material value stored → ~/.creds/cloudron.env (0600; API verified: profile mrcharles, apps 200)
|
||
|
||
### 14. docker daemon.json bounce window — my.knownelement.com (#727)
|
||
One planned dockerd restart (ALL ~300 containers bounce; live-restore=false
|
||
today, so no zero-downtime path) to apply nofile 262144 defaults + log
|
||
rotation + live-restore. Script ready: KNEL/cloudron
|
||
perf/docker-daemon.json.planned. Until then the postgres nofile bridge is
|
||
ephemeral (lost on postgres container recreate). Detail: t/316.
|
||
- [x] Pick a window — DONE 2026-09-02 ~19:30 CDT: applied (live-restore + nofile 262144 defaults); first-attempt log-driver conflict incident documented on #731
|
||
|
||
## CMDB change-control rulings needed (#705 P0 live → P2/P3)
|
||
|
||
### C1. CR itemtype for the 7-state workflow
|
||
GLPI natively has both Ticket and Change. The t/319 workflow
|
||
(Draft→Review→Approved→Scheduled→Implemented→Verified→Closed) maps most
|
||
cleanly onto GLPI **Changes** (validation/plan/approval fields built in),
|
||
with Tickets for break-fix. Recommend: Changes for CRs, Tickets stay for
|
||
incidents; both linked to the CI they touch.
|
||
|
||
### C2. Write access for the cmdb agent in the CR phase
|
||
Agent is Read-Only today (verified). If CRs live in GLPI, the agent needs
|
||
to CREATE/transition them — recommend adding the Self-Service profile
|
||
alongside Read-Only (can open + follow own items, still can't edit CIs).
|
||
Alternative: CRs enter via Redmine only and GLPI stays read-only for now.
|
||
|
||
### C3. #307 → GLPI refresh cadence
|
||
from-inventory.sh regenerates the CSV from the Discourse #307 raw;
|
||
to-glpi.sh is idempotent by name. Recommend folding "refresh #307 →
|
||
regenerate → import → report diff" into the daily 09:00 C2 housekeeping.
|
||
Related data-quality: #307 §5 has `pfvsvrki.knel.net` typo; 14
|
||
stale-dns-record CIs need reconcile-or-delete ruling.
|
||
|
||
## Agent-stack rulings needed (#767 — after TSGCOO tree discovery 2026-09-03)
|
||
|
||
### C4. Credentials policy — one statement, please
|
||
Three coexisting models: Bitwarden (TSGCOO's bw-run.sh design — replaces ~/.creds for
|
||
agent/system creds), ~/.creds 0600 (current house rules), Vaultwarden (your app-secrets
|
||
ruling). Proposed: Bitwarden = agent + system API credentials going forward (~/.creds
|
||
deprecated as #478 ingests them), Vaultwarden stays for app-internal secrets. Confirm?
|
||
|
||
> **ANSWERED 2026-09-03 (Charles):** Bitwarden/Vault is the SoR — "its the latter."
|
||
> ~/.creds is a bootstrap mechanism for convenience only (same as using the
|
||
> reachableceo linux/cloudron account as a bootstrap identity). Going forward: new
|
||
> agent/system credentials land in Bitwarden; ~/.creds materializes bootstrap copies.
|
||
|
||
### C5. #767 scope split
|
||
This chat owns the CR escalation ladder + GLPI Changes wiring + mechanical gates
|
||
(ticket-gate CR check, X-Consumer attribution); TSGCOO's lane owns identity provisioning
|
||
execution (#442/#478). Confirm the seam?
|
||
|
||
> **ANSWERED 2026-09-03 (Charles):** No split — **this chat is COO/C2 only going
|
||
> forward** (project management, policy making, enablement). The agent stack IS
|
||
> enablement → it lives HERE, end-to-end (design + provisioning execution). Dedicated
|
||
> chats get spun up for any work that isn't PM/policy/enablement. TSGCOO's existing
|
||
> tree is prior art feeding this chat, not a separate lane.
|
||
|
||
### C6. Resume TSGCOO's blockers?
|
||
Q1-Q6 in org-buildout/questions-v1.md + #478 stage-2 re-gate. I can clear Q1 (docker
|
||
group for TSGCOO) now — say the word. Invite links (Q3) + Gitea token (Q4) are yours.
|
||
|
||
> **ANSWERED 2026-09-03 (Charles):** "yes give all of the TSG* and COS* accounts docker
|
||
> group access. that is super critical for all them to work." → VERIFIED ALREADY IN
|
||
> PLACE: docker(988) confirmed on all 7 officer accounts (TSGCOO, TSGCCO, TSGCTO,
|
||
> TSGBOD, COS-RCEO, COS-WFO, COS-TSG). Org-buildout Q1 closed. Q3 (Cloudron invite
|
||
> links ×9) + Q4 (Gitea push token) remain Charles's.
|
||
|
||
### C7. Leaked vptechops Gitea token
|
||
Listed in a KNELSecretsManager remote URL — rotate at your convenience (your console,
|
||
not my lane).
|
||
|
||
### C8. GLPI Changes vs Tickets (was C1)
|
||
Still the blocking ruling for the whole CR wiring — see C1 above (recommend Changes).
|