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
- 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
- bij de installatie wordt gevraagd onder welk account Server Up draait: een
nieuw systeemaccount 'serverup', het account waarmee je werkt, een bestaand
account, of root zoals voorheen (--user NAAM slaat de vraag over)
- nieuw docker-entrypoint.sh: start als root, zet /data, stacks en backups
klaar, en zakt met setpriv af naar SU_UID:SU_GID met de capabilities die
nodig blijven (chown, dac_override, fowner - alle drie al in Docker's
standaardset)
- appdata blijft daarbij bewust ongemoeid; die mappen zijn van de apps zelf
- de gid van de docker-socket wordt uit de socket zelf gelezen, zodat het
account niet in de docker-groep hoeft (dat zou root op de host geven)
- installatieformulier vult PUID/PGID met de ids waaronder Server Up draait in
plaats van de 1000 die 44 sjablonen blind noemen
- een onleesbaar bestand laat de rest van de backup niet meer sneuvelen; wat
ontbreekt komt in het log en in de metadata (skipped)
- terugzetten herstelt het eigenaarschap van appdata, dat tarfile met
filter="data" laat vallen
- CI controleert in een echte container dat setpriv bestaat, dat er wordt
afgezakt, dat de socket-gid meekomt, dat /data schrijfbaar is en dat SU_UID=0
root laat blijven
- SU_UID=0 in .env is de ontsnappingsklep naar het oude gedrag
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
Het installatiescript kan nu allebei zelf regelen, zodat je na afloop niet
meer naar de webinterface hoeft om een account te claimen en niet meer in
.env hoeft te duiken om erbij te kunnen.
Beheerdersaccount:
- Op een terminal wordt gevraagd of je er meteen een wil, met naam en
wachtwoord (twee keer, echo uit).
- Automatisch via --admin NAAM plus --admin-password-file of
SU_ADMIN_PASSWORD; zonder bron en zonder terminal maakt het script er
zelf een van 24 tekens en toont die.
- --admin-password weigert bewust: argumenten zijn zichtbaar in 'ps'. Het
wachtwoord gaat via stdin naar curl, niet als argument.
- Nieuw --create-admin voor een installatie die al draait.
Bereikbaarheid:
- Keuzemenu voor BIND (deze server / hele netwerk / eigen adres), met het
gedetecteerde serveradres erbij.
- Bij opnieuw installeren is de bestaande instelling het uitgangspunt, zodat
enter je server niet ongemerkt terugzet op loopback.
Opgeloste fouten:
- Een bestaande .env bleef altijd ongemoeid, ook met --bind: de installatie
leek te lukken terwijl de server op het oude adres bleef luisteren.
- --update rekende met de standaardpoort in plaats van met wat er in .env
staat, waardoor de wachtlus en het slotadres niet klopten.
- --dry-run riep 'sudo docker' aan en vroeg dus om een wachtwoord terwijl
het net beloofd had niets te doen; zonder terminal liep het daarop vast.
- Ongeldig bind-adres en poort buiten 1-65535 worden nu meteen geweigerd.
Getest met een pseudo-terminal voor de vragen en tegen een echt draaiende
server voor het aanmaken van het account, inclusief een wachtwoord vol
aanhalingstekens en backslashes, een geweigerd tweede account en een server
die niet reageert. De e2e-tests slaan zichzelf over waar curl ontbreekt,
zoals in het CI-image. 992 tests groen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C7oLCRYzY5ixJ5Sv8Y8EFb
De teststap draait in python:3.12-slim, waar curl ontbreekt. Het
installatiescript brak daar af op de vereistencontrole, waardoor
test_dry_run_wijzigt_niets en test_dry_run_toont_de_hele_gang_van_zaken
faalden op de runner (runs 74 en 75).
Ontbrekende curl/tar is nu een waarschuwing bij --dry-run in plaats van
een harde fout, net als bij Docker: een proefdraai hoort juist te tonen
wat er zou gebeuren op een machine waar nog niets staat.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C7oLCRYzY5ixJ5Sv8Y8EFb
curl -fsSL https://git.ramonbesselink.nl/bes-r/server-up/raw/branch/main/install.sh | sh
install.sh controleert het systeem, biedt aan Docker te installeren als dat
ontbreekt, kloont de repo (of pakt het tar-archief uit als git ontbreekt), maakt
.env aan, bouwt en start, wacht op /healthz en toont waar je terecht kunt met de
waarschuwing meteen een account aan te maken.
- Opties: --dir, --port, --bind, --branch, --token, --update, --uninstall,
--yes, --dry-run.
- --update haalt nieuwe code op en herstart; .env, stacks en gegevens blijven.
- --uninstall stopt de container maar laat gegevens staan, en vertelt hoe je
die alsnog opruimt.
- Gebruikt alleen sudo waar nodig: kun je zelf in de doelmap schrijven en
docker aanroepen, dan blijft alles onder je eigen account.
Tijdens het testen gevonden en verholpen:
- `docker compose --project-directory` zoekt zonder -f het compose-bestand in de
huidige map; bij `curl | sh` is dat je thuismap. Nu altijd -f erbij.
- De wachtlus gaf anderhalve minuut geen teken van leven; nu een punt per
poging en 90 in plaats van 120 seconden.
- Bij --dry-run braken ontbrekende Docker-onderdelen de voorvertoning af; nu
waarschuwingen zodat je de hele gang van zaken ziet.
- De versie-uitlezing uit /healthz tolereert nu ook json met spaties.
Documentatie: docs/installeren.md met alle opties, bijwerken, verwijderen en een
probleemoplostabel; README verwijst ernaar.
Tests: syntaxis onder sh/dash/bash, geen bashismen, --help noemt alle opties,
ongeldige invoer stopt, een proefdraai maakt niets aan, en de installatieregel
in README en docs is identiek.
958 tests groen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C7oLCRYzY5ixJ5Sv8Y8EFb
