esh-pfi-infrastructure

1,312 Commits 2 Branches 5 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
vh	94899d6fa3	feat(uptimekuma): normalize names off Homepage, publish the status page, restore the widget NAMES. Homepage already answers "what is this service called", so the monitor name is now that name verbatim -- a second naming authority is how drift starts, and an alert reading "[Uptime Kuma] Beszel hub is DOWN" sends you hunting for a card that does not exist. Only two rows moved (Beszel hub -> Beszel, Dozzle hub -> Dozzle); the " hub" suffixes were mine, not the services'. The remaining mixed case is deliberate and is now documented as such. talk, vor and task-board are lowercase on Homepage and in their own repos; title-casing them here would make this board disagree with both. What actually looked messy was scripts/kuma's own ASCII-ordinal sort, which buried every lowercase name below every capitalised one. Fixed to case-insensitive. ⚠ RENAME SAFETY, which this pass needed and did not have. The seed keys on NAME, so editing a name would have read as a brand-new monitor: added fresh, with the old row orphaned, still checking, still alerting, and holding all the history. `rename_from:` names the old row for one run. Verified: both renamed monitors kept their IDs and all 67 heartbeats. Added with it, an orphan warning for any row on the board the spec no longer names -- because a forgotten monitor keeps paging. Its first cut diffed against the PRE-EDIT snapshot and so cried wolf on its own successful renames; it re-reads the board now. A warning that fires on its own correct work is worse than no warning. STATUS PAGE + WIDGET. The Homepage uptimekuma widget reads a PUBLISHED status page (/api/status-page/<slug>), not the admin API -- which is why the widget labels were deliberately absent from the rebuild: a dashboard widget pointed at a 404 is the suspected mechanism behind both of Homepage's unkillable D-state wedges, so shipping one on purpose would have been daft. The page now exists at slug `nethealth` (the pre-rebuild slug, so old references still resolve) and is DECLARED IN monitors.yaml, applied by `kuma seed`. Same principle as the notification channel: a from-scratch rebuild restores the page, the channel and the monitors together, and nothing the widget depends on lives only in Kuma's database. Verified in a browser: "13 SITES UP / 0 SITES DOWN / 100% UPTIME" on the dashboard. ⚠ saveStatusPage calls imgDataUrl.startsWith() unconditionally, so passing null throws and leaves the page CREATED BUT EMPTY -- which reads as success from /api/status-page (200, correct title) while the group list is silently blank. Pass "" instead. Commented at the call site.	2026-09-22 00:55:29 -07:00
vh	3a85a6bce1	feat(uptimekuma): rebuild on 2.5.5 as the fleet's service layer, with a client Homepage sat dead for three days in September while every monitoring tool reported correctly. Beszel said its host was up -- it was. Uptime Kuma was not watching it. The dashboard fell into the seam between two working instruments. Measured before changing anything: - Beszel: 18 hosts x {Status, CPU, Memory, Disk, Temperature}. Its alerts table is (system, name, value, min) -- there is NO url column, so it is structurally incapable of "this endpoint should return 200". Not a config gap; the data model. - Uptime Kuma: 6 rows, 2 of them folders. Four real monitors, all firewalls. - So the two are NOT redundant. They are disjoint, and the service layer between them was empty. REBUILT FROM SCRATCH, operator-authorised ("uptime-kuma was never really used... you can even dump the existing container and config"). Nothing was migrated, which also skipped the one-way v1->v2 database migration. - Pinned to 2.5.5. `:latest` is a documented trap now: upstream keeps it on the 1.x line, so an August 2026 pull produced an image BUILT 2024-12-20 running 1.23.16. Verified by digest -- latest and 1 share one digest while 2/next carry 2.5.5. Pinned exactly, not floating on 2, for the same reason. - Moved esh-docker-vm -> ana-docker. House placement rule puts cross-site services beside the Beszel and Dozzle hubs, and esh-docker-vm has wedged unkillably twice in four months. A monitor also cannot report the failure of the host it runs on, so it should not share a failure domain with the host layer. - Normalised restart: always -> unless-stopped, which the 2026-08-18 README flagged as worth doing on the next deliberate touch. - UPTIME_KUMA_DB_TYPE=sqlite in the compose skips 2.x's interactive database screen, so the stack comes up ready rather than parked on a form. scripts/kuma is a first-party Socket.IO client, because both obvious paths are wrong: there is no REST CRUD API in EITHER major version (server/routers/ holds exactly two files, /metrics + badges + status pages), and the community wrapper uptime-kuma-api is abandoned -- last release 2023-09-26, ceiling 1.23.1, no 2.x support ever. ⚠ getMonitorList's callback returns only {ok:true}; the list arrives as a SEPARATE pushed monitorList event. Reading the ack yields an empty board that looks authoritative -- which duplicated all 13 rows on the first re-seed before the bug was found. The client now waits for the push, and carries a dedupe verb because of it. 13 monitors seeded from monitors.yaml, keyed on name so a re-run updates rather than forking the board -- proven by re-running it (0 added, 13 updated), not assumed. Every URL was probed before being written: all 200. A board that ships red teaches everyone to ignore it. Verified: 13 rows, no duplicates, all UP with "200 - OK" read from the database WITH its WAL (a first read of kuma.db alone showed a stale 26 -- the copy predated the deletes). Homepage renders exactly one Uptime Kuma card. ⚠ NOT YET WIRED: notification delivery. The board detects but tells nobody, which is the same gap this work exists to close. The beszel-althing bridge hardcodes a [Beszel] subject prefix and hub footer, so routing Kuma through it unchanged would mislabel the alerts. Needs a decision before it is generalised.	2026-09-21 22:59:37 -07:00
vh	9d92c4bd21	fix(homepage): pin UltraSeedbox to one tab, dedupe Uptime Kuma, size columns to members UltraSeedbox had no layout: entry, and Homepage renders an untabbed group on every tab — eight full-width bookmark bars repeated four times. Pinned to Main with a row layout. Uptime Kuma rendered twice: a manual services.yaml block under Monitoring plus homepage.group=Apps on the container. Dropped the manual block, moved the label to Monitoring, added homepage.siteMonitor. Adopted the previously unmanaged uptimekuma stack into stacks/ so the label is version-controlled. Column counts declared more columns than groups had members, leaving the last row of several groups mostly empty. Columns now track member counts. Also records an UNRESOLVED regression: since the container was recreated the client render has lost its tab bar, wallpaper and i18n. Ruled out the config changes (committed pre-cleanup config reproduces it) and v2.0.0 (v1.13.2 reproduces it). Server HTML still carries the tab markup, so the loss is client-side. Details in the stack README.	2026-08-18 19:12:02 -07:00

