New Consistency page listing where the three places this app records what lives at an address disagree: - Address conflicts: the same address reported by more than one server. - DNS out of date: a record named after a server (its hostname, or its short name) that points at an address the server doesn't report. - IPAM out of date: an entry labelled with a server's name at an address the server doesn't report. - Not in IPAM: addresses a server reports or DNS points at that IPAM doesn't list, merged into one finding per address, with a one-click "Add to IPAM" that pre-fills a label. - No DNS record: server LAN addresses no cached A/AAAA record resolves to. It compares data the app already holds and fetches nothing when opened, so the page states how many servers had reported addresses and how many DNS zones are synced (and how old the oldest sync is) -- DNS records are only cached for zones that have been synced, and a report that silently treated missing data as "no records" would mislead. Rules chosen to keep it from crying wolf: - Only private addresses are compared; public DNS records aren't expected to be in IPAM. - Servers with no reported addresses are never judged. - Agents report IPv4 only, so records are only compared within an address family (an AAAA record isn't "stale" for lacking an IPv6 address). - Docker bridge networks (172.16/12) are ignored: shared ones aren't conflicts, and they aren't listed unless someone put them in DNS. - Tailscale addresses don't need DNS records (MagicDNS), and IPAM entries kept current by the Tailscale/Proxmox syncs aren't second-guessed. Findings anyone has decided are fine can be ignored (operators) with a reason. An ignore is keyed on the finding's stable identity so it stays ignored across runs, its stored text comes from the finding rather than the request, and it is marked "no longer occurring" once the condition goes away. Ignore/restore are audit-logged. New table consistency_ignores (migration 0012). portScan's private-address helper is now exported and shared. Verified with 36 checks (each rule and its exclusions, address-family and case/trailing-dot handling, IPv6 case, ordering, stable keys, the report route including a garbled agent report, source counts, ignore/unignore rules and audit entries) and by driving the page against the real routers in a browser: Add to IPAM actually created the entry, ignore and restore, severity filter, "show all", the viewer view, and narrow-width layout (which found and fixed a squeezed badge and clipped buttons). Real dev database mtime untouched. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
256 lines
14 KiB
Markdown
256 lines
14 KiB
Markdown
# Homelab Manager
|
|
|
|
Repository: `git@10.200.5.13:bobban/Homelab-manager.git` ([gitea.labsconnect.se/bobban/Homelab-manager](https://gitea.labsconnect.se/bobban/Homelab-manager) externally).
|
|
|
|
A single dashboard for a homelab: Proxmox, Synology DSM, Semaphore, Tailscale,
|
|
Gitea, and Dockhand/Docker status and basic actions, plus DNS record
|
|
management, an IP address inventory (IPAM), and a secret-expiry tracker
|
|
(ported from [Sloth Manager](../Sloth%20manager)) and scheduled-task tracking
|
|
across Debian/Raspbian hosts (ported from
|
|
[Schedule Task Manager](../ScheduleTaskManager)). Looks and feels like a
|
|
[Tabler](https://tabler.io) admin dashboard. Sign-in is delegated to
|
|
Authentik (OIDC), with local admin/operator/viewer roles.
|
|
|
|
## Status
|
|
|
|
All modules from the original plan are built:
|
|
|
|
- Monorepo scaffold, Tabler-themed app shell/navigation
|
|
- Authentik OIDC login, roles (first user to sign in becomes admin), audit log
|
|
- **Dashboard** — an overview of every system this app tracks, all sharing
|
|
one widget-card design (label + status badge, a small stat row, then its
|
|
own breakdown): DNS (domain/record counts per provider, cached records by
|
|
type), Secrets (monitored/expiring/expired, by type), and one widget per
|
|
integration — Tailscale by OS, Proxmox by node (VM/LXC counts too),
|
|
Dockhand by container state (plus host count), Semaphore and Gitea by
|
|
last-run status (plus private-repo count), and Synology's CPU/RAM
|
|
alongside its disk-health breakdown. Breakdowns render as a stacked
|
|
proportion bar with a legend — no charting
|
|
library, matching the rest of the app's plain-Tabler-CSS approach.
|
|
- **Diagnostic Log** (admin-only) — every call this app makes to a DNS
|
|
provider or integration (Tailscale, Proxmox, Synology, Semaphore, Gitea,
|
|
Dockhand), success or failure, with latency and the error message if it
|
|
failed — the last 500 calls, filterable by source/result, for
|
|
troubleshooting connectivity issues (ported from Sloth Manager's
|
|
provider-diagnostics log, generalized to cover every integration this app
|
|
has, not just DNS)
|
|
- **Secrets** — expiry tracking for API tokens/certs/passwords. An SSL
|
|
certificate can optionally be given a host:port to watch: the app opens a
|
|
real TLS connection (daily, and on demand via "Check now"), reads the
|
|
certificate's actual expiry, and keeps the date current — so a renewed cert
|
|
is picked up automatically and an unreachable host is flagged instead of
|
|
silently going stale
|
|
- **IP Addresses (IPAM)** — inventory of IPs across vendors/locations,
|
|
with "Sync from Tailscale" and "Sync from Proxmox" actions to pull in
|
|
tailnet device IPs and VM/LXC IPs (never overwrites a
|
|
manually-entered IP), and each entry now shows its matching DNS
|
|
record(s) from the DNS module's cache
|
|
- **DNS** — zone/record management across Cloudflare, Loopia, Pi-hole, Azure
|
|
DNS, cPanel, and Technitium; providers are configured in-app (not via env
|
|
vars) and their credentials are encrypted at rest
|
|
- **Servers** — cron/systemd tracking across Debian/Raspbian servers via a
|
|
lightweight push agent (`agent/linux/`), plus manual entries for things an
|
|
agent can't see (Docker jobs, backups). The Servers page itself just lists
|
|
registered servers and (admin-only) adds new ones / issues agent tokens;
|
|
clicking a server opens its detail page with CPU/RAM/disk status, IP
|
|
addresses, matching DNS names (looked up from the DNS module's cache), and
|
|
its scheduled tasks — live hardware from Proxmox for VM/LXC-backed
|
|
servers, or from the agent's own hardware report for everything else,
|
|
both showing the same per-disk usage breakdown (an LXC's root filesystem
|
|
read straight from the host; a QEMU VM's actual mounts via its guest
|
|
agent, alongside the allocated size Proxmox already knew about without
|
|
one). Proxmox-linked servers also get start/stop/restart buttons right on the
|
|
detail page. The detail page also has an **Admin Links** section
|
|
(operator/admin to add/edit/remove) for bookmarking that server's own
|
|
admin UIs — Dockge, Webmin, Cockpit, Portainer, or anything else reachable
|
|
by URL. Since not every server is a Proxmox VM, an admin can hide the
|
|
"Proxmox link" card per server ("Not a VM? Hide this" / "+ Show Proxmox
|
|
link options") — it stays visible regardless once a server actually is
|
|
linked, so unlinking is always reachable.
|
|
- **Tailscale**, **Proxmox**, **Synology**, **Semaphore**, **Gitea**,
|
|
and **Docker** each get their own top-level page (backed by the
|
|
matching integration) instead of living inside a shared Integrations
|
|
browsing view:
|
|
- **Tailscale** — device list with online/authorized status, and
|
|
authorize/deauthorize/remove actions; a live device-count widget.
|
|
- **Proxmox** — VM/LXC status across every node in the cluster, with
|
|
start/restart/shutdown/stop actions; a live running/total widget. Each
|
|
online node also gets its own host-stats card — uptime, CPU usage/cores/
|
|
load average, RAM and swap usage, and per-storage usage (local, LVM-thin,
|
|
ZFS, NFS, etc). Supports self-signed certificates (common in homelab
|
|
setups).
|
|
- **Synology** — volume and disk health (read-only by design).
|
|
Supports self-signed certificates.
|
|
- **Semaphore** — Ansible run status per template across every
|
|
project, with a "Run" action to trigger a template; a live
|
|
template-count widget (with a last-failed warning).
|
|
- **Gitea** — repo list with each repo's last CI run status, and
|
|
re-running just the failed jobs in a run; a live repo-count widget
|
|
(with a failing-build warning).
|
|
- **Docker** — container status across every Docker host Dockhand
|
|
manages (one credential covers all of them), with
|
|
start/stop/restart actions, a host filter, image-update status per
|
|
container (from Dockhand's own cached update check, plus a button
|
|
to trigger a fresh one), and a live running/total widget (with an
|
|
updates-available count).
|
|
|
|
The Integrations page itself is now just a list of configured
|
|
integrations (name/type/status, visible to every role) with an
|
|
admin-only "Add integration" button and edit/enable/disable/delete
|
|
actions per row — the six dedicated pages above are where you
|
|
actually use each one.
|
|
- Every table in the app is click-to-sort on any column (numbers, booleans,
|
|
and dates/text sort correctly regardless of how the column formats them)
|
|
and has an "Export CSV" button next to it that exports whatever's
|
|
currently sorted/filtered. Tables that can realistically grow large
|
|
(DNS zones/records, IP Addresses, Secrets, Servers, Audit Log, and each
|
|
integration's device/container/guest/repo/template list) are paginated,
|
|
20 rows per page by default — adjustable under Settings → Display — and
|
|
CSV export still covers every sorted/filtered row, not just the current
|
|
page.
|
|
- **Settings** (admin-only) — notification channels (Gotify, ntfy, SMTP,
|
|
generic webhook) with per-channel test buttons, per-event toggles (DNS
|
|
record added/updated/deleted, daily secret-expiry reminder and daily
|
|
Tailscale key-expiry reminder — both sharing one configurable
|
|
time/timezone), badge-color customization for both DNS
|
|
providers and integration types, and a **Display** tab (date order,
|
|
12/24-hour clock, and rows-per-page for every paginated table) applied
|
|
consistently across the app.
|
|
|
|
All six integrations follow the same config-in-UI + encrypted-credentials
|
|
pattern, added (and edited — e.g. to rotate an expired API token without
|
|
recreating the whole integration) through **Integrations → Manage
|
|
integrations**. See [INTEGRATIONS.md](INTEGRATIONS.md) for exactly what
|
|
credential to create and what access it needs in each target system,
|
|
for every integration and DNS provider.
|
|
|
|
**Verified for real, end to end**: every module above — including all six
|
|
integrations, both their read-only views and their write actions
|
|
(start/stop/restart, trigger-a-run, authorize/deauthorize) — has been
|
|
exercised against the user's actual live homelab, not just built against
|
|
specs. That pass also found and fixed two real bugs: the Synology adapter
|
|
assumed HTTPS-only (the NAS is reached over plain HTTP), and the Tailscale
|
|
adapter read `online`/`isExitNode` fields that don't actually exist in the
|
|
real API response (fixed to derive them from `connectedToControl` and
|
|
`enabledRoutes`). See the git log for the full verification notes per
|
|
integration.
|
|
|
|
Server and storage health is watched every 15 minutes: a server whose agent
|
|
stops reporting, a server disk / Proxmox storage / Synology volume passing a
|
|
usage threshold, and a Synology volume or disk that's degraded or failing each
|
|
raise one notification when the problem starts and one when it clears (both
|
|
thresholds are set under Settings → Notifications). Active problems are
|
|
remembered across restarts, so a rebuild doesn't re-alert them.
|
|
|
|
**Tags** — servers can be tagged (prod, media, rack-1, …) from their detail
|
|
page by operators and admins. Tags show as coloured chips on the Servers page,
|
|
which can be filtered by one or several tags (the filter is in the URL, so a
|
|
tag on a server's page links to everything sharing it), and they're searchable
|
|
from the global search box.
|
|
|
|
**Consistency** — a report of where IPAM, DNS and your servers disagree about
|
|
an address: the same address on two servers, a DNS record named after a server
|
|
that points somewhere it isn't, an IPAM entry labelled with a server's name at
|
|
the wrong address, addresses in use that IPAM doesn't list (with an "Add to
|
|
IPAM" button), and server addresses no DNS record points at. It only compares
|
|
data the app already holds — nothing is fetched when you open it — so it says how
|
|
many servers reported addresses and how fresh the synced DNS zones are. Only
|
|
private addresses are compared; Docker bridge networks are left out; anything
|
|
that's fine on purpose can be ignored with a reason, and stays ignored.
|
|
|
|
**Domains** — when each domain registration expires, read from the registry
|
|
itself. The domains behind your DNS zones are picked up automatically (a zone
|
|
like `lab.example.se` resolves to the `example.se` registration that actually
|
|
expires); others can be added by hand. Each is looked up daily over RDAP where
|
|
the TLD offers it, and otherwise over WHOIS via IANA's referral — which is what
|
|
makes `.se`, `.nu` and `.io` work, since those aren't in the RDAP bootstrap.
|
|
You're reminded daily from N days before expiry (Settings → Notifications,
|
|
default 30) until it's renewed, and told when an expiry date couldn't be
|
|
refreshed for several days. Registries that don't publish an expiry (`.de`,
|
|
`.eu`) can be tracked but have no date to warn about. Private zones (`.lan`,
|
|
`.local`) are skipped.
|
|
|
|
**Automation failures** — every 15 minutes the app looks at the latest run of
|
|
each Semaphore template and each Gitea repo's latest workflow run. A failed one
|
|
raises a single notification (with the project/template or repo, run number, and
|
|
for Gitea the run's link), and another when a later run succeeds. It's
|
|
state-based, so a job that fails every night alerts on the first failure rather
|
|
than every night. A run that's still going, was cancelled, or was stopped by
|
|
hand leaves things as they were, and anything that couldn't be read (a Semaphore
|
|
project or Gitea repo that errored, or an integration that's down) is neither
|
|
cleared nor re-announced. The first check after upgrading only records what's
|
|
already failing, so old failures aren't announced. Toggle it under Settings →
|
|
Notifications. For Gitea this follows the repo's most recent run on any
|
|
workflow or branch, the same as the Gitea page shows.
|
|
|
|
**Maintenance mode** silences alerts about one server, integration, or DNS
|
|
provider while you work on it (server offline / disk, storage and Synology
|
|
health, Proxmox backup alerts, and "integration down" for that service type).
|
|
Every window has a fixed end (5 minutes to 7 days) and expires on its own, and
|
|
a problem that began during a window and is still present when it ends alerts
|
|
then — a forgotten window can't hide an outage. A banner shows what's currently
|
|
silenced to every signed-in user.
|
|
|
|
**Ports** — each server's detail page has a Ports card for finding free ports
|
|
and remembering what each one is for. "Scan…" runs a TCP scan of a port range
|
|
from the app against the server's address (private addresses only, up to
|
|
20,000 ports at a time) and lists what's open plus the ranges that were
|
|
confirmed free; a free range can be clicked to reserve a port. Any port can
|
|
carry a service name and a comment, and a port with a note counts as taken
|
|
even when nothing is listening. The agent also reports what is bound on the
|
|
host (`ss`), which catches services listening on localhost only — a scan from
|
|
elsewhere can't see those, so they'd otherwise look free. Re-run the agent
|
|
install one-liner on a host to pick that up.
|
|
|
|
The app is installable as a PWA — "Install app" / "Add to Home Screen" from the
|
|
browser gives it its own icon and a standalone window on phone or desktop. This
|
|
needs the site to be served over HTTPS (browsers only offer install on secure
|
|
origins; `localhost` also counts). The bundled service worker deliberately
|
|
caches nothing, so an installed copy always shows the current build.
|
|
|
|
## Requirements
|
|
|
|
- Node.js 20+
|
|
- An Authentik instance reachable from wherever this app runs
|
|
|
|
## 1. Set up an Authentik application
|
|
|
|
1. Create an **OAuth2/OpenID Provider**:
|
|
- Redirect URI: `<APP_BASE_URL>/auth/callback`
|
|
- Scopes: `openid`, `email`, `profile`
|
|
2. Create an **Application** using that provider, and assign the users/groups
|
|
who should be able to sign in — Authentik controls who can authenticate;
|
|
the app's own admin/operator/viewer roles control what they can do once in.
|
|
3. Copy the provider's issuer URL, client ID, and client secret into `.env`.
|
|
|
|
## 2. Local development
|
|
|
|
```bash
|
|
cp .env.example .env # fill in AUTHENTIK_*, SESSION_SECRET, CREDENTIALS_ENCRYPTION_KEY
|
|
npm install
|
|
npm run dev:server # http://localhost:3000 (API)
|
|
npm run dev:web # http://localhost:5173 (Vite dev server, proxies /api and /auth to :3000)
|
|
```
|
|
|
|
Visit `http://localhost:5173` during development. Database migrations run
|
|
automatically on server start. SQLite data lands in `./data` (gitignored).
|
|
|
|
Generate `SESSION_SECRET` and `CREDENTIALS_ENCRYPTION_KEY` with:
|
|
|
|
```bash
|
|
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
|
|
```
|
|
|
|
## 3. Run with Docker
|
|
|
|
```bash
|
|
cp .env.example .env
|
|
# edit .env
|
|
docker compose -f docker-compose.dev.yml up -d --build # build locally
|
|
# or, once an image is published to your registry:
|
|
docker compose up -d
|
|
```
|
|
|
|
The app listens on `HOST_PORT` (default `3000`); SQLite data persists in
|
|
`./data` on the host.
|