nils/nixos-router
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add the appliance web UI look, interface names, MCP and REST API, local zone

Browse Source 
Web UI: dark/light themes (appliance layout, sidebar, switch checkboxes),
theme preference on the Advanced page, Changes page with the pending diff.

Interface names: router.interfaces.<name>.mac, lans.<l>.deviceName and
pppoe.vlanName; a rename is staged for the next reboot by router-apply.

Remote access: an MCP server (POST /mcp) and an OpenAPI REST API
(/api/v1, /api/openapi.json) with the same tokens, scopes, limits and audit
log; tools to read status, settings, leases, logs (get_logs), and to edit
and check the saved settings (never applied). Tokens on the API access page.

Firewall: a reserved `local` zone (the router itself) as the destination of
rules, so the web UI or SSH can be allowed from the WAN.

PLAN.md lists what is still left.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AeFqV9dZrK6nipHkPfyM4F
This commit is contained in:
nils
2026-11-01 16:56:59 +01:00
co-authored by Claude Sonnet 5.5
parent 95ab7223b9
commit 586274af4e
41 changed files with 3138 additions and 152 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SPECS.md
+8 -7
View File
@@ -1,16 +1,17 @@
# Specs
What nixos-router should become, beyond what exists. `PLAN.md` records decisions and what is done; this file
lists wanted features. Nothing here is started.
lists wanted features. The MCP server (read and change scopes) exists; the rest is not started.
## Later
### Programmatic access
- **REST API** for everything the web UI does (settings, apply/confirm, status, metrics, updates), versioned and
authenticated with tokens rather than the browser session. The web UI would use the same handlers.
- **REST API**: done with the MCP's feature set (OpenAPI at `/api/openapi.json`, see `PLAN.md`). Still to do: the rest
of what the web UI does (apply/confirm, metrics, updates), versioned; the web UI would use the same handlers.
- **GraphQL** on top of it, possibly: one query for the overview and for related settings.
- **MCP server**, so an assistant can read the router's state and propose or make changes (the same checks as the
web UI: settings are validated, applied with commit-confirm rollback, secrets are never returned).
- To settle first: token scopes (read-only vs. change), audit log, and that changes still go through
`settings.json` and `router-apply` rather than touching the live system.
- **MCP server**: done for reading and editing settings (see `PLAN.md`, "MCP server"). Still to do: an `apply` scope
(build, activate, confirm; a token with it can change the running system), more read tools (metrics history; `get_logs` exists),
per-token expiry, and a notice in the web UI when a token edited the settings.
- Rule for all of it: changes go through `settings.json` and `router-apply` (commit-confirm), never straight to the live
system; tokens have scopes; every call is logged.