vh/esh-pfi-infrastructure
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

memory: NH3 Mac mini asleep; fix tomorrow on site

Browse Source
This commit is contained in:
vh
2026-10-03 16:23:15 -07:00
parent 453c927ace
commit d4c5ae8d00
1 changed files with 1 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
persistent-memory.md
+1
View File
@@ -131,6 +131,7 @@ _As of 2026-10-03 ~1440 PT. The newest subsection is first; older subsections ca
- **RustDesk server (ana-docker) updated 1.1.14 → 1.1.16 at 1424** (same key; ports 21115-21119 reachable via rustdesk.phasefinal.com). Private key vaulted first as `ana-docker/rustdesk/id_ed25519`. "Change ID" is refused by the OSS server BY DESIGN (Pro feature; `rendezvous_server.rs` answers TCP RegisterPk with NOT_SUPPORT). Workaround, read at client source and untested: stop RustDesk, delete `enc_id` from RustDesk.toml, set a plain `id`, restart. → `servers/ana-docker/README.md` - **RustDesk server (ana-docker) updated 1.1.14 → 1.1.16 at 1424** (same key; ports 21115-21119 reachable via rustdesk.phasefinal.com). Private key vaulted first as `ana-docker/rustdesk/id_ed25519`. "Change ID" is refused by the OSS server BY DESIGN (Pro feature; `rendezvous_server.rs` answers TCP RegisterPk with NOT_SUPPORT). Workaround, read at client source and untested: stop RustDesk, delete `enc_id` from RustDesk.toml, set a plain `id`, restart. → `servers/ana-docker/README.md`
- **Booth vs 10.100.10.166 (Prime, ~1420): that client cannot reach the Booth.** The Booth was up and answered from 4 hosts at 1417; .166 is on nh3-dev's own subnet. Prime interrupted my check, so it is OPEN and resumes only on his word. - **Booth vs 10.100.10.166 (Prime, ~1420): that client cannot reach the Booth.** The Booth was up and answered from 4 hosts at 1417; .166 is on nh3-dev's own subnet. Prime interrupted my check, so it is OPEN and resumes only on his word.
- **esh-nas-pve → PVE 9: PREP + PVE 8 REBOOT TEST DONE (1533-1546, Prime on site).** Prep playbook `playbooks/esh-nas-pve-pve9-prep.yaml`; backups 103-107 on pbs-ana; came back on 6.8.12-43 with the pinned names. Two foot-guns are logged in the plan doc: VM 101's first start times out while its NFS recovers (retry), and mosquitto does not auto-restart on VM 100. **DONE 1606: esh-nas-pve is ON PVE 9.2.21 / kernel 7.0.14-20** (Prime go; ESH DNS stayed up; the /boot-LV-full trap is fixed and written up in the plan doc). Keep `nvme/ROOT@pre-pve9` about a week, then destroy it. **`pve` (esh-pve) is still on 8.4.20; its upgrade is a separate, bigger window** (DNS VM, the CT 108 mesh router, esh-ml1 with NVIDIA, so it needs `proxmox-default-headers` + a /boot check first). (Earlier assessment, kept:) Prime asked (1440) whether I can do it myself. Assessed read-only and ANSWERED. Facts: QNAP hardware, no AMT/IPMI (no remote console); PVE 8.4.20 but running kernel 6.8.12-13; up since 2026-08-18; ZFS root `nvme` booted by GRUB; systemd-boot meta present; NO NIC pins (uplink `enp5s0f0`); no DKMS. My answer: I can do all the prep remotely (vzdump, NIC pin, remove systemd-boot, root snapshot, pve8to9, a reboot test on PVE 8 first). The upgrade reboot should happen only with someone able to reach ESH, or with Prime's explicit acceptance of a no-console failure. VMs 100/101 on `pve` must be shut down first (hard NFS mounts). → `docs/runbooks/esh-pve-cluster-pve9-upgrade-plan.md` - **esh-nas-pve → PVE 9: PREP + PVE 8 REBOOT TEST DONE (1533-1546, Prime on site).** Prep playbook `playbooks/esh-nas-pve-pve9-prep.yaml`; backups 103-107 on pbs-ana; came back on 6.8.12-43 with the pinned names. Two foot-guns are logged in the plan doc: VM 101's first start times out while its NFS recovers (retry), and mosquitto does not auto-restart on VM 100. **DONE 1606: esh-nas-pve is ON PVE 9.2.21 / kernel 7.0.14-20** (Prime go; ESH DNS stayed up; the /boot-LV-full trap is fixed and written up in the plan doc). Keep `nvme/ROOT@pre-pve9` about a week, then destroy it. **`pve` (esh-pve) is still on 8.4.20; its upgrade is a separate, bigger window** (DNS VM, the CT 108 mesh router, esh-ml1 with NVIDIA, so it needs `proxmox-default-headers` + a /boot check first). (Earlier assessment, kept:) Prime asked (1440) whether I can do it myself. Assessed read-only and ANSWERED. Facts: QNAP hardware, no AMT/IPMI (no remote console); PVE 8.4.20 but running kernel 6.8.12-13; up since 2026-08-18; ZFS root `nvme` booted by GRUB; systemd-boot meta present; NO NIC pins (uplink `enp5s0f0`); no DKMS. My answer: I can do all the prep remotely (vzdump, NIC pin, remove systemd-boot, root snapshot, pve8to9, a reboot test on PVE 8 first). The upgrade reboot should happen only with someone able to reach ESH, or with Prime's explicit acceptance of a no-console failure. VMs 100/101 on `pve` must be shut down first (hard NFS mounts). → `docs/runbooks/esh-pve-cluster-pve9-upgrade-plan.md`
- **NH3 Mac mini (`Mac-mini`, 00:c5:85:13:e0:92, Wi-Fi, 10.100.10.121) asleep since ~1407; MeshCentral + RustDesk can't reach it.** Wake-on-LAN from nh3-dev (same subnet) did NOT wake it (Wi-Fi had disassociated). Prime fixes it on site 2026-10-04: `sudo pmset -a sleep 0 disksleep 0 displaysleep 10 womp 1 autorestart 1 powernap 0`, ideally plus Ethernet.
- **Done today, nothing open:** - **Done today, nothing open:**
- tank verified healthy 0629, disk kept, Miranda told; - tank verified healthy 0629, disk kept, Miranda told;
- albok-service 0.1.2 + the Nemi hourly timer; - albok-service 0.1.2 + the Nemi hourly timer;