websites init + docu revision

This commit is contained in:
Danilo Reyes
2026-02-06 08:13:37 -06:00
parent 893bb199b1
commit 17cd7ba593
11 changed files with 154 additions and 156 deletions

View File

@@ -88,7 +88,7 @@
- **T008**: `rg -n "enableProxy = true" hosts/vps/toggles.nix hosts/vps/configuration.nix hosts/server/toggles.nix`
- **T009**: ensure Caddy vs Nix comparison section remains in this file
- **T010**: `rg -n "iqQCY4iAWO-ca/pem|certPath|proxyReversePrivate" modules/network/nginx.nix modules/servers`
- **T011**: `rg -n "iptables.rules|iptables-restore|networking.firewall.enable = false" hosts/vps/configuration.nix`
- **T011**: `rg -n "nftables|forwardPorts|vps-snat" hosts/vps/configuration.nix`
- **T012**: `rg -n "services.wireguard.enable = true" hosts/vps/configuration.nix`
- **T013**: confirm `wireguard/private` exists in `secrets/wireguard.yaml`
- **T014**: `rg -n "10.77.0.1/24|10.8.0.1/24|10.9.0.1/24|AllowedIPs|allowedIPs" modules/services/wireguard.nix`
@@ -104,3 +104,4 @@
- **T024**: verify each task from T001-T026 has a corresponding verification line in this section
- **T025**: `rg -n "caddy|Caddy" README.org docs || true` and confirm no active-proxy references remain outside legacy migration notes
- **T026**: `rg -n "T0[0-2][0-9]" /home/jawz/Development/NixOS/specs/004-vps-migration/tasks.md` and confirm each task mentions at least one concrete path
- **T027**: `rg -n "modules/websites|danilo-reyes.com|blog.danilo-reyes.com|mb-report.lebubu.org" modules/websites hosts/vps/toggles.nix`

View File

@@ -56,7 +56,7 @@ and for lidarr-reports ed25519_lidarr-reports.pub
- Q: Are any services being migrated to the new VPS, and what does enableProxy do? → A: No services are migrated; enableProxy only configures nginx on the VPS, wireguard exposes the port, and services continue running on the host server.
- Q: How should the analytics service be migrated? → A: Migrate existing analytics data to the new server.
- Q: How should firewall parity be achieved on the new VPS? → A: Use the existing iptables ruleset as-is.
- Q: How should firewall parity be achieved on the new VPS? → A: Use the existing iptables ruleset as the source of truth and implement equivalent nftables/NixOS firewall rules; document any intentional deviations.
- Q: Where should VPN keys be stored? → A: Preserve keys only in the existing secrets system.
- Q: Which admin hosts should receive SSH authorized_keys entries? → A: Only the listed hosts (workstation, server, deacero, galaxy).
@@ -134,7 +134,7 @@ As an operator, I want a checklist of potential missing configuration from exist
- **FR-001**: The system MUST designate the new VPS as the primary host for reverse proxying and ensure all enabled services are routed through it without relocating the services.
- **FR-002**: The system MUST ensure proxy configuration is enabled for all services currently enabled on the host server so traffic flows through the new VPS while services remain on the host server.
- **FR-003**: The system MUST request existing proxy configuration files for verification and flag any subdomain mismatches against current service definitions.
- **FR-004**: The system MUST apply the existing iptables ruleset as-is on the new VPS to match the existing VPS behavior for all documented inbound and outbound flows.
- **FR-004**: The system MUST mirror the existing iptables behavior on the new VPS using nftables/NixOS firewall rules and document any intentional deviations from the source ruleset.
- **FR-005**: The system MUST enable the VPN configuration on the new VPS with the specified peer addresses and ensure each peer is uniquely identified.
- **FR-006**: The system MUST support encrypting sensitive VPN keys and pause for user-provided secret material when required.
- **FR-015**: The system MUST store VPN keys only in the existing secrets system and must not place them in plaintext configuration.
@@ -172,6 +172,6 @@ As an operator, I want a checklist of potential missing configuration from exist
## Assumptions
- The existing proxy configuration files will be provided by the user for comparison.
- The firewall rules from the existing VPS are authoritative and should be mirrored on the new VPS.
- The firewall rules from the existing VPS are authoritative and should be mirrored on the new VPS, even if implemented via nftables equivalents.
- The list of standard admin hosts for SSH access is complete unless the review identifies an omission.
- The analytics service migration steps are documentation-only and do not require immediate cutover.

View File

@@ -38,7 +38,7 @@ Deliver MVP as User Story 1 (primary host reverse proxy + keep services on host
**Independent test criteria**: Known inbound/outbound flows match existing VPS behavior.
- [x] T011 [US2] Apply iptables ruleset as-is to VPS configuration in hosts/vps/configuration.nix using the repo root iptables file
- [x] T011 [US2] Apply firewall parity to VPS configuration using nftables/NixOS rules derived from the repo root iptables file and document any intentional deviations
## Phase 5: User Story 3 (P2) - Secure access and VPN peers
@@ -71,6 +71,7 @@ Deliver MVP as User Story 1 (primary host reverse proxy + keep services on host
- [x] T025 [P] Update references to old VPS proxy logic (caddy) to ensure nginx is the only runtime proxy in README.org and docs/*.md
- [x] T026 [P] Validate all task descriptions include explicit file paths in specs/004-vps-migration/tasks.md and update mismatches
- [x] T027 [P] Move static site vhosts (portfolio/blog and mb-report) into modules/websites and enable them via host toggles
## Dependencies