Author

SHA1

Message

Date

vh

94899d6fa3

feat(uptimekuma): normalize names off Homepage, publish the status page, restore the widget

NAMES. Homepage already answers "what is this service called", so the monitor
name is now that name verbatim -- a second naming authority is how drift starts,
and an alert reading "[Uptime Kuma] Beszel hub is DOWN" sends you hunting for a
card that does not exist. Only two rows moved (Beszel hub -> Beszel, Dozzle hub
-> Dozzle); the " hub" suffixes were mine, not the services'.

The remaining mixed case is deliberate and is now documented as such. talk, vor
and task-board are lowercase on Homepage and in their own repos; title-casing
them here would make this board disagree with both. What actually looked messy
was scripts/kuma's own ASCII-ordinal sort, which buried every lowercase name
below every capitalised one. Fixed to case-insensitive.

⚠ RENAME SAFETY, which this pass needed and did not have. The seed keys on NAME,
so editing a name would have read as a brand-new monitor: added fresh, with the
old row orphaned, still checking, still alerting, and holding all the history.
`rename_from:` names the old row for one run. Verified: both renamed monitors
kept their IDs and all 67 heartbeats.

Added with it, an orphan warning for any row on the board the spec no longer
names -- because a forgotten monitor keeps paging. Its first cut diffed against
the PRE-EDIT snapshot and so cried wolf on its own successful renames; it
re-reads the board now. A warning that fires on its own correct work is worse
than no warning.

STATUS PAGE + WIDGET. The Homepage uptimekuma widget reads a PUBLISHED status
page (/api/status-page/<slug>), not the admin API -- which is why the widget
labels were deliberately absent from the rebuild: a dashboard widget pointed at
a 404 is the suspected mechanism behind both of Homepage's unkillable D-state
wedges, so shipping one on purpose would have been daft.

The page now exists at slug `nethealth` (the pre-rebuild slug, so old references
still resolve) and is DECLARED IN monitors.yaml, applied by `kuma seed`. Same
principle as the notification channel: a from-scratch rebuild restores the page,
the channel and the monitors together, and nothing the widget depends on lives
only in Kuma's database. Verified in a browser: "13 SITES UP / 0 SITES DOWN /
100% UPTIME" on the dashboard.

⚠ saveStatusPage calls imgDataUrl.startsWith() unconditionally, so passing null
throws and leaves the page CREATED BUT EMPTY -- which reads as success from
/api/status-page (200, correct title) while the group list is silently blank.
Pass "" instead. Commented at the call site.

