dc0bb9f0dc50bdb5929a6f81d4ced6fe9b0004b4
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 HarmenandClaude Opus 5
|
fd62f48309 |
De Tor hidden service is de tweede weg naar binnen, en die staat nergens
De gebruiker vroeg of Evolu Relay kwaad kan op zijn Umbrel. Het eerlijke antwoord was nee met twee kanttekeningen, en de tweede stond in geen enkel bestand: umbrelOS maakt per app een Tor hidden service en die stond gewoon aan. Samen met PROXY_AUTH_ADD: "false" betekent dat de relay bereikbaar vanaf het internet, alleen beschermd doordat het .onion-adres onraadbaar is. De gebruiker zet hem uit. Wat dit lastig maakt om te zien: het staat niet in de compose van de app. Je kunt dat bestand volledig lezen en concluderen dat alleen je LAN erbij kan. Vandaar dat het nu op drie plekken staat: in de compose bij de instelling waar de afweging gemaakt wordt, in het plan bij de statuspagina-vraag, en in de naslag. De naslag is de belangrijkste van die drie, want het mechanisme is een eigenschap van umbrelOS en geldt voor elke app. Het gevolg niet: bij Electrum Gate legt dezelfde hidden service alleen de inlogpagina bloot, want daar staat de proxy-inlog aan en loopt de TLS-poort niet via de proxy. Die vergelijking staat er als tabel bij, want de instelling alleen zegt niets; het is de combinatie. Opgemerkt door de gebruiker dat het ook voor Electrum Gate zou gelden. Deels terecht, en dat is precies waarom het in de gedeelde naslag hoort en niet in het plan van één app. Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
730621d850 |
De image in het eigen register, gepind op digest
umbreld haalt elke image via de Docker Engine API op, dus een lokaal gebouwde tag is voor hem onbereikbaar. De image staat nu in het Gitea-register op dezelfde server als deze store, en anoniem halen werkt daar: dat is dezelfde voorwaarde als voor het klonen van de store zelf, en de eigenaar sysop staat publiek. Beide services krijgen tag plus digest. De digest hoort erbij en niet alleen de tag, want een tag kan opnieuw geduwd worden en dan draait er iets anders dan er in de repo staat. De toets in tests/test_appstore_vorm.py drukt de pinstatus af en beide regels staan nu op "gepind"; van Electrum Gate nog geen. Wat er expres bij staat in commentaar: dit is de digest van één architectuur. Er is alleen amd64 geduwd, want deze Umbrel is amd64. Voor de officiele store moet het een multi-arch index-digest zijn met arm64 erin, en dat is buildx met QEMU. Zonder die notitie leest een gepinde digest als "eis gehaald". build.sh wijst nu ook naar het register, anders levert een volgende bouw weer een tag op waar de compose niet naar kijkt. De slotregels van het script zijn geen suggestie meer maar de resterende stappen: push, digest overnemen, version verhogen, en anoniem controleren met een uitgelogde pull in dezelfde context als de login. Manifest naar 0.0.2, met release notes die zeggen waarom: 0.0.1 was niet te installeren. Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
96565085a5 |
umbreld pullt buiten compose om, dus pull_policy kon nooit werken
De installatie faalde, en de foutmelding was voorspelbaar maar de oorzaak niet:
pull access denied for whatsnext/evolu-relay
at /opt/umbreld/node_modules/docker-modem/lib/modem.js:382:17
Die stacktrace is het punt. De pull komt uit docker-modem, de Docker-client van
umbreld zelf, dus rechtstreeks op de Docker Engine API. Compose komt er niet aan
te pas en de compose wordt alleen gelezen om te zien welke images erin staan.
pull_policy is een sleutel van de Compose-specificatie en wordt dus nooit
bekeken. Mijn reparatie van de vorige commit kon per definitie niet werken; hij
is eruit, want een sleutel die niets doet met een commentaar dat beweert van wel
is erger dan geen sleutel.
Waar die fout vandaan kwam: ik las in app-script dat install een
`compose "${app}" pull` doet en nam aan dat dat het pad was. Dat bestand is de
legacy-compat-laag en niet wat umbrelOS 1.x loopt bij een installatie vanuit de
interface. Dat staat nu als waarschuwing in de naslag, want het is precies het
soort bron dat overtuigend leest en het verkeerde antwoord geeft.
De echte regel, nu op het apparaat vastgesteld in plaats van uit code afgeleid:
elke image in de compose van een app moet anoniem uit een register te halen zijn.
Een lokaal gebouwde tag werkt niet, hoe goed docker compose up er ook mee overweg
zou kunnen.
Het image-veld staat er nog en wijst nog steeds naar de lokale tag. Dat is
bewust: het commentaar erboven zegt nu dat het zo niet werkt en wat er moet
komen. Weghalen zou de app-map stiller maar niet beter maken, en de keuze voor
een register is aan de gebruiker.
Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
HarmenandClaude Opus 5
|
8004acfae9 |
pull_policy: never, anders faalt de installatie op een image die nergens staat
De image is gebouwd op de Umbrel en staat alleen in de lokale Docker-opslag: er
is geen register. Dat leek te werken omdat `docker compose up` niets ophaalt zolang
de image lokaal bestaat. Bij het nakijken van app-script in umbreld bleek dat niet
het pad dat een installatie loopt.
umbreld draait `compose "${app}" pull` bij install, bij update en bij
post-patch-update. Die zou whatsnext/evolu-relay:c03a204 op Docker Hub zoeken,
waar hij niet bestaat, en dan faalt de installatie voordat er iets gestart is. Met
pull_policy: never slaat compose die twee services over bij het ophalen. Postgres
houdt de standaard, want die komt wél uit een register.
Bijkomend voordeel dat het houdt zodra er ooit een register is: ontbreekt de image,
dan is de fout "niet gevonden" en die wijst naar de overgeslagen bouwstap, in plaats
van een mislukte netwerkpoging die naar het register wijst.
Uit hetzelfde bestand meegenomen naar de naslag: starten gaat met
`up --detach --build`, dus umbreld zou een build:-blok wél uitvoeren. Toch blijft
bouwen-in-de-app een slecht idee, en nu met een tweede reden naast de whitelist: de
installatie hangt dan tijdens het bouwen. Op deze machine duurde dat 50 seconden.
Geen versieverhoging: deze app is nog nooit geïnstalleerd, dus er is geen manifest
op een apparaat om tegen te vergelijken.
Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
HarmenandClaude Opus 5
|
b2e9c8fc7a |
Evolu Relay als tweede app in de store, plus het bouwrecept
De gebruiker koos ervoor het pakket meteen te maken en een installatie te proberen, met de image lokaal gebouwd en het recept in de repo. Dit is dat pakket. Er is nog niets gebouwd en niets geinstalleerd; "gebouwd" is hier nadrukkelijk niet "werkend". De zwaarste ontwerpvraag is met een precedent beslecht en niet met een gok. Trezor Suite is geen browser met een sessiecookie en kan dus niet achter de inlog van umbrelOS; het was onduidelijk of PROXY_AUTH_ADD "false" dan verantwoord is of een omweg. De eigen nostr-relay-app van Umbrel doet exact hetzelfde, om precies dezelfde reden, en heeft ook geen eigen ports:. De prijs staat in de compose en in het plan: wie die poort bereikt, bereikt de relay. Wat de schade beperkt is dat de relay elke eigenaar zonder limietenrij weigert. Daarom gaat de quota-manager mee, en dat is geen restje van Trezor's betaalde hosting: hij is wat die rijen aanmaakt. Relay en quota-manager komen uit dezelfde image met een ander command, want bovenstrooms is het een codebase met meerdere startscripts. Het command staat expliciet en leunt niet op de CMD van de Dockerfile, waar yarn start staat met bovenstrooms zelf een twijfel erbij. Het bouwrecept staat in tools/ en niet in de app-map. Dat is geen netheid: een Dockerfile staat niet in de update-whitelist, dus bouwen-in-de-app zou elke nieuwe versie een deinstallatie plus herinstallatie kosten. Onder tools/ en niet onder build/, want dat laatste staat in .gitignore als bouwselmap en het recept zou stilzwijgend buiten de repo zijn gebleven. Dat kwam pas bij git status aan het licht. De poort is 3851 en niet 4000. 4000 is de eigen poort van de relay maar ook een veelgebruikte poort, en een botsing op de host merk je pas als de app niet start. Die les komt van 50002 tegen Fulcrum. Nieuw testbestand test_appstore_vorm.py, en het gaat over de store en niet over een app: id gelijk aan mapnaam, store-voorvoegsel, veldvolgorde, app_proxy die naar een bestaande service wijst, en elke gemounte map die in de repo bestaat. Het vindt zijn apps zelf, dus een derde app valt er automatisch onder. Digests toetst het expres niet: geen van de twee apps haalt die regel vandaag en een suite die altijd rood staat wordt niet gelezen. Mutatie-getest met drie ingrepen: het app-id laten afwijken van de mapnaam, APP_HOST naar een niet-bestaande service laten wijzen, en de .gitkeep weghalen. Alle drie vielen om bij de juiste toets, en git diff was daarna leeg. Umbrelapp is gepromoveerd naar Actief als 008, tussen Proefopstelling en Appstore, en het masterplan is naar het archief. Wat er in de plannen als open blijft staan is niet klein: of Trezor Suite dit adres accepteert, of het databaseschema zichzelf aanmaakt, en hoe je een eigenaar registreert. Tests: 32 goed 0 fout, 39 goed 0 fout en 54 goed 0 fout, niets overgeslagen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |