Paul Payne
0646abb9af
Complete rewrite of the UI refactor plan based on the insight that services are the entrypoint for everything. DNS, certs, proxy routes are effects of service registrations, not independent config surfaces. Two sidebar sections: Services (outward-facing, service-driven) and Central (inward-facing, device config). Each service page answers "what did Central do because of registered services?" Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
147 lines
6.8 KiB
Markdown
147 lines
6.8 KiB
Markdown
# Wild Central UI Refactor
|
|
|
|
## Core Insight
|
|
|
|
Everything flows from the **service**. When a service is registered, Central lights up the components it needs: DNS records, proxy routes, TLS certs, DDNS records. The other pages aren't independent configuration surfaces — they're views into the effects of service registrations.
|
|
|
|
This creates two clear sections:
|
|
|
|
- **Services section** — the service-driven system. Everything here exists because services were registered (or because services need it to function). This is what Wild Cloud and Wild Works interact with.
|
|
- **Central section** — the device itself. Firewall, VPN, security, DHCP. These exist whether or not any services are registered. This is the appliance config.
|
|
|
|
## Navigation
|
|
|
|
```
|
|
Services
|
|
├── Dashboard (default landing — health, warnings, at-a-glance status)
|
|
├── Cloudflare (THE setup page — token, zones, tunnel. Prerequisite for everything)
|
|
├── Services (registered services — the primary config surface)
|
|
├── DNS (complete DNS picture — internal + external resolution per service)
|
|
└── Certificates (TLS status per service — what's provisioned, what's missing)
|
|
|
|
Central
|
|
├── Firewall (nftables rules)
|
|
├── VPN (WireGuard server + peers)
|
|
├── CrowdSec (intrusion detection)
|
|
└── DHCP (IP address assignment + leases)
|
|
```
|
|
|
|
## Page Designs
|
|
|
|
### Dashboard
|
|
|
|
The landing page. At-a-glance system health:
|
|
- Daemon statuses: dnsmasq ✓, haproxy ✓, wireguard ✓, crowdsec ✓
|
|
- Registered services: 9 services (7 public, 2 internal)
|
|
- Certificates: 2 valid, 1 missing — ⚠ warning
|
|
- DDNS: synced, public IP 216.243.55.15
|
|
- Cloudflare: token valid ✓
|
|
- Warnings/actions: "wild-cloud.payne.io needs a TLS cert → Provision"
|
|
|
|
If Cloudflare isn't configured, the dashboard shows a prominent setup prompt directing the user there first.
|
|
|
|
### Cloudflare
|
|
|
|
The prerequisite page. Everything public depends on this:
|
|
- API token management (set, verify, show accessible zones)
|
|
- Tunnel status (cloudflared connection, connected services)
|
|
- DDNS provider config (which records to sync, current public IP, last sync)
|
|
|
|
This is the first page a new user configures. Without the token, public DNS and TLS certs don't work — the UI should make this dependency obvious.
|
|
|
|
### Services
|
|
|
|
THE primary interaction surface. Every registered service in one table:
|
|
|
|
| Domain | Backend | Type | Reach | DNS | TLS | DDNS |
|
|
|--------|---------|------|-------|-----|-----|------|
|
|
| cloud.payne.io | 192.168.8.240:443 | L4 passthrough | public | ✓ resolves | ✓ passthrough | ✓ A record |
|
|
| *.cloud.payne.io | (same) | L4 wildcard | public | ✓ resolves | ✓ passthrough | — |
|
|
| central.payne.io | 127.0.0.1:15055 | L7 proxy | internal | ✓ resolves | ✓ 88d left | — (internal) |
|
|
| wild-cloud.payne.io | 127.0.0.1:5055 | L7 proxy | internal | ✓ resolves | ⚠ missing | — (internal) |
|
|
| payne.io | 192.168.8.240:443 | L4 exact | public | ✓ resolves | ✓ passthrough | ✓ A record |
|
|
|
|
Each row shows the **complete status** of one service — every effect Central provides for it. The user sees immediately: "wild-cloud.payne.io is missing a TLS cert." Click a row to see details or take action.
|
|
|
|
Central's own domain (from config) appears in this table too — it's just another service from the user's perspective.
|
|
|
|
The service detail view shows:
|
|
- All the effects (DNS entry, proxy route, TLS cert, DDNS record)
|
|
- The registration source (wild-cloud, wild-works, config)
|
|
- Actions: provision cert, change reach, deregister
|
|
|
|
HAProxy raw config, stats, and generate/restart move to a collapsible "Advanced" section at the bottom.
|
|
|
|
### DNS
|
|
|
|
The **complete DNS picture** for all services. Not a configuration page — a status view showing how every domain resolves, from both inside and outside the network.
|
|
|
|
For each service domain:
|
|
| Domain | Internal (LAN) | External (Internet) |
|
|
|--------|---------------|---------------------|
|
|
| cloud.payne.io | 192.168.8.240 (direct to k8s LB) | 216.243.55.15 (via DDNS) |
|
|
| central.payne.io | 192.168.8.151 (Central) | — (internal only) |
|
|
| internal.cloud.payne.io | 192.168.8.240 (with local=/) | — (never forwarded) |
|
|
|
|
Plus DNS server infrastructure status:
|
|
- dnsmasq: running ✓, listening on 192.168.8.151
|
|
- Upstream forwarders: 1.1.1.1, 8.8.8.8
|
|
- DDNS sync: last checked 2m ago, public IP 216.243.55.15
|
|
|
|
This replaces the three overlapping DNS pages (dns, lan-dns, ddns) with one coherent view.
|
|
|
|
### Certificates
|
|
|
|
TLS cert status for every service that needs Central to terminate TLS:
|
|
|
|
| Domain | Status | Expires | Issuer | Action |
|
|
|--------|--------|---------|--------|--------|
|
|
| central.payne.io | ✓ valid | 88 days | Let's Encrypt | Renew |
|
|
| wild-cloud.payne.io | ⚠ missing | — | — | Provision |
|
|
|
|
Services with TLS passthrough (k8s instances) don't appear here — their backend handles TLS.
|
|
|
|
"Provision" and "Renew All" buttons. "Add Wildcard" for opt-in wildcard certs.
|
|
|
|
Requires Cloudflare token — if not configured, shows a prompt directing to Cloudflare page.
|
|
|
|
### Firewall, VPN, CrowdSec, DHCP
|
|
|
|
These are Central's own infrastructure config. Not service-driven. Each is its own page under the "Central" sidebar section. No changes needed to their content — just the grouping.
|
|
|
|
## Key Design Principles
|
|
|
|
1. **Services are the entrypoint.** Every page in the Services section answers: "what did Central do (or need to do) because of the services registered with it?"
|
|
|
|
2. **Status over configuration.** DNS and Certificates pages are primarily status views — they show the effects of service registrations. The user configures services, not DNS entries directly.
|
|
|
|
3. **Dependencies are visible.** Dashboard warns if Cloudflare isn't configured. Certificates page warns if token is missing. Services page shows which effects are green vs red.
|
|
|
|
4. **Two sections, two concerns.** Services = outward-facing (what Central does for consumers). Central = inward-facing (what the device does for itself).
|
|
|
|
## Migration
|
|
|
|
### Pages to delete
|
|
- `LanDnsPage.tsx` — duplicate
|
|
- `DdnsPage.tsx` — folded into Cloudflare
|
|
- `LanDnsComponent.tsx` — duplicate
|
|
|
|
### Pages to rename
|
|
- `CentralPage.tsx` → `DashboardPage.tsx`
|
|
- `IngressProxyPage.tsx` → `ServicesPage.tsx`
|
|
- `IngressProxyComponent.tsx` → `ServicesComponent.tsx`
|
|
- `CentralComponent.tsx` → `DashboardComponent.tsx`
|
|
|
|
### Pages to rewrite
|
|
- `DashboardComponent` — new status dashboard (currently just operator email)
|
|
- `ServicesComponent` — new service table with per-service effect status
|
|
- `DnsComponent` — unified DNS view (internal + external per service)
|
|
- `CloudflareComponent` — add DDNS management and tunnel status
|
|
|
|
### Sidebar changes
|
|
- Two labeled groups: "Services" and "Central"
|
|
- "Overview" → "Dashboard"
|
|
- "Ingress Proxy" → "Services"
|
|
- Remove DNS/LAN DNS/DDNS → replace with single "DNS"
|
|
- Add DDNS content to Cloudflare page
|