8004acfae98976379d6687a9f2ea55476b2d041b
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 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> |
||
|
HarmenandClaude Opus 5
|
1a87a45685 |
De bovenstroomse repo gelezen, en twee aannames sneuvelden
De gebruiker wil de Evolu Relay-app meteen pakketteren. Daarvoor moest fase 1 van Proefopstelling eerst af, want een compose schrijven op aannames is precies wat dat plan moet voorkomen. Upstream-evolu-relay.md gaat daarmee van vooronderzoek naar nagetrokken, met een bron-URL per feit. De quota-manager is in de praktijk verplicht, en om een andere reden dan gedacht. Niet omdat de relay hem aanroept: er is geen HTTP-koppeling en geen URL in de configuratie, ze delen alleen de Postgres. Maar isOwnerAllowed() eist een rij in de limietentabel en de quota-manager maakt die rijen. Zonder hem is de relay dus niet open maar dicht voor iedereen. Dat maakt de tweede weg interessant, want een rij is ook met de hand te zetten; de prijs daarvan is schrijven in andermans schema. Er is geen publieke image. Trezor bouwt er wel een maar duwt hem naar een eigen Amazon ECR, en op Docker Hub staat niets. Zelf bouwen en publiceren, of geen app, en dat is een doorlopende verplichting. Bijvangst die een risico wegneemt: datzelfde werkproces bouwt amd64 en arm64, dus de Dockerfile is bovenstrooms bewezen op een Pi. Nieuw risico dat ervoor terugkomt: LICENSE.md is door GitHub geclassificeerd als "other", en zodra je een image publiceert distribueer je hun software. Twee kleinere correcties. De compose van Trezor draait de relay niet, er staan alleen Postgres en Prometheus in; het is een ontwikkelopstelling en wat zij uitrollen staat in .k8s/. En alle processen komen uit één image met per service een ander command, dus het worden geen drie images. Eén tegenspraak blijft staan en is expres niet weggeschreven als feit: .env.sample zegt dat SERVER_ENV=prod authenticatie aanzet, maar in de code die ik las bepaalt die vlag alleen het logniveau en staan de controles onvoorwaardelijk aan. Eén van de twee is achterhaald. Dat is met één keer starten te meten en het staat als taak in fase 2. Tests: niet gedraaid, dit raakt alleen documentatie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
5cf23bb83d |
De stunnel-container is weg, en daarmee stap 1 van open punt 2
De handmatige installatie uit de tijd vóór dit plan bond poort 50002 en stond op restart: unless-stopped, dus hij overleefde een herstart. Dat was de laatste blokkade voor de Fulcrum-test die op te heffen was; wat er nu nog tussen zit is de eerste sync van Fulcrum, en dat is wachten en geen werk. De map ~/umbrel/home/Containers/ElectrumTLS blijft bewust staan tot de herstart-controle gedaan is; dat is de gedocumenteerde weg terug. De volgorde-waarschuwing die er bij die taak stond is eruit: de container mountte zijn entrypoint.sh uit die map, en die container is er nu af. Nagekeken en niet aangepast: de repo ElectrumTLS staat nog op de Git-server en is nog steeds anoniem leesbaar op b6afe67. Het domein staat daar dus nog in de historie, en die taak blijft open. Tests: niet gedraaid, dit raakt alleen documentatie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
f736787c39 |
Een store-URL wisselen is een herinstallatie, geen update
Open punt 8 stond sinds 19-08 als "niet uitgezocht, en niet aannemen dat het meevalt". Beantwoord, en het antwoord is nee: een geïnstalleerde app overleeft een wisseling van store-URL niet. Wat het verraderlijk maakt is de vorm waarin het misging. umbrelOS tóónde de update naar 0.0.15 gewoon, en voerde hem daarna niet uit, zonder foutmelding. "De update wordt gezien" leest als "de koppeling ligt er" en dat is precies wat het niet betekent: tonen en ophalen gaan niet langs dezelfde weg, en de herkomst van een geïnstalleerde app blijft de store waaruit hij kwam. Een gelijk app-id in een andere store maakt daar geen dezelfde app van. Deïnstalleren plus opnieuw installeren loste het op en de app draait weer. De prijs is app-data, dus de certificaatkeuze moest opnieuw gemaakt worden; wie een certificaat had geüpload in plaats van uit Zoraxy te kiezen, moet data/certs/ vooraf wegkopiëren. Dat staat er nu bij, want dit komt bij het masterplan Publicatie-Gate nog een keer langs: daar verandert het app-id. Gratis meegenomen bewijs: de app komt nog steeds omhoog op een installatie waar nooit een certificaat gekozen is. Dat was de fout die 0.0.3 velde. Verder de Fulcrum-omschakeltest voorzien van de reden dat hij stilligt: de eerste sync van Fulcrum stond op 72%. Omschakelen naar een backend die nog niet klaar is meet de sync en niet de app. Daarmee wacht alles wat in dit plan nog openstaat op iets dat vanzelf komt of ligt het bij de gebruiker; dat staat nu in de header, zodat een volgende sessie niet gaat zoeken naar werk dat er niet is. Tests: niet gedraaid, dit raakt alleen documentatie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
67ed9b603b |
Eén app store, twee apps
umbrelOS leest per store één repo, dus twee apps in twee repo's kan niet. Deze repo is de store en bevat vanaf nu Electrum Gate en het werk aan Evolu Relay. Opgezet als verse repo op verzoek van de gebruiker: de historie van ElectrumTLS en van EvoluRelay komt niet mee. Dat heeft één gevolg dat verder gaat dan opruimen. In de historie van ElectrumTLS staat het domein van de gebruiker en het certificaatpad, van vóór de opschoning van 19-08. Die komt hier niet in. Zolang die repo op de Git-server blijft staan verandert dat niets, dus het weghalen ervan is het laatste stuk van open punt 3 van het plan Appstore, en geen bijzaak. De store zelf hoefde niet te veranderen: store-id whatsnext, en dus blijft het app-id whatsnext-electrum-gate. Dat hangt aan het store-id en niet aan de URL, dus voor umbrelOS is dit dezelfde app in een andere store. Dat de store op 19-08 naar de maker genoemd werd in plaats van naar deze ene app, betaalt zich hier uit. Wat de documentatie betreft is dit één wortel voor beide apps, en dat was de reden om samen te voegen en niet de prijs ervan: de appstore-spec, het pinnen van images en de werkwijze golden al voor allebei en stonden in twee repo's naast elkaar. De kruisverwijzing die daarvoor nodig was (Referenties/Umbrel-appstore.md in de oude EvoluRelay-repo) is verdwenen; wat daarin stond over de plekken waar de relay een ander geval is, staat nu als ontwerp in het masterplan Umbrelapp §4. Botsende namen kregen een achtervoegsel met de app, en alleen die: Publicatie werd Publicatie-Gate en Publicatie-Relay, CHANGELOG.md werd CHANGELOG-electrum-gate.md. Proefopstelling kreeg 007, tussen de twee bestaande nummers, zodat de bovenkant van de reeks op tier-orde blijft staan. CONTINUE_HERE.md heeft een kolom App, maar de tiers lopen over beide apps heen: er is één volgorde van werken. Electrum Gate gaat naar 0.0.15, want website, repo, support, submission en icon wijzen nu naar UmbrelApps en zonder versieverhoging rolt dat niet uit. De release notes leggen aan de gebruiker uit dat hij de store opnieuw moet toevoegen. Of een geïnstalleerde app een wisseling van store-URL overleeft is nog steeds niet uitgezocht; dat blijkt bij het omzetten. Twee dingen in de plannen van Electrum Gate waren door deze verhuizing niet meer waar en zijn bijgewerkt: de taak "de repo hernoemen" in fase 7 is afgevinkt, en de repo-vorm in PLAN.md §4a toonde nog de store-id electrumtls, die al sinds fase 7 achterhaald was. Tests: 39 goed 0 fout en 54 goed 0 fout, niets overgeslagen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |