docs: decisions/ - decision list + future plans #4
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
decisions/ is still an empty stub. Waiting on your input: which choices to document as ADR-lite notes (candidates I saw while writing: PBS 3-way mirror, consumer-to-enterprise drive upgrade, two pi-hole instances, OPNsense as edge, 12VDC coverage strategy), and what the "future of the lab" section should say. Comment with the list and I'll draft each decision doc.
I don't hate the idea of using ADR, I'm just unfamiliar. Might hold on this one.
12VDC coverage is fairly obvious---keeping the core services running and keeping internet connection with the outside world was the priority; it works perfectly, too. We just need to improve the automated shutdown of bort and alex (which currently has a charging issue, but I digress) since those two are connected to a dumb lithium powerbank with only 15-20 minutes of runtime in an outage. I do have a fast-changeover pure-sine inverter that I've been meaning to connect up to citrine, but haven't gotten around to it yet.
Future of the lab...Honestly it's about consolidating the capabilities I already have. Authentik, Suricata, improved DNS stability, migrating off of Cloudflare to a different DNS provider (including all of my email name records), potentially hosting my own email (because it sounds fun), further cross-site capability sharing, better offsite backups, better monitoring and issue reporting, reducing noise and increasing signal for monitoring...there's a lot to do.
The OPNsense decision wasn't really a decision---it was the first choice I made and I haven't tried anything else because it's all worked fine.
The pi-hole setup is mostly because I have come to enjoy unbound dns and pi-hole, so the only workaround to their relatively-limited split-horizon setup is to just host two separate instances. The compute workload is negligible, and it makes it more clear exactly where certain origins can get names resolved from. There is a lot more cleanup to do, though; opnsense is still running as a resolver, and it's pointed at the internal pi-hole, which means that all of my careful separation isn't actually beneficial at this point; it's just preparing for the actual split once things are fully operational on both sides. Firewall rules need changed, DHCP settings need adjusted, and all the endpoints need to have access validated from various origins to confirm things are working as-expected.
Future content captured in new future.md (consolidation list, linked from README). ADR/decisions/ left on hold as you suggested; the decisions/ stub stays in the repo unlinked until you decide. The pi-hole split-horizon status (OPNsense still resolving, firewall/DHCP changes pending) was folded into network.md DNS section. Closing; reopen if you want the ADR path.