sync: auto-sync from GURU-5070 at 2026-06-27 06:53:09

Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-27 06:53:09
This commit is contained in:
2026-06-27 06:54:08 -07:00
parent dbe355a2d5
commit dde412a16f

View File

@@ -131,3 +131,48 @@ general advisory on forcing SharePoint docs to open in desktop Office (no change
"Open in the client application"; site-collection feature "Open Documents in Client Applications "Open in the client application"; site-collection feature "Open Documents in Client Applications
by Default"; or per-user Sync/"Add shortcut to OneDrive". Caveat: Business Basic (no desktop by Default"; or per-user Sync/"Add shortcut to OneDrive". Caveat: Business Basic (no desktop
Office license) users can hit an error instead of browser fallback. Office license) users can hit an error instead of browser fallback.
## Update: 06:52 PT — finish killing the dead `.50` resolver (Jupiter host + pfSense)
Continuation of the DNS-relay work: eradicated the dead `172.16.3.50` from all active config.
**1. Jupiter host DNS1 -> 172.16.0.1.** `/boot/config/network.cfg` `DNS_SERVER1="172.16.3.50"`
-> `"172.16.0.1"` (kept `8.8.8.8`/`1.1.1.1` as DNS2/3), and live `/etc/resolv.conf` first
nameserver updated. No network restart (would risk the SSH session). Backups
`network.cfg.bak-20260627`, `resolv.conf.bak-20260627`. Host lookups now fast (was ~5s stall;
the host couldn't use the `.50` relay container due to ipvlan host->own-container).
**2. pfSense LAN DHCP DNS — already correct, no change.** Read `config.xml`: the only DHCP scope
(`lan`, range `172.16.1.1-254`) already hands out `<dnsserver>172.16.0.1</dnsserver>` first, then
`8.8.8.8`, `1.1.1.1`. So DHCP was never the source of the dead `.50` — affected hosts were
statically configured (e.g. Jupiter, now fixed) and/or covered by the relay. pfSense system DNS =
`8.8.8.8`/`1.1.1.1`; unbound (DNS Resolver) running on `:53`.
**3. pfSense OpenVPN wizard state scrubbed.** The only other `.50` in `config.xml` was
`$config['ovpnserver']['step10']['dns1']=172.16.3.50` — pfSense's saved **OpenVPN setup-wizard**
state, NOT a live server (the `<openvpn>` config is empty; remote access is Tailscale/WireGuard).
So it was inert (not pushed to any client) — my earlier "VPN clients get .50" framing was wrong.
Scrubbed to `172.16.0.1` anyway (hygiene; prevents a future wizard re-run reintroducing it) via
`php` `write_config()` using the skill's proven `config.inc` bootstrap, no service reload. Backup
`/tmp/config.xml.predns-20260627.bak` on the box + pfSense config-history revision. The only
remaining `.50` string in config is that revision's own change-note (metadata, scrolls off).
**Tooling note:** all pfSense access went through the `unifi-wifi` pfSense SSH backend
(`pfsense-ssh.sh infrastructure/pfsense-firewall run "<cmd>"`) — authenticated path (askpass +
vaulted password, port 2248), not hand-rolled ssh. No dedicated DHCP/DNS verb exists, so used `run`.
### Update — Configuration Changes
- Jupiter (live): `/boot/config/network.cfg` DNS_SERVER1 -> `172.16.0.1`; `/etc/resolv.conf` live.
- pfSense (live, `config.xml` via write_config): `ovpnserver/step10/dns1` `172.16.3.50` -> `172.16.0.1`.
- No repo files changed in this update (infra-only). `wiki/systems/pfsense.md` note still TODO.
### Update — Infrastructure & Servers
- **pfSense office gateway** `172.16.0.1`, SSH port **2248**, user `admin`, pfSense 2.8.1 (FreeBSD).
Vault `infrastructure/pfsense-firewall.sops.yaml`. Tailscale `100.79.69.82`/`100.119.153.74`.
LAN DHCP scope `172.16.1.1-254`; unbound resolver on `:53` (verified 0.06s).
- Dead host `172.16.3.50` now fully decommissioned in config; `dns-relay` container still answers
`.50` for any static straggler. New DHCP clients get `172.16.0.1` directly.
### Update — Pending / Incomplete Tasks
- Optional: note this pfSense `.50` cleanup + DHCP finding in `wiki/systems/pfsense.md`.
- Seerr Plex Scan error follow-up (re-select Plex libraries) still open from earlier.