UniFi's reparatiecontainer mount de stackmap in plaats van het losse script,
zodat Docker er geen lege map van kan maken en exit 126 niet meer voorkomt.
Bevat ook de snellere image-build.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
ARG SU_VERSION stond bovenaan met een LABEL erachter. Die waarde verandert
per release, dus alle lagen erna vervielen: apt-get, de Docker-CLI van 70 MB
en de front-end-bestanden. Versie en label staan nu onderaan, en de assets
vóór de broncode zodat ze niet bij elke commit opnieuw van het CDN komen.
Ook: een mislukte pull noemt nu de waarschijnlijke oorzaak (geen gepusht
image) in plaats van alleen naar toegangsrechten te wijzen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
Je ziet nu waarom een app niet start: de logs en healthcheck-uitvoer van de
containers die niet opkwamen belanden in hetzelfde joblog, het wijzigscherm
meldt een bijgewerkt sjabloon, en de lege map die Docker achterlaat waar een
bestand hoort wordt opgeruimd in plaats van het probleem in stand te houden.
Bevat ook de vier nieuwe verbindingsapps en de soepelere updater-adressen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
De catalogus had niets om een machine elders bij je eigen netwerk te laten
komen, en niets om Proton Mail bruikbaar te maken voor apps die geen Proton
spreken.
- wireguard: client (eigen wg0.conf in wg_confs) of server, met NET_ADMIN,
SYS_MODULE, de kernelmodules van de host en src_valid_mark.
- tailscale: network_mode host zodat de tunnel voor de hele machine geldt,
met bewaarde staat en optionele subnetroutes.
- cloudflared: publiceert zelf geen poorten en werkt zichzelf niet bij.
- protonmail-bridge: SMTP op 1026 zodat hij naast Mailpit past; het sjabloon
legt de eenmalige aanmelding via de CLI uit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
Het adres uit de adresbalk van Forgejo of GitHub geeft HTML terug, en de
enige melding was een JSONDecodeError. Dat adres wordt nu omgerekend naar
/api/v1/repos/...; komt er toch HTML, dan zegt de melding wat er mis is.
Een https://-schema voor het imageveld wordt weggehaald, want een
image-adres heeft er nooit een.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
UniFi start weer op een Raspberry Pi 4: MongoDB standaard op 4.4.18, de
laatste versie zonder ARMv8.2-A-eis, met een instelbare versie en een
healthcheck die trage hardware de tijd geeft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
Het sjabloon pinde 4.4.29, maar vanaf 4.4.19 eist MongoDB ARMv8.2-A. Op een
Pi 4 (ARMv8.0-A) stopt mongod met 'Illegal instruction', wordt de container
nooit healthy en start UniFi niet.
- Standaard mongo:4.4.18, instelbaar via een geavanceerd veld.
- De reparatiecontainer draait dezelfde versie.
- Healthcheck ruimer: timeout 20s, start_period 90s, tien pogingen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
De dev-branch hoort een beta te tonen; na de release van v0.8.28 stond hij
gelijk aan main. De changelogkop is een lege sectie die bij de volgende
uitgave de releaseversie wordt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
install.sh krijgt --host, zodat een server die de ingebouwde hostnaam niet
kan oplossen toch bij de broncode kan. Bij een bestaande installatie wordt de
git-remote meteen omgezet, anders had de optie daar geen effect.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
Eerste stabiele uitgave sinds v0.8.12: de UniFi-storing verholpen, koppelen
laat databases met rust, eigen mappen en apparaten per app, herkomst van
sjablonen zichtbaar, en de vier verbeteringen rond wachtwoorden, wachtrijen,
snelheid en versietags.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
Vier verbeteringen die elk pas opvielen als je ze nodig had.
- Een gewijzigd databasewachtwoord wordt vóór de herstart omgezet in de nog
draaiende database (ALTER USER / updateUser). Lukt dat niet, dan breekt de
wijziging af en gaat de backup terug — 64 sjablonen hebben zo'n veld, en
POSTGRES_PASSWORD werkt alleen bij een lege datamap. Wachtwoorden gaan via
de omgeving en via stdin, niet via argumenten.
- jobs.met_slot serialiseert taken per app; de geplande backup slaat een
bezette app over in plaats van een half herschreven map in te pakken. Een
taak die klapt laat het slot los en wordt als mislukt afgesloten.
- api_stacks en api_connectable gebruiken één docker ps met het projectlabel
in plaats van een compose ps per stackmap.
- Per service een versietag te kiezen, bewaard in .serverup.json en opnieuw
toegepast na het renderen; het containerpaneel toont het draaiende image.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
Een mediamap koppelen of een USB-stick doorgeven kon alleen door het
compose-bestand met de hand te bewerken, en dat werd bij de eerstvolgende
'Instellingen wijzigen' overschreven.
- Nieuwe stap 'Extra's' in het invulmenu: per onderdeel een map van de host
(optioneel alleen lezen) of een apparaat.
- De keuzes staan in .serverup.json en worden ná het renderen toegepast, dus
ze overleven elke wijziging.
- /api/devices vindt seriële poorten (/dev/serial/by-id, ttyUSB*, ttyACM*) en
videokaarten, met een 'vast'-label voor by-id-paden.
- Het hostpad wordt vooraf gecontroleerd via /api/paths/check.
- Docker-socket, /etc, /proc, /sys en /boot worden geweigerd met uitleg, in
compose_transform en nog eens in de API.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
Sjablonen komen uit de git-cache van een app-repo. Loopt die achter, dan trekt
'Instellingen wijzigen' een oude versie over een werkende app heen zonder dat
iets dat zegt — precies wat er bij UniFi gebeurde.
- git.cache_status geeft commit, datum, synchronisatiemoment en de VERSION uit
de cache terug.
- /api/repos en /api/stacks/<naam>/config sturen die stand mee, met een
outdated-vlag als de repo-VERSION ouder is dan de draaiende versie.
- Het wijzigscherm toont repo, branch en hoe lang geleden er opgehaald is, en
waarschuwt bij een achterlopende cache.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
add_shared_network hing elke service van een stack aan het gedeelde netwerk.
Eén druk op 'koppelen' maakte daarmee de database van die app bereikbaar voor
elke andere gekoppelde app — en niet elk sjabloon zet daar een wachtwoord op.
- Standaard gaan alleen services mee die geen database, cache of zoekindex
zijn; brokers als mosquitto en rabbitmq blijven wel deelbaar.
- Per onderdeel te kiezen in de stap 'Verbinden'; de keuze staat in
.serverup.json en geldt ook bij een volgende wijziging.
- mongodump/mongorestore sturen geen inloggegevens meer mee bij een database
zonder authenticatie; die dump mislukte altijd.
- Joblogs worden bewaard in SU_JOBS (standaard /data/jobs) en teruggelezen na
een herstart; een afgekapte taak meldt dat in plaats van 'unknown'.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
Sjablonen komen uit de git-cache van een app-repo, niet uit het image. Welke
branch die volgt was nergens te zien en alleen te wijzigen door de repo te
verwijderen en opnieuw toe te voegen — waarbij de id een volgnummer krijgt en
het bronsjabloon van bestaande apps onvindbaar wordt.
- PUT /api/repos/<id> past naam, branch, submap en optioneel de URL aan; de id
blijft staan zodat .serverup.json van bestaande stacks blijft kloppen.
- Een leeg tokenveld laat het bestaande token staan.
- De repolijst toont de branch en heeft een bewerkknop; na opslaan wordt de
repo meteen opnieuw opgehaald.
- Nieuwe auditactie 'edit' vertaald in nl en en.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
Het linuxserver-image schrijft /config/data/system.properties alleen bij de
allereerste start. De authSource en het wachtwoord die daarna in Compose
veranderden kwamen er nooit in, dus UniFi bleef verbinden met de gegevens van
de eerste installatie — MongoDB antwoordde met UserNotFound: unifi@unifi.
- De reparatiecontainer zet db.mongo.uri, statdb.mongo.uri, db.mongo.local en
unifi.db.name opnieuw uit de actuele omgeving; overige instellingen blijven.
- Gebruikersnaam en wachtwoord worden url-gecodeerd in de URI gezet.
- Het bestand wordt op zijn plaats overschreven, dus eigenaar en rechten
blijven van UniFi zelf.
- Het wachtwoord uit system.properties telt mee als inlogpoging, zodat een
afgeweken .env de stack niet onherstelbaar maakt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
Het audit-logboek las request.remote_addr uit in de achtergrondthread van de
job. De RuntimeError die daarop volgde belandde in de foutafhandeling, die de
zojuist gemaakte backup terugzette — inclusief het oude compose-bestand.
- Adres vóór de threadstart vastleggen bij herconfigureren, koppelen, backup
maken en terugrollen.
- UniFi: init-script probeert de beheerders 'unifi' en 'root' en herkent een
server zonder authenticatie, zodat ook een oud Mongo-volume gerepareerd
wordt; bestaande rollen blijven staan en 'backup'/'restore' worden aangevuld.
- UniFi: healthcheck van Mongo zonder inloggegevens, anders bleef de container
ongezond en startte de reparatiecontainer nooit.
- Backups: mongodump/mongorestore gebruiken de beheerder uit compose in plaats
van de verzonnen gebruiker 'app'.
- Appkaart: knop die de webinterface opent, met het adres uit /api/stacks.
- Joblog: geen dubbele regels meer doordat polls elkaar konden overlappen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H9Vcwu7owJZ3nj5dCf4VFT
Gemeten: 709 seconden voor 318 images, terwijl de netwerktijd zo'n 48 seconden
is. Twee oorzaken.
- het aantal tegelijk gold in totaal in plaats van per registry. Registries
knijpen per host af en tweederde staat op Docker Hub, dus ghcr, lscr en quay
stonden daarachter te wachten zonder dat dat iets oploste. Nu vier per
registry, registries naast elkaar
- elke ronde controleerde alles opnieuw. Geslaagde controles blijven een week
staan, met spreiding per image zodat niet alles op dezelfde dag verloopt. De
sleutel is de naam met tag, dus een gewijzigde tag wordt altijd
gecontroleerd; mislukkingen komen nooit in de cache
Gemeten na de wijziging: koude cache 43s, warme cache 0s.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
- overnemen: een compose-app die buiten Server Up om draait, met een knop
erbij trekken. Er wordt niets verplaatst of gekopieerd; de stackmap wordt een
verwijzing naar de map die de gebruiker al heeft. Kopieren zou de relatieve
paden in zijn compose-bestand breken
- kan Server Up niet bij die map (hij ziet alleen wat via BASE_DIR gekoppeld
is), dan zegt hij dat met waar de map moet staan
- verwijderen van een container die niet bij een app hoort, met in de vraag dat
alleen de container weggaat en niet zijn gegevens of image
- hoort hij bij een compose-project, dan staat erbij dat hij terugkomt zodra
dat project ergens anders start en dat overnemen waarschijnlijk is wat je
zoekt. Daarom staat overnemen links van verwijderen
- een overgenomen app verwijderen haalt alleen de verwijzing weg; rmtree zou
daar bovendien op weigeren en halverwege stranden
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
DELETE /api/repos/<id> las r["id"] zonder controle, dus een regel zonder id gaf
een 500 - dezelfde fout die GET /api/repos had. Verwijderen haalt alle regels
met die id weg, zodat een dubbele vermelding in een klik weg is.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
Met twee repo's die dezelfde id dragen tekende de store geen kaarten terwijl de
knop "Nog N tonen" een dalend getal liet zien: klikken verlaagde het getal met
zestig en er verscheen niets.
De repolijst wordt getekend met :key="repo.id". Dubbele keys zijn voor Alpine
ongedefinieerd gedrag, dus ontbrekende of verkeerde blokken, terwijl de tellers
gewoon doorrekenen over de gegevens.
GET /api/repos geeft een id nu nog maar een keer terug.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
De appslijst bleef leeg na het rechtzetten van de paden, terwijl de API de apps
gewoon leverde: de pagina haalde ze nooit opnieuw op. goto() wisselt alleen van
pagina en saveSettings() verversde niets, dus je keek naar de lijst van bij het
laden van de pagina.
- bij een padwijziging worden de appslijst en de containers opnieuw opgehaald
- saveSettings() gooide het antwoord van de server weg en meldde altijd
"opgeslagen", ook als de server de opslag weigerde. Sinds v0.8.05 een pad
buiten de koppeling weigert was dat het verschil tussen aangepast en niets
gebeurd; de melding komt nu in beeld
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
De rondgang doorliep alle vijf de stappen goed en de CI-stap viel er daarna
alsnog op om, zonder melding: tussen "Rondgang geslaagd" en het einde zaten
tweeenhalve seconde en verder niets. Dat is het opruimblok.
- opruimen kan de uitslag niet meer bepalen; mislukt het, dan staat dat er
- het script eindigt expliciet met exitcode 0
- de CI drukt de exitcode van de stap af, want zonder dat getal was niet te
achterhalen waar een rode job vandaan kwam terwijl het scherm groen was
De postgres-race uit v0.8.06 is bevestigd opgelost: de rondgang liep in een
keer door.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
Vier runs op rij faalden op "psql: connection to server on socket ... No such
file or directory". Het officiele postgres-image start bij een eerste run eerst
een tijdelijke server om de init-scripts te draaien, stopt die, en start dan
pas de echte. pg_isready meldt tijdens die tijdelijke server al "klaar", dus
kwam de volgende opdracht net in het gat daarna, dan was de socket weg.
- de wachtlus voert nu echte query's uit en gaat pas door na twee geslaagde
achter elkaar; bij een time-out staat de laatste fout erbij
- een achtergebleven testcontainer wordt voor de start opgeruimd, want een
geannuleerde run draait zijn opruimblok niet
De deploy zelf werkte al die tijd; deze stap draait erna.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
Oorzaak van de lege appslijst: LIBRARY_DIR stond op /srv/serverup/stacks
terwijl alleen /opt/serverup gekoppeld is. Dat pad bestaat binnen de container
niet, dus geen apps in de lijst en alle containers onder "handmatig gestart" —
want beheerd leest dezelfde map. Nergens stond waarom.
paden.bereikbaar() bestond al sinds v0.7.92 maar hing alleen aan het veld
Hoofdmap en aan het verhuizen. De drie padvelden schrijven rechtstreeks naar
PUT /api/settings, en daar stond geen wacht.
- PUT /api/settings weigert nu een pad waar Server Up niet bij kan, met de
regel voor .env erbij. Een ongewijzigd pad blokkeert niets, anders kun je met
een kapotte instelling niets meer wijzigen
- een lege appslijst zegt nu waarom in plaats van "Geen apps gevonden"
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
Drie keer op rij de verkeerde oorzaak aangewezen voor een lege appslijst, omdat
doctor niet genoeg vertelde om ertussen te kiezen: hij telde regels met ls.
Hij vraagt het nu aan de app zelf en toont het pad letterlijk (repr, dus met
een spatie of regeleinde zichtbaar), of de app die map vindt, en per map of hij
als app meetelt en zo niet waarom.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
api_stacks sloeg elke map zonder compose-bestand over met een kale continue.
Zo'n map dook daarna nergens meer op: niet in de lijst, en de containers die
erbij horen belandden onder "handmatig gestart" omdat beheerd op datzelfde
compose-bestand afgaat.
De interface heeft er wel een weergave voor - rode stip, streepje in plaats van
een status, geen knoppen - die door dat continue nooit te zien kon zijn.
Ze staan er nu tussen met die waarschuwing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
De koppeling van BASE_DIR kan intact zijn terwijl de container er toch niets
ziet. Docker bindt met propagation rprivate: een koppeling die op de host na
het aanmaken van de container ontstaat komt daar niet doorheen, en dan ziet de
container de lege map eronder.
- --doctor loopt met findmnt alle koppelingen onder BASE_DIR langs en
vergelijkt met de mountlijst van de container
- ontbreekt er een, dan staat erbij welke en hoe je hem meekoppelt
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
De app store toonde geen kaarten met daaronder een knop die 106 apps beloofde.
Het raster liep over de repolijst, de tellers over de opgehaalde apps: liepen
die uit elkaar, dan stond er een getal onder een leeg scherm zonder dat er
ergens een fout te zien was.
- storeResultaat en storeVerborgen tellen nu over dezelfde lijst die ook de
kaarten oplevert
- een lege store zegt wat er aan de hand is (geen repository, of geen apps die
aan het filter voldoen) in plaats van leeg te blijven
- GET /api/repos gaf een 500 op een repo zonder id, waardoor de repolijst in de
interface leeg werd en dus de hele store; zulke regels worden overgeslagen
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
"fatal: shallow file has changed since we read it" komt van twee git fetch in
dezelfde map. Bij het opstarten synchroniseert Server Up alles, en ondertussen
kan iemand op Synchroniseren drukken of een app installeren. Er zat geen slot
op, dus een synchronisatie kon over een andere heen lopen en de cache
halverwege achterlaten - waarna de repo zich niet meer liet bijwerken en de app
store leeg bleef.
- een slot per repo, zodat er nog maar een git tegelijk in een cache werkt
- lukt bijwerken niet, om welke reden dan ook, dan wordt de cache weggegooid en
opnieuw opgehaald. Er staat niets in dat bewaard hoeft te blijven, dus dat is
het juiste antwoord op elke fout hier. Dit repareert ook caches die al stuk
zijn
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
De koppelingscontrole in --doctor keek of het pad in /proc/self/mountinfo
voorkwam. Een bind mount wijst echter naar een inode, niet naar een pad: is de
map op de host vervangen nadat de container was aangemaakt, dan kijkt de
container naar de oude en meestal lege map terwijl het pad nog netjes in de
mountlijst staat.
- --doctor telt nu aan beide kanten en vergelijkt
- onderscheidt "map bestaat niet in de container" van "map is leeg"
- staat er buiten wel iets en binnen niet, dan is dat een fout met de weg
terug erbij (docker compose up -d --force-recreate)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
- "stack" heet in de interface voortaan "app": 24 teksten per taal plus de
terugvalteksten in de pagina. Je installeerde een app uit de App Store en
kreeg een stack; dat moest je maar net weten
- code, API-paden, mapnamen en .serverup.json houden `stack` — dat leest
niemand, en hernoemen zou opgeslagen gegevens en URL's breken
- de aparte sectie "Overige containers" is verdwenen. Handmatig gestarte
containers staan nu tussen de rest met het label "Handmatig gestart", met
starten, stoppen en logs. De zoekterm geldt voor allebei; een
categoriefilter laat ze vallen, want ze hebben geen categorie
- de waarschuwing bij backups zei nog dat appdata er niet in zit; sinds
v0.7.88 zit die er juist wel in, met een databasedump erbij
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
- `git pull --rebase --autostash` stopte met "Cannot rebase onto multiple
branches" zodra branch.<tak>.merge meer dan een waarde had; daarmee werkte
geen enkele repo meer bij en bleef ook de app store leeg, want die leest uit
dezelfde cache
- tweede fout in dezelfde regel: `git pull` zonder argumenten haalt de tak op
waarop ooit gekloond is, dus de branch uit de repo-instellingen werd
genegeerd. Van main naar dev omzetten deed stilzwijgend niets
- het bijwerken haalt nu de ingestelde tak op en zet de cache daar hard op:
ongevoelig voor de upstream-instellingen, volgt een gewijzigde branch, en
laat zich niet blokkeren door lokale wijzigingen
- --doctor vraagt Server Up zelf welke LIBRARY_DIR en DATA_DIR hij gebruikt,
hoeveel stacks hij daar ziet en hoeveel apps er in de store-cache zitten.
Dat verschil tussen "wat staat er op de host" en "waar kijkt de app" was
nergens zichtbaar
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
- tools/backup_rondgang.py draait backup en terugzetten tegen een echte
Docker-daemon in de CI: postgres-sidecar vullen, backuppen, alles weggooien,
terugzetten, en controleren dat de database daarna nog kan schrijven. Alle
bestaande backuptests vervangen Docker door een nep, dus die keten was nooit
bewezen
- daardoor gevonden: het terugzetten gaf de appdata de verkeerde eigenaar. Het
archief bevat de echte uid (postgres draait als 70 en zegt dat nergens in de
metadata); die gaat nu voor op PUID en op onze eigen uid
- een mislukte --update rolt terug naar de commit van ervoor en start die
opnieuw, in plaats van een stilstaande server en een rijtje commando's
- met een registry-image (SU_IMAGE) wordt er gepulld in plaats van gebouwd
- nieuw --reconfigure: bind, poort, account of hoofdmap wijzigen zonder de
broncode aan te raken
- nieuw --uninstall --purge: ook het volume, de gegevensmap en het account,
per onderdeel gevraagd. Zonder --purge somt --uninstall nu op wat blijft
- --dir wordt op een volledig pad gecontroleerd, het tijdelijke bestand voor
het beheerdersaccount is niet meer voorspelbaar, en er gaat nog een
rondgang naar de docker-daemon in plaats van twee
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
Ik sprong met tientallen (0.7.90 → 0.8.00 → … → 0.9.00 → 0.10.00) en liep
daarmee de reeks uit: dit schema rolt over bij .90, dus na 0.9.90 hoort 1.0.00
te komen. "0.10.00" bestond niet, en schond ook het formaat v0.0.00 uit de
projectafspraken.
De vijftien uitgaven van deze sessie zijn hernummerd naar 0.7.81 t/m 0.7.95,
aaneengesloten. In één doorloop met een tabel, want 0.8.81 wordt 0.7.90 en
0.7.90 wordt 0.7.81 — achtereenvolgende vervangingen zouden elkaar overschrijven.
Meegenomen: verwijzingen in de documentatie, .env.example, install.sh en de
tests. Verkorte vormen als "vanaf v0.10" zijn vervangen door het volledige
nummer, want die waren niet automatisch te herleiden.
De commit-onderwerpen in de geschiedenis dragen nog de oude nummers; VERSION en
CHANGELOG zijn leidend.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
Ik ging ervan uit dat de bereikbaarheidscontrole niet kon slagen omdat de
runner in een eigen container zit. De eerste run liet zien dat hij wél slaagt:
"Antwoordt op http://127.0.0.1:5000". De exitcode wordt nu meegenomen, dus een
echte fout in de deploy laat de CI vallen in plaats van alleen in het log te
belanden.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
- bijwerken vanuit de interface kon nooit werken: selfupdate schreef SU_TAG naar
<werkmap>/.env, maar die map is nergens in de container gemount. De
helper-container mount hem wel en zet de tag nu
- een vastgepinde versie kon niet bijgewerkt worden: `git reset --hard
origin/<tag>` bestaat niet. Resetten gaat nu naar FETCH_HEAD, wat voor takken
en tags allebei klopt
- de token stond in .git/config en in ps; hij gaat nu via een bestand met modus
0600 dat na afloop weer weg is (git via een credential-helper, curl via
--config). Schema en host komen uit bron_url, want git zoekt op exact die
combinatie
- nieuwe optie --base-dir PAD: de hoofdmap bij de installatie zetten in plaats
van achteraf in .env, waarna je de data alsnog moet verhuizen. Relatieve
paden en systeemmappen worden geweigerd
- nieuwe actie --doctor: een installatie doorlichten zonder iets te wijzigen —
container, bereikbaarheid op het ingestelde adres, het account versus SU_UID
in .env, of BASE_DIR echt gekoppeld is, de rechten van .env en de vrije
ruimte. Exitcode 1 bij fouten
- de CI draait --doctor na elke deploy tegen de echte installatie
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
De runner draait in python:3.12-slim, zonder curl. Daar faalde elke poging en
toetsten deze tests niet meer dan "curl ontbreekt". Ze krijgen nu een eigen
curl-schilletje op $PATH, zodat ze overal vastleggen wat ze horen vast te
leggen: welk adres het script opvraagt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
- vragen werden bij `curl | sh` niet gesteld en zelf met "ja" beantwoord:
vraag() keek naar stdin (de pipe) in plaats van naar /dev/tty. Docker werd
daardoor van get.docker.com gehaald zonder dat het gevraagd was en
--uninstall brak af zonder bevestiging. Eén terminal_beschikbaar() voor alle
vijf de plekken
- met --bind <eigen ip> mislukten de healthcheck en het aanmaken van het
beheerdersaccount, omdat het script altijd 127.0.0.1 vroeg terwijl compose op
$BIND publiceert; het controleadres volgt nu $BIND, met blokhaken om IPv6
- een mislukte update meldde "Bijgewerkt." met exitcode 0; hij stopt nu met een
foutmelding, en een verse installatie zegt in het slot eerlijk dat er niet
geantwoord is
- curl kreeg tijdslimieten bij het pollen, zodat het aantal pogingen weer iets
betekent; SU_WACHT_POGINGEN maakt het instelbaar
- het slot noemde nog "beheert Docker als root" en toont nu het account
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
`+chown,dac_override,fowner` kwam door elke stringtest heen maar werd door
setpriv geweigerd met "bad capability string", waarna de container niet meer
opstartte. Alleen de CI-stap in een echte container zag dit.
- CAPS is nu +chown,+dac_override,+fowner
- de test laat de echte setpriv over de string oordelen in plaats van hem te
vergelijken met een verwachte tekst; met de oude waarde faalt hij
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