2026-09-22 00:55:29 -07:00

vh

3a85a6bce1

feat(uptimekuma): rebuild on 2.5.5 as the fleet's service layer, with a client

Homepage sat dead for three days in September while every monitoring tool
reported correctly. Beszel said its host was up -- it was. Uptime Kuma was not
watching it. The dashboard fell into the seam between two working instruments.

Measured before changing anything:
  - Beszel: 18 hosts x {Status, CPU, Memory, Disk, Temperature}. Its alerts
    table is (system, name, value, min) -- there is NO url column, so it is
    structurally incapable of "this endpoint should return 200". Not a config
    gap; the data model.
  - Uptime Kuma: 6 rows, 2 of them folders. Four real monitors, all firewalls.
  - So the two are NOT redundant. They are disjoint, and the service layer
    between them was empty.

REBUILT FROM SCRATCH, operator-authorised ("uptime-kuma was never really
used... you can even dump the existing container and config"). Nothing was
migrated, which also skipped the one-way v1->v2 database migration.

  - Pinned to 2.5.5. `:latest` is a documented trap now: upstream keeps it on
    the 1.x line, so an August 2026 pull produced an image BUILT 2024-12-20
    running 1.23.16. Verified by digest -- latest and 1 share one digest while
    2/next carry 2.5.5. Pinned exactly, not floating on 2, for the same reason.
  - Moved esh-docker-vm -> ana-docker. House placement rule puts cross-site
    services beside the Beszel and Dozzle hubs, and esh-docker-vm has wedged
    unkillably twice in four months. A monitor also cannot report the failure
    of the host it runs on, so it should not share a failure domain with the
    host layer.
  - Normalised restart: always -> unless-stopped, which the 2026-08-18 README
    flagged as worth doing on the next deliberate touch.
  - UPTIME_KUMA_DB_TYPE=sqlite in the compose skips 2.x's interactive database
    screen, so the stack comes up ready rather than parked on a form.

scripts/kuma is a first-party Socket.IO client, because both obvious paths are
wrong: there is no REST CRUD API in EITHER major version (server/routers/ holds
exactly two files, /metrics + badges + status pages), and the community wrapper
uptime-kuma-api is abandoned -- last release 2023-09-26, ceiling 1.23.1, no 2.x
support ever.

  ⚠ getMonitorList's callback returns only {ok:true}; the list arrives as a
  SEPARATE pushed monitorList event. Reading the ack yields an empty board that
  looks authoritative -- which duplicated all 13 rows on the first re-seed
  before the bug was found. The client now waits for the push, and carries a
  dedupe verb because of it.

13 monitors seeded from monitors.yaml, keyed on name so a re-run updates rather
than forking the board -- proven by re-running it (0 added, 13 updated), not
assumed. Every URL was probed before being written: all 200. A board that ships
red teaches everyone to ignore it.

Verified: 13 rows, no duplicates, all UP with "200 - OK" read from the database
WITH its WAL (a first read of kuma.db alone showed a stale 26 -- the copy
predated the deletes). Homepage renders exactly one Uptime Kuma card.

⚠ NOT YET WIRED: notification delivery. The board detects but tells nobody,
which is the same gap this work exists to close. The beszel-althing bridge
hardcodes a [Beszel] subject prefix and hub footer, so routing Kuma through it
unchanged would mislabel the alerts. Needs a decision before it is generalised.

2026-09-21 22:59:37 -07:00

vh

9d92c4bd21

fix(homepage): pin UltraSeedbox to one tab, dedupe Uptime Kuma, size columns to members

UltraSeedbox had no layout: entry, and Homepage renders an untabbed group on
every tab — eight full-width bookmark bars repeated four times. Pinned to Main
with a row layout.

Uptime Kuma rendered twice: a manual services.yaml block under Monitoring plus
homepage.group=Apps on the container. Dropped the manual block, moved the
label to Monitoring, added homepage.siteMonitor. Adopted the previously
unmanaged uptimekuma stack into stacks/ so the label is version-controlled.

Column counts declared more columns than groups had members, leaving the last
row of several groups mostly empty. Columns now track member counts.

Also records an UNRESOLVED regression: since the container was recreated the
client render has lost its tab bar, wallpaper and i18n. Ruled out the config
changes (committed pre-cleanup config reproduces it) and v2.0.0 (v1.13.2
reproduces it). Server HTML still carries the tab markup, so the loss is
client-side. Details in the stack README.

2026-08-18 19:12:02 -07:00