Paul Payne
2e6fce54e3
Dashboard: infrastructure health (router, cloudflare, DDNS, daemons). Services: every registered service with full status (DNS, proxy, TLS, DDNS) in expandable rows + custom TCP routes section. 9 sidebar items → 6. Seven old pages eliminated — their content lives in the two new pages where it belongs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
189 lines
8.5 KiB
Markdown
189 lines
8.5 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. Infrastructure health + registered services with their full status.
|
|
- **Central section** — the device itself. Firewall, VPN, security, DHCP. These exist whether or not any services are registered.
|
|
|
|
## Navigation
|
|
|
|
```
|
|
Services
|
|
├── Dashboard (infrastructure health: router, cloudflare, DDNS, daemons)
|
|
├── Services (registered services + custom TCP routes)
|
|
|
|
Central
|
|
├── Firewall
|
|
├── VPN
|
|
├── CrowdSec
|
|
└── DHCP
|
|
```
|
|
|
|
6 sidebar items (down from 9). Two labeled groups with clear separation.
|
|
|
|
---
|
|
|
|
## Dashboard
|
|
|
|
The "is everything working" page. Shows the health of the infrastructure that Central depends on. If anything here is red, services won't work properly.
|
|
|
|
### Gateway Router
|
|
- Is the router forwarding DNS to Central (192.168.8.151)?
|
|
- Are the required ports forwarded? (443, 80, 51820/UDP)
|
|
- Instructions for common routers if not configured
|
|
|
|
### Cloudflare
|
|
- Is the API token configured and valid?
|
|
- What zones are accessible?
|
|
- Token setup inline if missing (don't send user to another page)
|
|
|
|
### Dynamic DNS
|
|
- Is the public IP current? When was it last checked?
|
|
- Are all A records synced?
|
|
- Record list with status (cloud.payne.io ✓, dev.payne.io ✓, etc.)
|
|
- These are infrastructure records, not per-service — they exist to make the public IP reachable
|
|
|
|
### Daemon Status
|
|
- dnsmasq: running ✓ (listening on 192.168.8.151)
|
|
- haproxy: running ✓ (pid 12345)
|
|
- wireguard: running ✓ (2 peers connected)
|
|
- crowdsec: running ✓
|
|
- nats: running ✓
|
|
|
|
### Warnings
|
|
- "wild-cloud.payne.io needs a TLS cert → [Provision]"
|
|
- "Cloudflare token not set → [Configure]"
|
|
- "Port 443 not forwarded on router → [How to fix]"
|
|
|
|
---
|
|
|
|
## Services
|
|
|
|
THE page. Everything about every service in one place.
|
|
|
|
### Service List
|
|
|
|
Each service is a collapsed row showing summary status. Expand for full details.
|
|
|
|
**Collapsed row:**
|
|
```
|
|
cloud.payne.io L4 passthrough public *.subdomains ✓✓✓✓
|
|
wild-cloud.payne.io L7 proxy internal ✓✓⚠—
|
|
payne.io L4 exact public ✓✓✓✓
|
|
```
|
|
|
|
The four indicators are: DNS, Proxy, TLS, DDNS. Green/warning/missing/not-applicable.
|
|
|
|
**Expanded row for cloud.payne.io:**
|
|
```
|
|
┌─────────────────────────────────────────────────────────────────────┐
|
|
│ cloud.payne.io wild-cloud public│
|
|
│ L4 passthrough → 192.168.8.240:443 *.subdomains │
|
|
├─────────────────────────────────────────────────────────────────────┤
|
|
│ DNS (LAN) address=/cloud.payne.io/192.168.8.240 ✓ │
|
|
│ DNS (Public) A record cloud.payne.io → 216.243.55.15 ✓ │
|
|
│ Proxy HAProxy L4 SNI + wildcard *.cloud.payne.io ✓ │
|
|
│ TLS passthrough (k8s traefik handles) ✓ │
|
|
│ │
|
|
│ Source: wild-cloud Registered: 2h ago │
|
|
│ [Change Reach] [Deregister] │
|
|
└─────────────────────────────────────────────────────────────────────┘
|
|
```
|
|
|
|
**Expanded row for wild-cloud.payne.io:**
|
|
```
|
|
┌─────────────────────────────────────────────────────────────────────┐
|
|
│ wild-cloud.payne.io wild-cloud internal│
|
|
│ L7 reverse proxy → 127.0.0.1:5055 │
|
|
├─────────────────────────────────────────────────────────────────────┤
|
|
│ DNS (LAN) local=/ + address=.../192.168.8.151 ✓ │
|
|
│ DNS (Public) (internal only — no public DNS record) — │
|
|
│ Proxy HAProxy L7 Host header routing ✓ │
|
|
│ TLS Central terminates — cert MISSING ⚠ │
|
|
│ └─ [Provision Certificate] │
|
|
│ │
|
|
│ Source: wild-cloud Registered: 2h ago │
|
|
│ [Change Reach] [Deregister] │
|
|
└─────────────────────────────────────────────────────────────────────┘
|
|
```
|
|
|
|
Central's own domain (from config) appears here too — it's just another row. Source shows "config" instead of a consumer name.
|
|
|
|
### Custom TCP Routes
|
|
|
|
Below the service list, a separate section for manual TCP proxy rules that aren't domain-based service registrations:
|
|
|
|
```
|
|
Custom TCP Routes
|
|
┌────────────────────────────────────────────────┐
|
|
│ civil_ssh port 2222 → 192.168.8.10:22 │
|
|
│ [Remove] │
|
|
├────────────────────────────────────────────────┤
|
|
│ [+ Add Custom Route] │
|
|
└────────────────────────────────────────────────┘
|
|
```
|
|
|
|
These are from `cloud.haproxy.customRoutes` in the global config.
|
|
|
|
### Actions
|
|
|
|
- **Register new service** (manual registration form)
|
|
- **Provision certificate** (per-service, inline)
|
|
- **Change reach** (internal ↔ public, per-service)
|
|
- **Deregister** (per-service)
|
|
- **Add wildcard cert** (covers multiple services under same domain)
|
|
- **Generate & Apply HAProxy** (advanced, collapsed)
|
|
- **View raw HAProxy config** (advanced, collapsed)
|
|
|
|
---
|
|
|
|
## Central Section
|
|
|
|
These pages are unchanged in content. They're Central's own infrastructure config — not driven by service registrations.
|
|
|
|
### Firewall
|
|
nftables rules. Ports opened for HAProxy (443, 80), VPN (51820), SSH (22), plus any custom.
|
|
|
|
### VPN
|
|
WireGuard server config + peer management. Add/remove peers, view configs, QR codes.
|
|
|
|
### CrowdSec
|
|
Intrusion detection. Alerts, decisions, machines, bouncers.
|
|
|
|
### DHCP
|
|
dnsmasq DHCP config. IP ranges, lease times, static leases, active leases.
|
|
|
|
---
|
|
|
|
## What Disappeared
|
|
|
|
The following pages are eliminated — their content lives elsewhere:
|
|
|
|
| Old Page | Where It Went |
|
|
|----------|---------------|
|
|
| Overview | → Dashboard (completely rewritten as infrastructure health) |
|
|
| Cloudflare | → Dashboard (Cloudflare section) |
|
|
| DNS | → Services (per-service DNS status in expanded rows) |
|
|
| LAN DNS | → Services (per-service LAN DNS entries) |
|
|
| DDNS | → Dashboard (Dynamic DNS section — infrastructure health) |
|
|
| Ingress Proxy | → Services (proxy status in expanded rows, custom routes section) |
|
|
| Certificates | → Services (TLS status in expanded rows, provision inline) |
|
|
|
|
---
|
|
|
|
## Design Principles
|
|
|
|
1. **Services are the entrypoint.** The Services page is where you see, configure, and troubleshoot everything about what Central serves.
|
|
|
|
2. **Dashboard is about infrastructure.** Is the foundation healthy? Router, Cloudflare, DDNS, daemons. If something here is red, fix it before worrying about individual services.
|
|
|
|
3. **Everything about a service is in one place.** DNS, proxy, TLS, DDNS — all visible in the expanded service row. No hopping between pages to understand one service's status.
|
|
|
|
4. **Two sections, two concerns.** Services = what Central does for consumers. Central = what the device does for itself.
|
|
|
|
5. **6 items, not 9.** Less navigation, less confusion. The information isn't lost — it's better organized.
|