night 2026-10-22: D3 wording in the volunteer guides (the website change is a ready patch — a push publishes); D6 drill-reader proof; P3 research; P6 repos-private readers (read only)
gates / gates (push) Successful in 16m8s

This commit is contained in:
2026-10-22 16:22:28 +02:00
parent 1b442bcc2e
commit 0639cf0772
12 changed files with 729 additions and 11 deletions
@@ -0,0 +1,322 @@
diff --git a/website/CHANGELOG.md b/website/CHANGELOG.md
index e3fb6756..3c7999c4 100644
--- a/website/CHANGELOG.md
+++ b/website/CHANGELOG.md
@@ -1,4 +1,22 @@
-## 2026-10-22 — the download pages point at installer 1.30.0 (W1, W7; operator yes)
+## 2026-10-22 (night) — the privacy wording says what is true; the minimum machine is written down (D3 / R-985, D5 / R-991; operator rulings 15:47) — committed, NOT published — publish is the operator's morning yes
+
+- **D3 (R-985):** every promise that „nobody, not even us" can read the remote backup now says the whole truth.
+ The box encrypts the backup with a key made on the box; the recovery code is made on the box, shown once, and we keep
+ no copy; we hold only the locked key package and cannot open it; from the remote storage and the hub nobody can read
+ the backup. **New, stated plainly:** while the box runs, the operator has root access for support, and with it could
+ reach the data and the backup key on the box. Pages: `biztonsagimentes` / `en/backups`, `gyik` / `en/faq` („Ti
+ hozzáfértek az adataimhoz?", JSON-LD too), `szolgaltatasok` / `en/services`, `sajat-felho-tarhely` /
+ `en/own-cloud-storage`, `adatkezeles` (§6, §7, §8) and `feltetelek` (§6, §7: „a távoli mentésed nem nyitható ki" now
+ only when the box is lost AND the code is lost). Sources: `documentation/architecture/03-host-agent.md` §8a,
+ `07-backup-architecture.md` §2, `13-threat-model.md` §5. The volunteer guide (both languages) got the same wording.
+- **D5 (R-991, R-993 merged):** the minimum machine — x86-64, 4 cores, 8 GB memory, 256 GB SSD; recommended 16 GB and
+ 512 GB; not supported: Raspberry Pi / ARM, Synology / QNAP, routers, rented cloud servers. New block „Milyen gépre
+ telepíthető?" / „Which machines can it install on?" in the „Mielőtt letöltöd" card of `letoltes` / `en/download`
+ (installer version, links and checksum untouched); one paragraph in the FAQ „Milyen gépre van szükségem?" (JSON-LD
+ too); the estimator page's advice list now names the memory floor (`gepigeny` / `en/sizing`). `sizing-data.json`
+ unchanged. Nothing enforces the floor at install time (R-993's measurement) — that stays the operator's call.
+
+## 2026-10-22 — the download pages point at installer 1.30.0 (W1, W7; operator yes)
- `letoltes.html` and `en/download.html`: version, both links, the side-file link, the two check commands and the SHA-256
now name `felhom-installer-1.30.0-pve9.2-1.iso` (`590d7b9b…74d5cc1`, the same 1 705 324 544 bytes). Published and
diff --git a/website/adatkezeles.html b/website/adatkezeles.html
index 10617a03..53256372 100644
--- a/website/adatkezeles.html
+++ b/website/adatkezeles.html
@@ -250,8 +250,8 @@
</ul>
<p>
<strong>A kulcsletétről, egyszerűen:</strong> a mentésed kulcsát csak lezárt formában tároljuk.
- Kinyitni csak a <strong>helyreállító kódoddal</strong> lehet, ami nálunk nincs meg. Ha elveszíted
- ezt a kódot, a távoli mentésed nem nyitható ki — mi sem tudjuk kinyitni.
+ Kinyitni csak a <strong>helyreállító kódoddal</strong> lehet, ami nálunk nincs meg. Ha a szervered
+ tönkremegy, és ezt a kódot is elveszíted, a távoli mentésed nem nyitható ki — mi sem tudjuk kinyitni.
</p>
<!-- source: documentation/architecture/07-backup-architecture.md:67-75 ("genuinely zero-knowledge… R exists in zero system copies by design") -->
<p>
@@ -265,8 +265,9 @@
<h2>7. A szervered adatainak távoli mentése</h2>
<p>
A szervereden lévő adatokról távoli mentés készül. <strong>A mentés nálad, a szerveren
- titkosítódik, mielőtt elhagyja az otthonodat.</strong> Sem a tárhely üzemeltetője, sem mi nem
- tudjuk elolvasni a tartalmát.
+ titkosítódik, mielőtt elhagyja az otthonodat.</strong> A tárhelyen lévő tartalmát sem a tárhely
+ üzemeltetője, sem mi nem tudjuk elolvasni. A működő szervereden lévő kulcsot a rendszergazdai
+ hozzáférésünkkel elérhetnénk (lásd a 8. pontot).
</p>
<!-- source: documentation/architecture/01-topology-and-trust.md:118 ("ciphertext only (operator can't read)"); 07-backup-architecture.md:378-379 -->
<ul>
@@ -288,7 +289,7 @@
<p>
Őszintén: <strong>rendszergazdai (root) hozzáférésünk van minden szerverhez, amit kezelünk.</strong>
Ez kell a frissítésekhez, a mentések ellenőrzéséhez és a hibák javításához. Ezzel a hozzáféréssel
- a szervereden tárolt adatok elérhetők. Csak üzemeltetésre és hibaelhárításra használjuk.
+ a szervereden tárolt adatok és a távoli mentés kulcsa is elérhetők. Csak üzemeltetésre és hibaelhárításra használjuk.
</p>
<!-- source: documentation/architecture/07-backup-architecture.md:49-52 ("The operator holds root SSH on every box… 'The operator cannot read customer data' was never the security property") -->
<p>
diff --git a/website/biztonsagimentes.html b/website/biztonsagimentes.html
index 256bd383..e6f8293e 100644
--- a/website/biztonsagimentes.html
+++ b/website/biztonsagimentes.html
@@ -269,8 +269,9 @@
<p>Egy lemezen minden helyi másolat <strong>ugyanazon a lemezen</strong> van. Ez véd a véletlen törlés és a hibás fájlok ellen, de egy lemezhiba ellen nem. Lemezhiba ellen <strong>egy másik lemez</strong> vagy a <strong>távoli mentés</strong> véd. A Felhom ezt meg is mutatja: csak akkor számol második másolatot, ha biztosan tudja, hogy az egy másik lemezen van, és ha ezt nem tudja ellenőrizni (például egy virtuális gépben), azt ki is írja.</p>
<h3 style="margin-top: 24px;"><svg class="ico-lg" aria-hidden="true"><use href="/assets/icons.svg?v=1#i-lock"/></svg> A helyreállítási kód – amit csak te ismersz</h3>
- <p>A távoli mentésed titkosított, és a titkosítás kulcsa egy <strong>helyreállítási kód</strong>. Ez a kód pontosan egyszer jelenik meg: a te képernyődön, a beállításkor. Nálunk nem marad belőle másolat.</p>
- <p>Ez tudatos döntés, és két oldala van. Az egyik, hogy a távoli mentésedet rajtad kívül <strong>senki</strong> nem tudja elolvasni – mi sem. A másik, hogy ha a doboz megsemmisül és a kód is elveszett, akkor a távoli mentés <strong>nekünk sem visszaállítható</strong>. Ezért a kód papírra kerül, és jó helyre.</p>
+ <p>A távoli mentésedet a doboz titkosítja, mielőtt az elhagyja az otthonodat. A kulcs a dobozon készül, és ott is marad. A kulcsról a doboz egy lezárt másolatot is készít, amit a <strong>helyreállítási kód</strong> nyit. Ezt a lezárt másolatot mi őrizzük, de kinyitni nem tudjuk. A kód is a dobozon készül, és pontosan egyszer jelenik meg: a te képernyődön, a beállításkor. Nálunk nem marad belőle másolat.</p>
+ <p>Ez tudatos döntés, és két oldala van. Az egyik: a távoli tárhelyen csak a titkosított mentés van, nálunk pedig csak a lezárt kulcs. Ezekből <strong>senki</strong> nem tudja elolvasni a mentésedet – mi sem. A másik: ha a doboz megsemmisül és a kód is elveszett, akkor a távoli mentés <strong>nekünk sem visszaállítható</strong>. Ezért a kód papírra kerül, és jó helyre.</p>
+ <p>Egy dolgot őszintén elmondunk. Amíg a dobozod működik, támogatás céljából <strong>rendszergazdai (root) hozzáférésünk</strong> van hozzá. Ezzel a dobozon lévő adataidat és a mentés kulcsát is elérhetnénk. Ezt a hozzáférést csak üzemeltetésre és hibaelhárításra használjuk. A helyreállítási kód tehát a távoli másolatot védi, nem a működő dobozt.</p>
<h3 style="margin-top: 24px;"><svg class="ico-lg" aria-hidden="true"><use href="/assets/icons.svg?v=1#i-chart-column"/></svg> Monitoring és értesítések</h3>
<p>A mentéseket folyamatosan figyeljük. Ha probléma van – sikertelen mentés, betelő tárhely, kapcsolati hiba – az a felügyeleti rendszerünkben megjelenik, és e-mail értesítés is indul róla. A zárt teszt egyik célja épp az, hogy ezeket az értesítéseket éles körülmények között csiszoljuk.</p>
diff --git a/website/en/backups.html b/website/en/backups.html
index 6815c02b..1f44eaf8 100644
--- a/website/en/backups.html
+++ b/website/en/backups.html
@@ -269,8 +269,9 @@
<p>On one disk, every local copy is <strong>on the same disk</strong>. That protects against deleting something by mistake and against broken files, but not against a disk failure. A <strong>different disk</strong> or the <strong>remote backup</strong> protects against a disk failure. Felhom shows this too: it counts a second copy only when it knows for sure that the copy is on another disk, and when it cannot check that (for example inside a virtual machine), it says so.</p>
<h3 style="margin-top: 24px;"><svg class="ico-lg" aria-hidden="true"><use href="/assets/icons.svg?v=1#i-lock"/></svg> The recovery code – only you know it</h3>
- <p>Your remote backup is encrypted, and the key to the encryption is a <strong>recovery code</strong>. The code appears exactly once: on your screen, when it is set up. We keep no copy of it.</p>
- <p>This is a deliberate choice, and it has two sides. One: <strong>nobody</strong> but you can read your remote backup – not even us. The other: if the box is destroyed and the code is lost too, then <strong>we cannot restore</strong> the remote backup either. So the code goes on paper, and somewhere safe.</p>
+ <p>The box encrypts your remote backup before it leaves your home. The key is made on the box, and it stays there. The box also makes a locked copy of the key, which the <strong>recovery code</strong> opens. We keep that locked copy, but we cannot open it. The code is made on the box too, and it appears exactly once: on your screen, when it is set up. We keep no copy of it.</p>
+ <p>This is a deliberate choice, and it has two sides. One: the remote storage holds only the encrypted backup, and we hold only the locked key. From these, <strong>nobody</strong> can read your backup – not even us. The other: if the box is destroyed and the code is lost too, then <strong>we cannot restore</strong> the remote backup either. So the code goes on paper, and somewhere safe.</p>
+ <p>One thing we tell you honestly. While your box runs, we have <strong>administrator (root) access</strong> to it for support. With it, we could reach the data on the box and the backup key too. We use this access only to run the service and to fix faults. So the recovery code protects the remote copy, not the running box.</p>
<h3 style="margin-top: 24px;"><svg class="ico-lg" aria-hidden="true"><use href="/assets/icons.svg?v=1#i-chart-column"/></svg> Monitoring and notifications</h3>
<p>We watch the backups all the time. If there is a problem – a failed backup, storage filling up, a connection fault – it shows up in our monitoring, and an e-mail goes out about it. One aim of the closed test is to polish these notifications in real use.</p>
diff --git a/website/en/download.html b/website/en/download.html
index 5cadb7b5..36f7271a 100644
--- a/website/en/download.html
+++ b/website/en/download.html
@@ -92,6 +92,11 @@
<p>Installing <strong>erases every piece of data</strong> on the disk you select. The installer never chooses for you: it lists the disks with their size and type, and overwrites the one you pick.</p>
<p>Unplug the external drive you use for backups before you start. If you are not certain which disk is the right one, <strong>stop and call your operator</strong>.</p>
<p>The guide from your operator describes every step, screen by screen. Do not start without it.</p>
+ <h3 style="margin-top: 24px;"><svg class="ico-lg" aria-hidden="true"><use href="/assets/icons.svg?v=1#i-cpu"/></svg> Which machines can it install on?</h3>
+ <p><strong>At least:</strong> an x86-64 processor (Intel or AMD) with 4 cores, N100 class or newer; 8 GB of memory; a 256 GB SSD.</p>
+ <p><strong>Recommended:</strong> 16 GB of memory and a 512 GB SSD. Photos and films go on a separate data drive.</p>
+ <p><strong>Not supported:</strong> Raspberry Pi and other ARM boards, Synology / QNAP, routers, rented cloud servers.</p>
+ <p>To estimate how much memory your own apps need, use the <a href="/en/sizing">Which machine do I need?</a> page.</p>
</div>
</div>
</section>
diff --git a/website/en/faq.html b/website/en/faq.html
index c5a9ee00..ad41161a 100644
--- a/website/en/faq.html
+++ b/website/en/faq.html
@@ -77,7 +77,7 @@
"name": "What machine do I need?",
"acceptedAnswer": {
"@type": "Answer",
- "text": "For most homes a mini PC (for example with an Intel N100 processor and 16-32 GB of RAM) is perfectly fine. They are quiet, energy-saving (15-35 W) and compact – one fits on the shelf next to the router. If you want more storage (for a film library, say), you can add a NAS or external hard drives. More detailed set-ups are on the Technology page. To estimate how big a machine your own apps need, use the Which machine do I need? page."
+ "text": "For most homes a mini PC (for example with an Intel N100 processor and 16-32 GB of RAM) is perfectly fine. They are quiet, energy-saving (15-35 W) and compact – one fits on the shelf next to the router. The smallest machine: an x86-64 processor (Intel or AMD) with 4 cores, 8 GB of memory and a 256 GB SSD. Recommended: 16 GB of memory and a 512 GB SSD. Not supported: Raspberry Pi and other ARM boards, Synology / QNAP, routers, rented cloud servers. If you want more storage (for a film library, say), you can add a NAS or external hard drives. More detailed set-ups are on the Technology page. To estimate how big a machine your own apps need, use the Which machine do I need? page."
}
},
{
@@ -197,7 +197,7 @@
"name": "Can you get at my data?",
"acceptedAnswer": {
"@type": "Answer",
- "text": "That is an important, fair question, and I answer it honestly. For support and maintenance I normally have remote access to your server – as any IT provider has to the systems it manages. I need it to check backups, install updates and fix faults. The key to your remote backup, though, only you know: the recovery code appears once, on your screen, and I keep no copy of it. So I cannot read the remote backup either. Important: unlike the big cloud providers, Felhom does no algorithmic analysis of your data and no profiling for advertising, and your data leaves your home only encrypted (the remote backup)."
+ "text": "That is an important, fair question, and I answer it honestly. For support and maintenance I have administrator (root) remote access to your server – as any IT provider has to the systems it manages. I need it to check backups, install updates and fix faults. With this access I could reach the data on your server and the backup key too. I use it only to run the service and to fix faults. The box encrypts your remote backup before it leaves your home, and the key is made on the box. The recovery code only you know: it appears once, on your screen, and I keep no copy of it. So I cannot read your backup from the remote storage or from my central system. On the running box, though, I could reach the key with the access above. Important: unlike the big cloud providers, Felhom does no algorithmic analysis of your data and no profiling for advertising, and your data leaves your home only encrypted (the remote backup)."
}
},
{
@@ -533,6 +533,7 @@
</button>
<div class="faq-answer"><div class="faq-answer-inner">
<p>For most homes a <strong>mini PC</strong> (for example with an Intel N100 processor and 16-32 GB of RAM) is perfectly fine. They are quiet, energy-saving (15-35 W) and compact – one fits on the shelf next to the router.</p>
+ <p><strong>The smallest machine:</strong> an x86-64 processor (Intel or AMD) with 4 cores, 8 GB of memory and a 256 GB SSD. Recommended: 16 GB of memory and a 512 GB SSD. Not supported: Raspberry Pi and other ARM boards, Synology / QNAP, routers, rented cloud servers.</p>
<p>If you want more storage (for a film library, say), you can add a NAS or external hard drives. More detailed set-ups are on the <a href="/en/technology#hardware">Technology</a> page.</p>
<p>To estimate how big a machine your own apps need, use the <a href="/en/sizing">Which machine do I need?</a> page.</p>
</div></div>
@@ -711,8 +712,8 @@
</button>
<div class="faq-answer"><div class="faq-answer-inner">
<p>That is an important, fair question, and I answer it honestly.</p>
- <p>For support and maintenance I normally have remote access to your server – as any IT provider has to the systems it manages. I need it to check backups, install updates and fix faults.</p>
- <p>The key to your remote backup, though, <strong>only you know</strong>: the recovery code appears once, on your screen, and I keep no copy of it. So I cannot read the remote backup either.</p>
+ <p>For support and maintenance I have administrator (root) remote access to your server – as any IT provider has to the systems it manages. I need it to check backups, install updates and fix faults. With this access I could reach the data on your server and the backup key too. I use it only to run the service and to fix faults.</p>
+ <p>The box encrypts your remote backup before it leaves your home, and the key is made on the box. The recovery code <strong>only you know</strong>: it appears once, on your screen, and I keep no copy of it. So I cannot read your backup from the remote storage or from my central system. On the running box, though, I could reach the key with the access above.</p>
<p>Important: unlike the big cloud providers, Felhom does <strong>no algorithmic analysis of your data</strong> and no profiling for advertising, and your data leaves your home only encrypted (the remote backup).</p>
</div></div>
</div>
diff --git a/website/en/own-cloud-storage.html b/website/en/own-cloud-storage.html
index c9f0ec12..49b558f8 100644
--- a/website/en/own-cloud-storage.html
+++ b/website/en/own-cloud-storage.html
@@ -219,7 +219,7 @@
</div>
<div class="info-card">
<p>Your files are on the machine standing at your home. Every night the server makes backups by itself, on three levels: on the box, on a second drive if there is one, and encrypted on remote storage.</p>
- <p>The remote copy leaves encrypted, and the key is yours: without the recovery code that copy cannot be read. The machine belongs to you, and there is no storage subscription that climbs year after year.</p>
+ <p>The remote copy leaves encrypted. The key is made on your box, and your recovery code, which only you know, opens its locked copy. So nobody at the remote storage can read it. For support, I have administrator access to the running box. The machine belongs to you, and there is no storage subscription that climbs year after year.</p>
<p>The details are written out on the <a href="/en/backups">Backups</a> page.</p>
</div>
</div>
diff --git a/website/en/services.html b/website/en/services.html
index c34dae4f..f88310cc 100644
--- a/website/en/services.html
+++ b/website/en/services.html
@@ -129,7 +129,7 @@
</li>
<li class="caps-item">
<h4><svg class="ico-lg" aria-hidden="true"><use href="/assets/icons.svg?v=1#i-lock"/></svg> A recovery code only you know</h4>
- <p>The key to your remote backup's encryption is a recovery code that appears exactly once — on your screen. I do not know it and cannot recreate it. That also means that without the code, I cannot read the remote backup either: keep it somewhere safe.</p>
+ <p>The box encrypts your remote backup, and a recovery code locks its key. The code appears exactly once — on your screen. I do not know it and cannot recreate it. If the box breaks, you need this code to bring the remote backup back: keep it somewhere safe. For support I have administrator access to the running box; the <a href="/en/backups">Backups</a> page says more.</p>
</li>
<li class="caps-item">
<h4><svg class="ico-lg" aria-hidden="true"><use href="/assets/icons.svg?v=1#i-rotate-cw"/></svg> Restore when something goes wrong</h4>
diff --git a/website/en/sizing.html b/website/en/sizing.html
index 7f6d34cb..870807b2 100644
--- a/website/en/sizing.html
+++ b/website/en/sizing.html
@@ -96,8 +96,9 @@
<section class="shell-section sizer-advice-section">
<h2>What the machine needs</h2>
<ul class="sizer-advice">
- <li>Processor: x86-64 (Intel or AMD), 4 cores, N100 class or newer.</li>
- <li>System disk: a 256 GB SSD; 512 GB recommended.</li>
+ <li>Processor: x86-64 (Intel or AMD), at least 4 cores, N100 class or newer.</li>
+ <li>Memory: at least 8 GB; 16 GB recommended.</li>
+ <li>System disk: at least a 256 GB SSD; 512 GB recommended.</li>
<li>Photos and films go on a separate data drive.</li>
<li>Not supported: Raspberry Pi and other ARM boards, Synology / QNAP, routers, rented cloud servers.</li>
</ul>
diff --git a/website/feltetelek.html b/website/feltetelek.html
index 299acd16..4bb27e9b 100644
--- a/website/feltetelek.html
+++ b/website/feltetelek.html
@@ -155,7 +155,7 @@
<h2>6. Hozzáférünk a szerveredhez</h2>
<p>
<strong>Rendszergazdai (root) hozzáférésünk van a szerverhez.</strong> Ez kell a frissítésekhez,
- a mentés ellenőrzéséhez és a hibák javításához. Ezzel a szerveren lévő adatok elérhetők. Csak
+ a mentés ellenőrzéséhez és a hibák javításához. Ezzel a szerveren lévő adatok és a távoli mentés kulcsa is elérhetők. Csak
üzemeltetésre és hibaelhárításra használjuk.
</p>
<!-- source: documentation/architecture/07-backup-architecture.md:49-52 -->
@@ -165,11 +165,11 @@
</p>
<!-- source: documentation/architecture/01-topology-and-trust.md:97-105 (box-initiated control, signed jobs) -->
- <h2>7. A mentésed kulcsa nálad van</h2>
+ <h2>7. A mentésed kódja nálad van</h2>
<p>
A távoli mentésed titkosítva készül. A kulcsát egy <strong>helyreállító kód</strong> zárja, amit
- csak te ismersz — nálunk nincs meg, és nem tudjuk pótolni. <strong>Ha elveszíted, a távoli
- mentésed nem nyitható ki.</strong> Tedd el jól.
+ csak te ismersz — nálunk nincs meg, és nem tudjuk pótolni. <strong>Ha a szerver tönkremegy, és a kódot is
+ elveszíted, a távoli mentésed nem nyitható ki.</strong> Tedd el jól.
</p>
<!-- source: documentation/architecture/07-backup-architecture.md:67-83 -->
diff --git a/website/gepigeny.html b/website/gepigeny.html
index e33f4b75..e318ef6f 100644
--- a/website/gepigeny.html
+++ b/website/gepigeny.html
@@ -96,8 +96,9 @@
<section class="shell-section sizer-advice-section">
<h2>Amit a géptől várok</h2>
<ul class="sizer-advice">
- <li>Processzor: x86-64 (Intel vagy AMD), 4 mag, N100 kategória vagy újabb.</li>
- <li>Rendszerlemez: 256 GB SSD; ajánlott az 512 GB.</li>
+ <li>Processzor: x86-64 (Intel vagy AMD), legalább 4 mag, N100 kategória vagy újabb.</li>
+ <li>Memória: legalább 8 GB; ajánlott a 16 GB.</li>
+ <li>Rendszerlemez: legalább 256 GB SSD; ajánlott az 512 GB.</li>
<li>A fotók és a filmek külön adatlemezre kerüljenek.</li>
<li>Nem támogatott: Raspberry Pi és más ARM gépek, Synology / QNAP, routerek, bérelt felhőszerverek.</li>
</ul>
diff --git a/website/gyik.html b/website/gyik.html
index 41229a30..72123a9b 100644
--- a/website/gyik.html
+++ b/website/gyik.html
@@ -77,7 +77,7 @@
"name": "Milyen gépre van szükségem?",
"acceptedAnswer": {
"@type": "Answer",
- "text": "A legtöbb otthoni felhasználónak egy mini PC (pl. Intel N100 processzorral, 16-32 GB RAM-mal) tökéletesen megfelel. Ezek csendesek, energiatakarékosak (15-35W fogyasztás), és kompaktak – elfér a polcon a router mellett. Ha nagyobb tárhelyet szeretnél (pl. filmes könyvtárhoz), egy NAS-al vagy külső merevlemezekkel bővíthető. Részletesebb konfigurációkat a Technológiák oldalon találsz. Hogy a te alkalmazásaidhoz mekkora gép kell, a Milyen gép kell? oldalon becsülheted meg."
+ "text": "A legtöbb otthoni felhasználónak egy mini PC (pl. Intel N100 processzorral, 16-32 GB RAM-mal) tökéletesen megfelel. Ezek csendesek, energiatakarékosak (15-35W fogyasztás), és kompaktak – elfér a polcon a router mellett. A legkisebb gép: x86-64 processzor (Intel vagy AMD) 4 maggal, 8 GB memória és 256 GB SSD. Ajánlott: 16 GB memória és 512 GB SSD. Nem támogatott: Raspberry Pi és más ARM gépek, Synology / QNAP, routerek, bérelt felhőszerverek. Ha nagyobb tárhelyet szeretnél (pl. filmes könyvtárhoz), egy NAS-al vagy külső merevlemezekkel bővíthető. Részletesebb konfigurációkat a Technológiák oldalon találsz. Hogy a te alkalmazásaidhoz mekkora gép kell, a Milyen gép kell? oldalon becsülheted meg."
}
},
{
@@ -197,7 +197,7 @@
"name": "Ti hozzáfértek az adataimhoz?",
"acceptedAnswer": {
"@type": "Answer",
- "text": "Ez egy fontos és jogos kérdés, amire őszintén válaszolok. A támogatás és karbantartás érdekében alapesetben van távoli hozzáférésem a szerveredhez – ahogy bármely IT szolgáltatónak a kezelt rendszerekhez. Ez szükséges a mentések ellenőrzéséhez, frissítések telepítéséhez, és hibaelhárításhoz. A távoli mentésed kulcsát viszont csak te ismered: a helyreállítási kód egyszer jelenik meg, a te képernyődön, és nálam nem marad belőle másolat. A távoli mentést így én sem tudom elolvasni. Fontos: szemben a nagy felhőszolgáltatókkal, a Felhomnál nincs algoritmikus adatelemzés, nincs reklámcélú profilozás, és az adataid csak titkosítva hagyják el az otthonodat (a távoli mentés)."
+ "text": "Ez egy fontos és jogos kérdés, amire őszintén válaszolok. A támogatás és karbantartás érdekében rendszergazdai (root) távoli hozzáférésem van a szerveredhez – ahogy bármely IT szolgáltatónak a kezelt rendszerekhez. Ez szükséges a mentések ellenőrzéséhez, frissítések telepítéséhez, és hibaelhárításhoz. Ezzel a hozzáféréssel a szervereden lévő adataidat és a mentés kulcsát is elérhetném. Csak üzemeltetésre és hibaelhárításra használom. A távoli mentésedet a doboz titkosítja, mielőtt elhagyja az otthonodat, és a kulcs a dobozon készül. A helyreállítási kódot csak te ismered: egyszer jelenik meg, a te képernyődön, és nálam nem marad belőle másolat. Ezért a távoli tárhelyről és a központi rendszeremből én sem tudom elolvasni a mentésedet. A működő dobozon viszont a fenti hozzáféréssel a kulcsot is elérném. Fontos: szemben a nagy felhőszolgáltatókkal, a Felhomnál nincs algoritmikus adatelemzés, nincs reklámcélú profilozás, és az adataid csak titkosítva hagyják el az otthonodat (a távoli mentés)."
}
},
{
@@ -533,6 +533,7 @@
</button>
<div class="faq-answer"><div class="faq-answer-inner">
<p>A legtöbb otthoni felhasználónak egy <strong>mini PC</strong> (pl. Intel N100 processzorral, 16-32 GB RAM-mal) tökéletesen megfelel. Ezek csendesek, energiatakarékosak (15-35W fogyasztás), és kompaktak – elfér a polcon a router mellett.</p>
+ <p><strong>A legkisebb gép:</strong> x86-64 processzor (Intel vagy AMD) 4 maggal, 8 GB memória és 256 GB SSD. Ajánlott: 16 GB memória és 512 GB SSD. Nem támogatott: Raspberry Pi és más ARM gépek, Synology / QNAP, routerek, bérelt felhőszerverek.</p>
<p>Ha nagyobb tárhelyet szeretnél (pl. filmes könyvtárhoz), egy NAS-al vagy külső merevlemezekkel bővíthető. Részletesebb konfigurációkat a <a href="/technologiak#hardver">Technológiák</a> oldalon találsz.</p>
<p>Hogy a te alkalmazásaidhoz mekkora gép kell, a <a href="/gepigeny">Milyen gép kell?</a> oldalon becsülheted meg.</p>
</div></div>
@@ -711,8 +712,8 @@
</button>
<div class="faq-answer"><div class="faq-answer-inner">
<p>Ez egy fontos és jogos kérdés, amire őszintén válaszolok.</p>
- <p>A támogatás és karbantartás érdekében alapesetben van távoli hozzáférésem a szerveredhez – ahogy bármely IT szolgáltatónak a kezelt rendszerekhez. Ez szükséges a mentések ellenőrzéséhez, frissítések telepítéséhez, és hibaelhárításhoz.</p>
- <p>A távoli mentésed kulcsát viszont <strong>csak te ismered</strong>: a helyreállítási kód egyszer jelenik meg, a te képernyődön, és nálam nem marad belőle másolat. A távoli mentést így én sem tudom elolvasni.</p>
+ <p>A támogatás és karbantartás érdekében rendszergazdai (root) távoli hozzáférésem van a szerveredhez – ahogy bármely IT szolgáltatónak a kezelt rendszerekhez. Ez szükséges a mentések ellenőrzéséhez, frissítések telepítéséhez, és hibaelhárításhoz. Ezzel a hozzáféréssel a szervereden lévő adataidat és a mentés kulcsát is elérhetném. Csak üzemeltetésre és hibaelhárításra használom.</p>
+ <p>A távoli mentésedet a doboz titkosítja, mielőtt elhagyja az otthonodat, és a kulcs a dobozon készül. A helyreállítási kódot <strong>csak te ismered</strong>: egyszer jelenik meg, a te képernyődön, és nálam nem marad belőle másolat. Ezért a távoli tárhelyről és a központi rendszeremből én sem tudom elolvasni a mentésedet. A működő dobozon viszont a fenti hozzáféréssel a kulcsot is elérném.</p>
<p>Fontos: szemben a nagy felhőszolgáltatókkal, a Felhomnál <strong>nincs algoritmikus adatelemzés</strong>, nincs reklámcélú profilozás, és az adataid csak titkosítva hagyják el az otthonodat (a távoli mentés).</p>
</div></div>
</div>
diff --git a/website/letoltes.html b/website/letoltes.html
index f31078ea..72885f3d 100644
--- a/website/letoltes.html
+++ b/website/letoltes.html
@@ -92,6 +92,11 @@
<p>A telepítés <strong>minden adatot töröl</strong> a lemezről, amelyet kiválasztasz. A telepítő soha nem választ helyetted: felsorolja a lemezeket méretükkel és típusukkal, és azt írja felül, amelyiket te kijelölöd.</p>
<p>Húzd ki a gépből a mentésre használt külső lemezt, mielőtt elkezded. Ha nem vagy biztos benne, melyik a jó lemez, <strong>állj meg, és hívd az üzemeltetőt</strong>.</p>
<p>A lépéseket az üzemeltetőtől kapott útmutató írja le, képernyőről képernyőre. Az útmutató nélkül ne kezdd el.</p>
+ <h3 style="margin-top: 24px;"><svg class="ico-lg" aria-hidden="true"><use href="/assets/icons.svg?v=1#i-cpu"/></svg> Milyen gépre telepíthető?</h3>
+ <p><strong>Legalább:</strong> x86-64 processzor (Intel vagy AMD) 4 maggal, N100 kategória vagy újabb; 8 GB memória; 256 GB SSD.</p>
+ <p><strong>Ajánlott:</strong> 16 GB memória és 512 GB SSD. A fotók és a filmek külön adatlemezre kerüljenek.</p>
+ <p><strong>Nem támogatott:</strong> Raspberry Pi és más ARM gépek, Synology / QNAP, routerek, bérelt felhőszerverek.</p>
+ <p>Hogy a te alkalmazásaidhoz mekkora memória kell, a <a href="/gepigeny">Milyen gép kell?</a> oldalon becsülheted meg.</p>
</div>
</div>
</section>
diff --git a/website/sajat-felho-tarhely.html b/website/sajat-felho-tarhely.html
index 0066bd39..42acba09 100644
--- a/website/sajat-felho-tarhely.html
+++ b/website/sajat-felho-tarhely.html
@@ -219,7 +219,7 @@
</div>
<div class="info-card">
<p>A fájljaid a nálad álló gépen vannak. A szerver minden éjjel magától készít mentéseket, három szinten: a dobozon, egy második meghajtón, ha van, és titkosítva egy távoli tárhelyen.</p>
- <p>A távoli másolat titkosítva megy el, és a kulcs nálad van: a helyreállítási kód nélkül az a másolat nem olvasható. A gép a tiéd, és nincs tárhely-előfizetés, ami évről évre drágul.</p>
+ <p>A távoli másolat titkosítva megy el. A kulcs a dobozodon készül, és a lezárt másolatát a helyreállítási kódod nyitja, amit csak te ismersz. A távoli tárhelyen így senki nem tudja elolvasni. A működő dobozhoz támogatás céljából nekem rendszergazdai hozzáférésem van. A gép a tiéd, és nincs tárhely-előfizetés, ami évről évre drágul.</p>
<p>A részletek a <a href="/biztonsagimentes">Biztonsági mentés</a> oldalon vannak leírva.</p>
</div>
</div>
diff --git a/website/szolgaltatasok.html b/website/szolgaltatasok.html
index 133af98c..926ab1af 100644
--- a/website/szolgaltatasok.html
+++ b/website/szolgaltatasok.html
@@ -129,7 +129,7 @@
</li>
<li class="caps-item">
<h4><svg class="ico-lg" aria-hidden="true"><use href="/assets/icons.svg?v=1#i-lock"/></svg> Helyreállítási kód, amit csak te ismersz</h4>
- <p>A távoli mentésed titkosításának kulcsa egy helyreállítási kód, ami pontosan egyszer jelenik meg: a te képernyődön. Én nem ismerem, és nem tudom visszaállítani. Ez azt is jelenti, hogy a kód nélkül a távoli mentés nekem sem olvasható: tedd el jól.</p>
+ <p>A távoli mentésedet a doboz titkosítja, és a kulcsát egy helyreállítási kód zárja. A kód pontosan egyszer jelenik meg: a te képernyődön. Én nem ismerem, és nem tudom pótolni. Ha a doboz tönkremegy, a távoli mentés visszahozásához kell ez a kód: tedd el jól. A működő dobozhoz támogatás céljából rendszergazdai hozzáférésem van; erről a <a href="/biztonsagimentes">Biztonsági mentés</a> oldal ír.</p>
</li>
<li class="caps-item">
<h4><svg class="ico-lg" aria-hidden="true"><use href="/assets/icons.svg?v=1#i-rotate-cw"/></svg> Visszaállítás, ha baj van</h4>
@@ -0,0 +1,16 @@
read drill (ls-remote): OK
read drill API: 200
write drill (create a file via API): 403
push drill (git, dry-run against the server's receive-pack): 403
read other private admin/cc-secrets: 404 / git REFUSED
read other private admin/homelab-manifests: 404 / git REFUSED
read other private admin/jarr: 404 / git REFUSED
read other private admin/jarr-social: 404 / git REFUSED
read the public live catalog with the token: 13f9c9cb
drill HEAD: 256d65f6
# 9202 pointed at the drill catalog the 09 §6.5 way (2026-10-22 ~15:57 CEST): controller.yaml saved as
# controller.yaml.pre-d6-1022; git.repo_url = admin/app-catalog-drill, git.username = drill-reader, git.token = sec
# DRILL_CATALOG_TOKEN (written on the guest from stdin, never on a command line); catalog-cache removed; restart.
# The controller log 13:57:44 UTC: "Cloning https://gitea.dooplex.hu/admin/app-catalog-drill.git → …/catalog-cache"
# (no error); the cache HEAD 256d65f (the drill main); remote.origin.url is the PLAIN URL (R-616: no token stored).
@@ -0,0 +1,99 @@
# Part 3 — the data-loss candidates: research (night of 2026-10-22)
Research by a helper (read only; it changed nothing). Saved by the main session from the helper's report (the helper's
own write was refused by the harness). Baselines: controller cbc944c (v0.339.0), agent 2d5840b (v0.162.0), felhom.eu
1b442bcc. Architecture read: `07` §6.1.1, §10.2 (rows R-359, R-87), the design headers in R-899 `nightowed.go`,
`nightchain.go`, `offbox_clear.go`, R-822 `offbox_window.go`, hub F-14 `pbsdr.go`. Live reads: demo-hp's agent journal
(backup lines — `demohp-whole-box-completions.txt`) and `docker ps` on 9202. The main session's proofs and fixes are
recorded in the night report; this file is the input.
| Item | Verdict | Reason | Action |
|---|---|---|---|
| 1187a symlink | REAL (code) | `appexport/fabplan.go:292-310` follows a link; the tar write fails; `export.go:712` drops the whole drive folder; the export still ends „done" | fix + red-proof, P2 |
| 1187b owner/symlink | REAL (code) | `appexport/restore.go:1138-1183` handles only dirs and regular files, no chown | fold with (a) |
| 1187c stopped-app import | REAL (code) | `restore.go:355-374` removes the volumes only when the app RUNS; `docker cp` merges | 9202 proof, then refuse |
| 1187d | PLAUSIBLE | no `restoreOpBlocked` check in `StartImport` | fold into (c) |
| 1187f | REAL (code) | the bundle's HDD_PATH is used; an empty one gives a relative path | stays in the row |
| 1187g | REAL (code) | `classifyDBImage` does not know postgis (adventurelog, dawarich); psql without ON_ERROR_STOP | small fix, 9202 proof |
| 1188b | REAL in code, unlikely | `backup/restore.go:218` drops the rm error, then untars into the old volume | P4 |
| 1188c | ALREADY FIXED | v0.337.0, `TestR1188c_ALeftoverTempDoesNotBlockTheRetry` | close |
| 1188d | REAL (wording) | 30-min cap; scratch is kept, so a second press probably continues (not measured) | measure, then the sentence |
| 1188e | REAL, P4 | `offbox_restore.go:675-679` reads latest, `_ = id` | P4 |
| 1189a | REAL, half-live | agent `localapi/server.go:1179-1192`: a future archive time gives a negative age | agent fix needs the vouch |
| 1189b | SPLIT | the skipped nights after an off-cycle run: FIXED by R-899 (v0.304.0), shown in the journal; the ~3 min/night creep is still real | close that half; creep → P4 |
| 1189c | REAL in code | quiesce waits for the catch-up and the update leg, not for a restore | 9202 recipe |
| 1189d | REAL (code) | proof 05:30 and integrity 06:00 are daily jobs; the catch-up runs only the 3 backup legs; no hub age alarm | own row, ~15-line fix |
| 1189e | REAL (code) | the hub checks „since midnight"; any HH:MM window passes | hub row |
| 1189f | OPERATOR DECISION | design question | — |
| 1189g | REAL, P4 | spring-forward 02:30 → 03:30 collides with tier2 | unit test |
| 1189h | not re-read | — | stays |
| 1189i | REAL, P4 UX | check and begin are not atomic (`web/handlers.go:1860/1881`) | P4 |
| 1190a | REAL (code) | the ceremony stages the off-site password only if off-site is configured; hub „abc"→"" demotes the good package | unit tests, ~6-line fix |
| 1190b | REAL (code) | the global bar ignores `recoveryOffer()`; the start handler does not refuse | 409 fix, P2 |
| 1190c | PLAUSIBLE | — | read-only fingerprint compare for Tester4 |
| 1190d | OPERATOR DECISION | — | — |
| 1190e/f/h | not re-read | — | stay |
| 1190g | REAL (code) | a nil AppConfig drops the app from `liveDriveBinds`, so its live folder can be listed (and deleted) as kept | fix, P2 |
| 1205 | OPERATOR DECISION | the F-14 gate is deliberate (ruling 2026-07-13) | two options to the operator |
| 1206 | no loss on the Felhom tier (by design, R-822); the NAS tier open | the guard refuses a prune while any snapshot is future-dated; the NAS tier prunes without the guard | pure unit test with the policy simulator |
## R-1187(c) — a `.fab` import into a STOPPED app merges into the old volumes. REAL (code)
`controller/internal/appexport/restore.go:355-374` removes the volumes (`RemoveStackVolumes` = `compose down --volumes`,
`cmd/controller/main.go:3566-3591`) only when `IsStackRunning` (`main.go:3467-3471`: Running or Degraded). Every other
state (household-stopped, crashed, error, starting) „overwrites config in place". `restoreVolumeData` (`:736-772`) then
runs `volume create` (a no-op on an existing volume) and `docker cp -` (`:717-732`), which adds and overwrites but
never deletes: the result is old ∪ bundle. The drive half (`restoreHDDData` `:590-648`, `extractTar`) merges in both
branches. Harm: a broken app (not running) is the likeliest import target; a stale SQLite `-wal` beside the bundle's
`.db` is a corruption shape. „No SQL dump by default" alone is NOT-A-FINDING: with stop ticked the DB volume is captured
cold, which is consistent (`export.go:258-279`, `:366`; `appbackup/dbdump.go:142-144` lists only running containers).
Fix: `executeImport`, ~8 lines — (B) refuse an import over an installed app that is not running (now); (A) remove its
volumes too, only together with the D22 put-back copy. 9202 recipe (~20 min): a throwaway uptime-kuma; MARK-A into the
volume, export (stop ticked), MARK-N; control: import while RUNNING → MARK-N gone; MARK-N again, Stop, import → MARK-N
survives + the debug line „deployed but not running — will overwrite config in place".
## R-1189(b) — split
The skipped nights after an off-cycle run are ALREADY FIXED by R-899, controller v0.304.0 (2026-10-09),
`quiesce/nightowed.go`, `TestR899_*` (6). Proven on demo-hp: before the fix every off-cycle run was followed by a
skipped night (10-01 22:10 → no 10-02; 10-05 11:19 → no 10-06; 10-08 22:20 → no 10-09); after it every one was followed
by a night run (10-17 16:33 → 10-18 04:33; 10-19 03:25 → 04:32; 10-20 08:42 → 10-21 04:32). The creep is still REAL,
low harm: agent `localapi/server.go:1184` is `age >= Cadence`, age counted from the archive START; the controller polls
every 5 min (`quiesce.go:150`) and the archive starts after the apps are stopped. Measured with no press between:
04:31:07 → 04:33:18 → 04:36:47 → 04:38:14, and 04:33:37 → 04:38:44 → 04:42:40 (~1.5–5 min/night). Unpressed, the start
reaches W+6h in ~70–80 nights, then one night is skipped (44 h is below the 48 h valve, `quiesce.go:807-818`); the hub's
26 h line (`deadline.go:29`) alarms the operator. Fix: `quiesce/tiers.go` — inside the window a tier is due when
`age >= cadence - 4h` (~6 lines, no customer data); proof: a unit test with an injected clock.
## R-1189(d) — proof and integrity never run on a box that is off at 05:30–06:00. REAL (code)
`main.go:1613` `Daily("offsite-integrity","06:00")`, `:1635` `Daily("offsite-proof","05:30")`; the scheduler picks the
next future time (`scheduler.go:499-518`) and skips late fires (`:341-346`); the catch-up runs only the three backup
legs (`main.go:1544-1553`, `catchUpLegs` `:4138`). The comment at `main.go:1601-1603` („checked the next day it is on")
is true only if the box is on at 06:00. The hub shows `offsite.last_integrity_*` (`web/offsite_box.go:199-210`) with
no age alarm. Design: `07` §10.2, R-359 („due-ness, not a weekday"). Fix: an After-hook on `nightchain.CatchUp` running
the due-gated integrity check and proof once; the comment corrected (~15 lines); optional hub age alarm. Red-proof: a
CatchUp test with a never-05:30 clock and a recording hook.
## R-1190(a) — a ceremony with off-site not configured seals no repo password and supersedes the good package. REAL (code)
`web/escrow_handlers.go:217-224` stages only if `OffboxConfigured()` (`backup/offbox.go:695-710`) — false when the target
is cleared or disabled, although `ClearOffboxTarget` deliberately keeps the password file (`offbox_clear.go` header).
The agent then seals no password (`cmd/felhom-agent/main.go:2981-3003`) and uploads sha "". Hub `SaveHostEscrow` sees
`curSHA != ""` and demotes the good package to retained custody (operator-only). `OffsiteRecoveryOffer` reads "" as
„covers no key" (`offbox.go:1855-1873`) and says nothing. Fix: stage when the password file exists (~6 lines;
`PushOffboxPasswordForEscrow` `offbox.go:800` reads only the file). Red-proof: a web test asserting the stage fn is
called; a hub store test pinning „abc"→"" ⇒ superseded.
## Other mechanism lines
1187a `fabplan.go:292-310` (a FIFO also hangs the export on `os.Open`) · 1187b `restore.go:1138-1183` · 1187g
`restore.go:1047-1056`, `933-943` vs `appbackup/dbservices.go:37` (the dump is `--clean --if-exists`, so ON_ERROR_STOP is
safe; copy `dbdump.go:775-784`) · 1188b `backup/restore.go:218` (`StopStack` is `compose down`, `stacks/manager.go:1444`)
· 1188d `web/offbox_handlers.go:455` (scratch kept, `offbox_restore.go:373-392`) · 1188e `offbox_restore.go:675-679`,
marker SnapshotID `:458` · 1189c `quiesce.go:213-275`, `:565` · 1189e hub `monitor/deadline.go:416-419`, `555-565` ·
1189i `web/handlers.go:1860`, `1881` · 1190b `web/escrow_banner.go:23-35`, `templates/backups_remote.html:144-160`
(its comment names the harm, R-199), `escrow_handlers.go:180-245`, reachable in offer shape (c) `offbox.go:1866-1870` ·
1190g `stacks/kept.go:220-235`, `336-360`, `372-389`; `deploy.go:1113-1125` (a parse error gives nil) · 1205 hub
`web/pbsdr.go:236-248`, `store.go:3293-3297` (deliberate; operator ruling 2026-07-13) · 1206 `backup/offbox_window.go:22-24`,
`130-137`.
@@ -0,0 +1,33 @@
# demo-hp agent journal, 2026-09-25..2026-10-22, whole-box completions (read-only extract, 2026-10-22 night)
# source: ssh demo-hp journalctl -u felhom-agent --since 2026-09-25 | grep 'backup: completed'
2026-09-30T13:47:12+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_09_30-13_37_38.tar.zst bytes=9978959837
2026-10-01T22:15:25+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_01-22_10_48.tar.zst bytes=4681052311
2026-10-01T22:18:31+02:00 vmid=9201 target=felhom-pbs archive=felhom-pbs:backup/ct/9201/2026-10-01T20:15:29Z bytes=15223817181
2026-10-03T04:38:20+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_03-04_33_33.tar.zst bytes=4674947408
2026-10-04T04:39:41+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_04-04_34_55.tar.zst bytes=4679944932
2026-10-05T04:40:16+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_05-04_35_24.tar.zst bytes=4882309520
2026-10-05T11:24:01+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_05-11_19_30.tar.zst bytes=4880501245
2026-10-07T04:40:48+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_07-04_35_11.tar.zst bytes=4885448692
2026-10-07T08:49:53+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_07-08_45_01.tar.zst bytes=4885939687
2026-10-08T22:25:40+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_08-22_20_43.tar.zst bytes=4887664196
2026-10-08T22:37:38+02:00 vmid=9201 target=felhom-pbs archive=felhom-pbs:backup/ct/9201/2026-10-08T20:34:27Z bytes=15886927313
2026-10-10T04:36:04+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_10-04_31_07.tar.zst bytes=4891163862
2026-10-11T04:38:55+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_11-04_33_18.tar.zst bytes=4892408175
2026-10-12T04:42:14+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_12-04_36_47.tar.zst bytes=4886425953
2026-10-13T04:43:56+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_13-04_38_14.tar.zst bytes=4893173044
2026-10-14T07:28:23+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_14-07_17_45.tar.zst bytes=14405409944
2026-10-14T09:35:17+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_14-09_28_50.tar.zst bytes=5648463064
2026-10-14T14:17:08+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_14-14_10_50.tar.zst bytes=5650197172
2026-10-15T04:40:04+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_15-04_33_37.tar.zst bytes=5701486585
2026-10-15T22:43:13+02:00 vmid=9201 target=felhom-pbs archive=felhom-pbs:backup/ct/9201/2026-10-15T20:38:47Z bytes=18841786645
2026-10-16T04:45:26+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_16-04_38_44.tar.zst bytes=5874954851
2026-10-17T04:50:13+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_17-04_42_40.tar.zst bytes=6818853501
2026-10-17T16:40:55+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_17-16_33_32.tar.zst bytes=6768484797
2026-10-18T04:40:58+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_18-04_33_15.tar.zst bytes=6916890749
2026-10-18T13:19:59+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_18-13_12_26.tar.zst bytes=6938307162
2026-10-19T03:32:49+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_19-03_25_27.tar.zst bytes=6864786948
2026-10-19T04:39:17+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_19-04_32_04.tar.zst bytes=6892633451
2026-10-20T04:41:20+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_20-04_33_27.tar.zst bytes=7149221307
2026-10-20T08:49:31+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_20-08_42_04.tar.zst bytes=7150133935
2026-10-21T04:40:20+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_21-04_32_11.tar.zst bytes=7022500164
2026-10-22T04:43:56+02:00 vmid=9201 target=local archive=local:backup/vzdump-lxc-9201-2026_10_22-04_35_58.tar.zst bytes=7025168609
@@ -0,0 +1,109 @@
# P6 — Can the repositories be private? (R-925, read only)
Night session 2026-10-22, helper. Measured 2026-10-22 ~15:50–16:10 CEST from DooPlex and from demo-hp.
Nothing was changed. No repository setting, no Secret, no file outside this folder.
No secret value is in this folder. Credentials are reported as names, byte counts, or SET/EMPTY.
Raw outputs: `02-registry-anon.txt`, `03-packages-anon.txt`, `04-box-git-config.txt`,
`05-anon-measurements.txt`, `06-argocd.txt`.
## 1. Which repositories are public today
Command: `curl -s https://gitea.dooplex.hu/api/v1/repos/admin/<repo>` (no login), field `private`.
| Repository | Anonymous API | `private` | Anonymous `git ls-remote` |
|---|---|---|---|
| admin/felhom.eu | 200 | false | rc=0 (HEAD 1b442bcc2ea8) |
| admin/felhom-controller | 200 | false | rc=0 (HEAD cbc944c3c0c9) |
| admin/felhom-agent | 200 | false | rc=0 (HEAD 2d5840ba112f) |
| admin/app-catalog-felhom.eu | 200 | false | rc=0 (HEAD 13f9c9cb139f) |
| admin/homelab-manifests | 404 | (hidden) | rc=128 "could not read Username" |
Control: a nonsense repo `admin/no-such-repo-p6` gives the same 404 / rc=128 as homelab-manifests.
So homelab-manifests is private (or absent to anonymous). ArgoCD reads it with a credential (section 3, row R12).
The four Felhom repositories are public. The user `admin` is `visibility: public`.
## 2. Package visibility (images, agent binary, golden)
Gitea docs (docs.gitea.com/usage/packages/overview, "Access restrictions"): a package belongs to its OWNER,
not to a repository. Read access for a user-owned package is "public, if user is public too".
Linking a package to a repository only lists it on the repository page.
Measured agreement (anonymous, `05-anon-measurements.txt` section G):
the images `felhom-hub`, `felhom-samba`, `jarr`, `wan-probe`, `sparkyfitness-export` have NO public repository
(anonymous repo API = 404), and an anonymous token dance still lists their tags (HTTP 200).
Result: making a REPOSITORY private does not change who can pull its images or download its packages.
Those stay public while the user `admin` is public.
## 3. The readers — each measured with no login
| # | Reader | Repo | What it reads | Credential configured? | Command (no login) | Answer |
|---|---|---|---|---|---|---|
| R1 | Website git-sync, 4 containers in Deployment `felhom-system/felhom-webpage` (`git-sync`, `git-sync-scripts`, init `git-sync-init`, init `git-sync-scripts-init`) | felhom.eu | `--repo=http://gitea.gitea-system.svc.cluster.local:3000/admin/felhom.eu.git`, ref `main` (sparse `/website/`) and ref `installer-v1.35.0` (sparse `/scripts/`) | **NO** — no env, no envFrom, no secret volume, no password/askpass arg (`sudo kubectl get deploy -A -o yaml`, parsed) | `git ls-remote http://10.43.8.106:3000/admin/felhom.eu.git HEAD` | rc=0, 1b442bcc2ea8 |
| R2 | ISO first boot (`scripts/iso/felhom-bootstrap.sh:168`) | felhom.eu (via the website, R1) | `https://felhom.eu/scripts/felhom-host-install.sh` | n/a — website, not Gitea | `curl https://felhom.eu/scripts/felhom-host-install.sh` (DooPlex and demo-hp) | 200 / 200 |
| R3 | Installer, agent config files (`felhom-host-install.sh:567`, `:2920`, `:2943`) | felhom-agent | `raw/tag/v<agent ver>/configs/<16 files>` | Only if the hub-served controller.yaml has `git.token`. All 4 measured boxes: **EMPTY** (R5). So anonymous. The script says so: "fetching artifacts ANONYMOUSLY" | `curl …/admin/felhom-agent/raw/tag/v0.162.0/configs/felhom-agent.service` (DooPlex and demo-hp host) | 200 / 200. Control nonsense path: 404 |
| R4 | Installer + agent self-update + bundle bootstrap: agent binary, config bundle, golden (generic packages) | (package, owner `admin`) | `/api/packages/admin/generic/felhom-agent/<v>/felhom-agent`, `…/felhom-config-bundle.json`, `…/felhom-golden/<v>/golden.tar.zst` | Optional; agent.json has no `selfupdate` key on felhom-pve, Tester 1, demo-hp (defaults = anonymous) | `curl -r 0-0 …/felhom-agent/0.162.0/felhom-agent`; same for bundle; golden 0.331.0 | 206 / 206 / 206. Control nonsense version: 404 |
| R5 | Controller catalog sync on every box (`controller/internal/sync/sync.go`, `git.username`/`git.token` optional) | app-catalog-felhom.eu | `https://gitea.dooplex.hu/admin/app-catalog-felhom.eu.git`, branch main, every 15m | **NO** — `git.username` and `git.token` EMPTY on demo-hp 9201, demo-hp 9202, N100 9201, Tester 1 9201 (`04-box-git-config.txt`) | `pct exec 9201 -- docker exec -e GIT_TERMINAL_PROMPT=0 felhom-controller git ls-remote …app-catalog-felhom.eu.git HEAD` (demo-hp) | 13f9c9cb139f. Positive control: controller log `[sync] Catalog sync complete` 13:57:47 UTC |
| R6 | Controller self-update image pull (`internal/selfupdate/updater.go`: anonymous token dance when no creds) | (package `felhom-controller`) | `gitea.dooplex.hu/v2/admin/felhom-controller/tags/list` | NO (same empty `git` block) | anonymous `/v2/token?…:pull` then `tags/list` | token issued; 200 with tag list. Without token: 401 (normal registry challenge) |
| R7 | k3s image pulls (hub, act-runner, wan-probe, jarr, …) | (packages) | `gitea.dooplex.hu/admin/felhom-hub:0.165.0` etc. | NO — no `imagePullSecrets` on pods or service accounts; no `/etc/rancher/k3s/registries.yaml` | anonymous token dance for `felhom-hub`, `felhom-act-runner` | 200 / 200 |
| R8 | Hub template fetcher (`hub/internal/web/templatefetcher.go:13`) | felhom-controller | `raw/branch/main/controller/configs/controller.yaml.example` | **YES** — Basic auth from env `REGISTRY_USERNAME`/`REGISTRY_TOKEN` (Secret `gitea-creds`, scoped read:package + read:repository per R-925). R-925 records a 403 when read:repository was missing, so the token IS sent | anonymous `curl` of the same URL | 200 (anonymous also works today). Hub log: `[DEBUG] Template fetched (5881 bytes)` hourly, last 15:54 |
| R9 | Hub Gitea client: tag/package probes (`hub/internal/gitea/gitea.go`), version checker (`version.go`) | felhom-agent tags, packages | `raw/tag/…`, `/api/v1/packages/admin…`, `/v2/…/tags/list` | YES — same `gitea-creds` (SetBasicAuth) | `/api/v1/packages/admin` anonymous | 401 "token is required" — this API already needs the token, so the hub already has one |
| R10 | CI (Gitea Actions, `.gitea/workflows/gates.yml` in all 4 repos) — own checkout | each repo | `git remote add origin http://gitea.gitea-system.svc.cluster.local:3000/admin/<repo>.git` + fetch | **NO** — plain git, no token in the URL or env (only `secrets.RESEND_API_KEY` is used) | `git ls-remote http://10.43.8.106:3000/admin/<repo>.git HEAD` for all 4 | rc=0 for all 4. Control nonsense repo: rc=128 |
| R11 | CI — sibling clones: felhom.eu cloned by controller, agent, catalog CI; felhom.eu CI clones agent, controller, catalog; agent CI `check-published-versions.py` reads `/api/v1/repos/admin/felhom-agent/tags` + `raw/tag` in-cluster | all 4 | as R10 | **NO** | as R10 | rc=0 |
| R12 | ArgoCD app `felhom` (`repoURL https://gitea.dooplex.hu/admin/felhom.eu.git`, path `manifests`) | felhom.eu | git | **YES** — repo-creds Secret `argocd/gitea-repo-creds` (keys url 24 bytes, username 5, password 40); its url is `https://gitea.dooplex.hu` (homelab-manifests `argocd-system/argocd-config.yaml:73`), a prefix that matches every repo on the host. Also `homelab-manifests-repo` for 47 homelab apps | n/a (credentialed) | not affected |
| R13 | Public readers of the website's `<!-- source -->` comments and of README links | felhom.eu (+ controller, agent) | repo-relative paths in served HTML; 3 docs link to Gitea source pages | n/a | `curl https://felhom.eu/<page> \| grep -c '<!-- source'` | adatkezeles 33, feltetelek 15, teszteles 7, en/testing 6 (served live) |
Not a reader: the website has no link to `gitea.dooplex.hu` (grep: 0). `build-golden.sh` fetches from Docker/Debian, not Gitea.
## 4. Verdict per repository
| Repository | Verdict |
|---|---|
| homelab-manifests | **Already private.** Its only reader (ArgoCD) has a credential. Nothing to do. |
| felhom-controller | **Can be private after one named change: CI clones with a read token** (R10). Hub reader R8 is credentialed. Boxes pull the IMAGE, which is a package and stays public (R6, section 2). Precondition to check first: the `gitea-creds` token user can read a private repo of `admin`. |
| felhom.eu | **Must stay public now, because of the website git-sync (R1).** It has no credential. Can be private after: (a) git-sync gets a read token (a Secret + `--password-file` / `GITSYNC_PASSWORD_FILE` in `manifests/webpage.yaml`), (b) CI clones with a read token (R10/R11 — three other repos clone felhom.eu as a sibling), (c) the served `<!-- source -->` comments are stripped (operator ruling 2026-10-09 in R-925). ArgoCD (R12) is already credentialed. |
| felhom-agent | **Must stay public, because every new box and every reinstall fetches 16 config files from `raw/tag/v<ver>/configs/` with no login (R3).** Can be private after: the installer takes those files from the generic package (public by owner visibility) instead of `raw/tag`, plus the CI token (R10/R11). Giving boxes a token is not a real fix: a token on a customer box is readable by the customer. |
| app-catalog-felhom.eu | **Must stay public, because every box clones it every 15 minutes with no login (R5).** A private catalog needs a read credential on every customer box, and the customer has root on that box, so the token is effectively public. Keep public. |
## 5. Decide-row text for the operator
**Make felhom-controller private now?** (felhom.eu, felhom-agent and the catalog cannot go private tonight — see section 4.)
- Yes, after one change: CI clones with a read token. Cost: one CI secret and an edit to the clone step in each
gates.yml. Gain: the controller source is no longer readable anonymously. The controller IMAGE stays
anonymously pullable (packages follow the user `admin`, not the repo), so the compiled code stays public.
- No: nothing changes. The rule "no secret may enter a public repo" (`manifest_bearer_gate.py`) stays the control.
**What breaks if the setting is wrong.** felhom.eu private: the website keeps its last checkout while the
git-sync sidecars run (`--max-failures=-1`), so it LOOKS fine. At the next pod restart the init containers
(`--one-time`) fail and the pod does not start. Then felhom.eu is down, and the ISO first boot cannot fetch
the installer (R2). felhom-agent private: the next fresh install or reinstall stops at the config fetch.
Catalog private: every box's catalog sync fails every 15 minutes.
Any repo private before the CI change: its CI job fails and mails the gate alarm.
**How to undo.** One setting: Gitea → repository → Settings → "Make repository private" → clear the box → Save.
Effect is immediate; git-sync retries every 30 s.
## 6. `<!-- source -->` comments that must change if the repos go private
Served on the live website (measured with `curl` + `grep -c`):
| Page | Count | What they cite |
|---|---|---|
| website/adatkezeles.html (/adatkezeles) | 33 | hub/ (12), documentation/ (11), manifests/ (5), website/ (2), scripts/ (1), felhom-controller (1), plus operator rulings and measurements |
| website/feltetelek.html (/feltetelek) | 15 | documentation/ (12) |
| website/teszteles.html (/teszteles) | 7 | documentation/ (3), website/ (3) |
| website/en/testing.html (/en/testing) | 6 | documentation/ (3), website/ (2) |
Total served: 61. R-925 names "32 on /adatkezeles"; today it is 33, and three more pages carry 28.
The comments cite repo-relative paths, not Gitea URLs.
Not served (in the repo only; they become private together with the repo; no change needed):
documentation/legal/* (DRAFT-adatkezelesi-tajekoztato 54, adatkezelesi-tajekoztato-1.0 32 / -1.1 33,
feltetelek-1.0 14 / -1.1 15, DRAFT-aszf 15, DRAFT-kapcsolat-hozzajarulas 4, DRAFT-impresszum 2, README 1),
documentation/runbooks/secrets.md 1, OPEN-ITEMS.md 1.
Links to Gitea source pages that stop working for anonymous readers:
`felhom-agent/README.md`, `felhom-controller/scripts/README.md`,
`felhom.eu/documentation/pilot/RUNBOOK-peti-pbsdr-2026-07-11.md`. All are operator documents.
@@ -0,0 +1,14 @@
### anonymous registry: tags/list without token
felhom-controller tags/list no-token: 401
felhom-hub tags/list no-token: 401
felhom-act-runner tags/list no-token: 401
### WWW-Authenticate header
www-authenticate: Bearer realm="https://gitea.dooplex.hu/v2/token",service="container_registry",scope="*"
### anonymous token dance (no credentials)
felhom-controller token-issued: yes
{"name":"admin/felhom-controller","tags":["0.213.0","0.214.0","0.215.0","0.216.0","0.217.0","0.218.0","0.219.0","0.220.0","0.220.1","0.220.2","0.221.0","0.221.1","0.222.0","0.223.0","0.224.0","0.225.0","0.226.0","0.226.1","0.227.0","0.227.1","0.228.0","0.229.0","0.230.0","0.231.0","0.232.0","0.233.0
felhom-hub token-issued: yes
{"name":"admin/felhom-hub","tags":["0.100.2","0.101.0","0.102.0","0.103.0","0.104.0","0.105.0","0.106.0","0.107.0","0.108.0","0.109.0","0.110.0","0.111.0","0.111.1","0.112.0","0.113.0","0.114.0","0.115.0","0.116.0","0.117.0","0.118.0","0.118.1","0.119.0","0.120.0","0.121.0","0.122.0","0.123.0","0.12
felhom-act-runner token-issued: yes
{"name":"admin/felhom-act-runner","tags":["0.1.0"]} http 200
@@ -0,0 +1,9 @@
## Package listing and owner visibility (anonymous, 2026-10-22 ~15:55 CEST)
GET https://gitea.dooplex.hu/api/v1/users/admin -> {'login': 'admin', 'visibility': 'public'}
GET https://gitea.dooplex.hu/api/v1/packages/admin -> 401 {"message":"token is required"} (the API listing needs a token)
GET https://gitea.dooplex.hu/admin/-/packages (web page) -> 200, lists:
container: felhom-act-runner felhom-controller felhom-hub felhom-samba jarr recipe-importer revfulop-calendar sparkyfitness-export wan-probe
generic: felhom-agent felhom-golden (newest golden on the page: 0.331.0)
Anonymous pull tests of packages whose repo is NOT public: see 05-anon-measurements.txt section G.
Gitea docs, docs.gitea.com/usage/packages/overview "Access restrictions": user-owned package read = "public, if user is public too";
"A package always belongs to an owner (a user or organisation), not a repository."
@@ -0,0 +1,32 @@
### demo-hp guest 9201 — git: block of /opt/docker/felhom-controller/controller.yaml (username/token reduced to SET/EMPTY)
git:
branch: main
repo_url: https://gitea.dooplex.hu/admin/app-catalog-felhom.eu.git
sync_interval: 15m
token: <EMPTY>
username: <EMPTY>
### demo-hp guest 9202 — git: block of /opt/docker/felhom-controller/controller.yaml (username/token reduced to SET/EMPTY)
git:
branch: main
repo_url: https://gitea.dooplex.hu/admin/app-catalog-felhom.eu.git
sync_interval: 15m
token: <EMPTY>
username: <EMPTY>
== felhom-pve
running: 9201
### felhom-pve guest 9201
git:
branch: main
repo_url: https://gitea.dooplex.hu/admin/app-catalog-felhom.eu.git
sync_interval: 15m
token: <EMPTY>
username: <EMPTY>
== root@192.168.0.154
running: 9201
### root@192.168.0.154 guest 9201
git:
branch: main
repo_url: https://gitea.dooplex.hu/admin/app-catalog-felhom.eu.git
sync_interval: 15m
token: <EMPTY>
username: <EMPTY>
@@ -0,0 +1,57 @@
# Anonymous measurements, 2026-10-22T15:57:56+02:00, from DooPlex (no credential; GIT_ASKPASS=/bin/false, global git config disabled)
## A. repo API private flag (anonymous GET /api/v1/repos/admin/<repo>)
felhom.eu: http 200 private=False
felhom-controller: http 200 private=False
felhom-agent: http 200 private=False
app-catalog-felhom.eu: http 200 private=False
homelab-manifests: http 404 private=n/a
## B. git ls-remote, public URL
https://gitea.dooplex.hu/admin/felhom.eu.git: rc=0 1b442bcc2ea8
https://gitea.dooplex.hu/admin/felhom-controller.git: rc=0 cbc944c3c0c9
https://gitea.dooplex.hu/admin/felhom-agent.git: rc=0 2d5840ba112f
https://gitea.dooplex.hu/admin/app-catalog-felhom.eu.git: rc=0 13f9c9cb139f
https://gitea.dooplex.hu/admin/homelab-manifests.git: rc=128 error: unabl :: fatal: could not read Username for 'https://gitea.dooplex.hu': terminal prompts disabled
control (nonsense repo): rc=128 error: unabl :: fatal: could not read Username for 'https://gitea.dooplex.hu': terminal prompts disabled
## C. git ls-remote, in-cluster service URL (the URL git-sync and CI use)
http://10.43.8.106:3000/admin/felhom.eu.git: rc=0 1b442bcc2ea8
http://10.43.8.106:3000/admin/felhom-controller.git: rc=0 cbc944c3c0c9
http://10.43.8.106:3000/admin/felhom-agent.git: rc=0 2d5840ba112f
http://10.43.8.106:3000/admin/app-catalog-felhom.eu.git: rc=0 13f9c9cb139f
control (nonsense repo): rc=128 error: unabl :: fatal: could not read Username for 'http://10.43.8.106:3000': terminal prompts disabled
## D. raw files, public URL
felhom-controller template (hub fetcher): 200
felhom-agent raw/tag/v0.162.0/configs/felhom-agent.service (installer): 200
felhom.eu raw/tag/installer-v1.35.0/scripts/felhom-host-install.sh: 200
app-catalog raw/branch/main/README.md: 200
control nonsense path: 404
## E. generic packages (HEAD-equivalent: range 0-0), public URL
felhom-agent/0.162.0/felhom-agent: 206
felhom-agent/0.162.0/felhom-config-bundle.json: 206
felhom-golden/0.85.1/golden.tar.zst: 404
control nonsense version: 404
package listing API anon (/api/v1/packages/admin): 401
package web page anon (/admin/-/packages): 200
## F. website (felhom.eu) — what the ISO first boot fetches
https://felhom.eu/scripts/felhom-host-install.sh: 200
## G. package visibility vs repo visibility (anonymous)
golden 0.331.0 (range 0-0): 206
container jarr: anon tags/list=200 ; anon repo admin/jarr api=404 ; repo links on package page: none
container wan-probe: anon tags/list=200 ; anon repo admin/wan-probe api=404 ; repo links on package page: none
container felhom-hub: anon tags/list=200 ; anon repo admin/felhom-hub api=404 ; repo links on package page: none
container sparkyfitness-export: anon tags/list=200 ; anon repo admin/sparkyfitness-export api=404 ; repo links on package page: none
container felhom-samba: anon tags/list=200 ; anon repo admin/felhom-samba api=404 ; repo links on package page: none
## I. from a box (demo-hp host and its guest 9201), anonymous
guest 9201 controller container: git ls-remote catalog (no credential): 13f9c9cb139f
guest 9201 catalog cache origin URL has no userinfo:
host: agent raw config at tag (installer path): 200
host: agent binary package (range 0-0): 206
host: website installer: 200
controller sync positive log on 9201 (last 2 sync lines):
2026/10/22 13:57:47 sync.go:299: [INFO] [sync] Catalog sync complete
2026/10/22 13:57:47 sync.go:155: [INFO] [sync] Periodic sync: Sablonok naprakészek — nincs változás
@@ -0,0 +1,17 @@
## H. ArgoCD (read only)
applications per repoURL:
1 https://charts.goauthentik.io https://gitea.dooplex.hu/admin/homelab-manifests.git
1 https://cloudnative-pg.github.io/charts https://gitea.dooplex.hu/admin/homelab-manifests.git
1 https://gitea.dooplex.hu/admin/felhom.eu.git
43 https://gitea.dooplex.hu/admin/homelab-manifests.git
1 https://kubernetes-sigs.github.io/external-dns/ https://gitea.dooplex.hu/admin/homelab-manifests.git
1 https://mojo2600.github.io/pihole-kubernetes/https://mojo2600.github.io/pihole-kubernetes/ https://gitea.dooplex.hu/admin/homelab-manifests.git
1 https://raw.githubusercontent.com/plexinc/pms-docker/gh-pages https://gitea.dooplex.hu/admin/homelab-manifests.git
felhom app:
https://gitea.dooplex.hu/admin/felhom.eu.git path=manifests
repository secrets (names only):
NAME TYPE DATA AGE
homelab-manifests-repo Opaque 4 309d
repo-creds secrets (names only):
NAME TYPE DATA AGE
gitea-repo-creds Opaque 3 309d
@@ -119,9 +119,9 @@ After connecting, the box's screen says: "Felhom — the box is linked. Setup ca
## 7. The recovery code (~2 minutes) — do not skip this
The box sends an **encrypted** copy of your files to Felhom's remote storage. **Only you** get the
key to that encryption: it is the **recovery code**. Until you create it, **the remote backup does
not start**.
The box sends an **encrypted** copy of your files to Felhom's remote storage. The key to that
encryption is made on the box. The **recovery code** opens a locked copy of the key, and **only you**
get that code. Until you create it, **the remote backup does not start**.
**When the yellow bar appears (about 15 minutes after the box is connected)**, that is the moment. *(2026-09-30)* The box spends
its first minutes preparing the remote storage, and until then it cannot create the code — which is
@@ -136,9 +136,14 @@ it refreshes itself.
3. The code is shown **once and once only**. **Write it on paper** and put it where you keep your
important documents. A photo on your phone is not enough if the phone is lost too.
> ⚠ **Felhom cannot get this code back for you.** Not because we will not: your copies are encrypted
> so that we ourselves cannot open them. If the code is lost, the remote copies remain, but
> **nobody — not us either — can open them again**.
> ⚠ **Felhom cannot get this code back for you.** Not because we will not: the box makes the code,
> and we keep no copy of it. From the remote storage we ourselves cannot open your copies. If the box
> breaks and the code is lost too, the remote copies remain, but **nobody — not us either — can open
> them again**.
>
> One thing we tell you honestly: while your box runs, we have administrator (root) access to it for
> support. With it, we could reach the data on the box and the backup key too. We use it only to run
> the service and to fix faults.
Once you are done, the bar disappears and the remote backup starts by itself. New apps go into the
remote backup by themselves (controller v0.283.0). If the Backup page says "Some apps have no off-site
+10 -5
View File
@@ -131,8 +131,8 @@ Az összekötés után a doboz képernyője ezt írja: „Felhom — a doboz ös
## 7. A helyreállítási kód (~2 perc) — ezt ne hagyd ki
A doboz a fájljaidról **titkosított** másolatot küld a Felhom távoli tárhelyére. A titkosítás
kulcsát **csak te** kapod meg: ez a **helyreállítási kód**. Amíg nem hozod létre, **a távoli
mentés nem indul el**.
kulcsa a dobozon készül. A kulcs lezárt másolatát a **helyreállítási kód** nyitja, és ezt a kódot
**csak te** kapod meg. Amíg nem hozod létre, **a távoli mentés nem indul el**.
**Amikor a sárga sáv megjelenik (a doboz összekötése után kb. 15 perccel),** akkor jött el az ideje. *(2026-09-30)* A doboz az
első perceket a távoli tárhely előkészítésével tölti, és addig a kódot még nem tudja létrehozni — ezért
@@ -148,9 +148,14 @@ magától frissül.
3. A kód **egyetlen egyszer** jelenik meg a képernyőn. **Írd fel papírra**, és tedd el oda, ahová a
fontos iratokat teszed. Fénykép a telefonról nem elég, ha a telefon is elveszik.
> ⚠ **A Felhom nem tudja visszaszerezni ezt a kódot.** Nem azért, mert nem akarja: a másolataidat
> úgy titkosítják, hogy mi magunk se tudjuk megnyitni őket. Ha a kód elvész, a távoli másolatok
> megmaradnak, de **senki — mi sem — nem tudja többé megnyitni őket**.
> ⚠ **A Felhom nem tudja visszaszerezni ezt a kódot.** Nem azért, mert nem akarja: a kódot a doboz
> készíti, és nálunk nem marad belőle másolat. A távoli tárhelyről mi magunk se tudjuk megnyitni a
> másolataidat. Ha a doboz tönkremegy, és a kód is elvész, a távoli másolatok megmaradnak, de
> **senki — mi sem — nem tudja többé megnyitni őket**.
>
> Egy dolgot őszintén elmondunk: amíg a dobozod működik, támogatás céljából rendszergazdai (root)
> hozzáférésünk van hozzá. Ezzel a dobozon lévő adataidat és a mentés kulcsát is elérhetnénk. Csak
> üzemeltetésre és hibaelhárításra használjuk.
Ha ezzel megvagy, a sáv eltűnik, és a távoli mentés magától elindul. Az új alkalmazások maguktól
bekerülnek a távoli mentésbe (vezérlő v0.283.0). Ha a Biztonsági mentés oldalon azt látod: „Van