Files
felhom.eu/STATUS.md
T

121 lines
8.4 KiB
Markdown

# STATUS — what works, what's broken, what's next
**Ready for the first real tester (Tester-2): yes. You confirmed the tunnel route and the connect mails (2026-09-30).**
**Updated 2026-10-04: off-site safety finished. Both demo boxes run controller 0.290.0 and host agent 0.138.0. Hub
0.128.0. New installs get golden 0.290.0 with agent 0.138.0; every box's floor is 0.290.0.**
## Today (2026-10-04): off-site safety finished
- **The weekly clean-up is ON and no longer stops itself.** The fake-backup check now skips young copies that a manual
backup replaced the same day, instead of refusing. I ran one window on demo-hp: no refusal, nothing removed
(127 → 127), because every candidate was still young. The first real removals come when those copies are older than
8 days — around 11 October. demo-felhom gets its first window at its next night run.
- **DooPlex keeps 8 weekly copies of ep0** (your choice). Old copies go weekly; anything ep0 deletes still never reaches
the copy by itself. Today's nightly copy ran fine.
- **tester-1's 3 old keys are gone.** The daily alarm for tester-1 stopped. (You got one last alarm mail this morning,
sent just before I removed them.)
- **A restore from the DooPlex copy works.** I restored demo-hp's whole box onto a scratch machine in about 3 minutes,
read its data, then deleted it. **One trap found:** a restored box starts automatically and points at the real
drives. Run beside the original, that would be two copies of the same box. I switched it off in time; the runbook
now warns, and a row asks to make it safe by default.
- **"Delete my old set-aside backups" works again.** The hub does it, 7 days after the household's request; the
household or you can cancel in that time. Tested on tester-1 with a planted test folder.
- **Your answers are recorded**, including that you keep the current Hetzner key for now (a row holds the 3 steps).
- **Rows:** 6 closed, 4 opened. The list went from 330 to 328.
## Today (2026-10-03, evening): your choices A and A — built
- **A box can no longer delete its off-site backups.** Both demo boxes now use a key that can only add. I tried a
delete from each box: refused. Old backups all stayed (demo-felhom 11 → 13, demo-hp 91 → 100).
- **No box gets the storage password any more.** The box gives the hub only its public key; the hub puts it in the
storage account. I asked for the password with demo-hp's own login: refused.
- **The hub keeps the passwords locked (encrypted).** A copy of the hub database no longer reveals them.
- **Every day the hub checks each storage account's key file.** It found old unlocked keys from earlier boxes:
4 on demo-felhom's account and 5 on demo-hp's — now removed. tester-1's account still has 3 (its box is gone); you
get a daily alarm for it until they go.
- **The weekly clean-up window works, but it is switched OFF.** I opened one window on demo-hp by hand: it opened,
the fake-backup check refused, and it closed in 3 seconds. The check refused because I had made a manual backup
today — it is too strict. I fix that next; until then nothing deletes old backups (there is plenty of room).
- **ep0's whole-box backups are copied to DooPlex every night.** First copy: 12 GB in 3 minutes, all 4 backups.
DooPlex cannot read them (encrypted per household). A failed copy mails you; the test mail arrived.
- **One bug, found and fixed live:** the first new box version misread its backup count as 0, and you got one
false alarm mail ("demo-felhom: fell from 11 to 0"). **Ignore that mail.** Fixed 15 minutes later (0.289.1).
- **Rows:** 3 closed, 6 opened, 1 opened and closed the same day. The list went from 327 to 330.
## Today (2026-10-03, later): off-site backup safety, step 1 — measured, nothing built
- **The "add only" lock works.** I tested it on tester-1's storage account (your choice; no box uses it now).
New backups go in. Restore works. Every delete is refused. I put the account back exactly as it was.
- **But the lock alone does not protect us yet.** A broken-into box can ask the hub for the storage password.
With that password it can log in and remove the lock. First the box must stop getting the password.
- **A second trap:** with "add only", an attacker can add fake backups dated in the future. The normal
clean-up rule then deletes all the real backups. Any clean-up must check for this.
- **The hub keeps every storage password in plain form.** Anyone who reads the hub database can delete
every household's off-site backups. New row.
- **ep0:** Hetzner cannot snapshot the extra disk at all. One of the three old ideas does not exist.
- **Rows:** 2 closed, 3 opened. The list went from 326 to 327 rows. The dated check for 6 October is done.
## Today (2026-10-03): the to-do list is in order — paperwork only, no machine touched
- **Finished items left the open list.** It went from 442 rows to 326. Nothing was deleted; each moved row names
where its full text is.
- **Every open row now has one category and one severity** (P1 now · P2 before the first paying customer · P3
during the first customers · P4 later). **No row is P1.** 27 rows are P2.
- **Two new automatic checks** refuse a finished row left in the open list, and a new row without a category or a
severity.
- **Your four new items are on the roadmap:** security updates for the box's own system; legal pages and business
papers; "what if the household leaves Felhom"; a second login step for the dashboard. Two of them are also real
findings today: **a box never receives system security updates**, and **the website has no privacy notice,
terms or imprint.**
- The ranked list and my reasoning: the triage recommendation in the audits folder.
**Tester-2 — read only, from the hub.** The customer record exists. Tester-2's box has not registered yet.
## Today (afternoon): every app checked again
- **No data-loss fault.** I checked all 58 apps with the fixed check. It made each app really save something, then
looked where the data landed. **No app saves data where the backup does not copy it.**
- **40 apps: proven correct. 18 apps: not proven either way.** In those 18 the check could not fill every folder (for
example an upload folder stays empty because my test saves no upload). Nothing was found outside a backed-up folder.
I list them and work on them later.
- **papra was broken for new installs, now fixed.** It needs more memory than its limit, so a fresh install crashed in a
loop. I measured it and raised the limit. No box runs papra.
- **plant-it's program image is gone from Docker Hub.** It is already hidden from new installs. No box runs it.
## Removing an app now tells the truth (your choice A)
- When the household removes an app, its own files (books, videos) **stay**. The dialog and the result now say so, and
name the folder. Proven on the scratch box: the video was still there after the remove.
## Before the first paying customer
Everything here must be done before the first customer who pays:
1. **SparkyFitness:** written permission from the author (the e-mail draft is ready). If none → hidden from new installs.
2. **Tandoor:** written permission from the authors. If none → hidden from new installs.
3. **A lawyer reviews the licence list** (Tandoor, SparkyFitness, Emby, n8n, Plex, the paid "enterprise" parts, Redis).
4. **Agent updates:** I may sign agent updates only until the first paying customer; after that you sign them.
Your licence decisions are recorded: Emby, Plex and n8n stay. recipe-importer needs nothing unless we share it.
## Also today
- **New version 0.288.0 and a new golden (0.288.0).**
- **Rows.** 7 closed, 6 opened. The list went from 436 to 442 rows.
## What needs you
0. **Nothing new from the off-site work.** The Hetzner key change stays your call whenever you want it (3 steps, in
the list).
1. **plant-it:** keep the hidden template as it is, or remove it entirely (its image no longer exists). **If you say
nothing:** it stays hidden; nothing runs it.
2. **Send the SparkyFitness request, and ask the Tandoor authors** (the "Before the first paying customer" list).
3. **Phone test (2 minutes), only if you want it:** say so, and I put MeTube back on demo-hp with a family login.
## Standing steps
- **Monthly security re-test: last run 2026-10-01, next due ~2026-11-01.** (You start it with the standing brief.)
- **Weekly:** the golden bake (next around 9 October; today's bake was 0.288.0).
- **Registry clean-up:** only when the registry disk fills; "show me" mode first, then a person decides.