Commit graph

5 commits

Author SHA1 Message Date
Ramon
e61f90745b v0.8.05-beta - een onbereikbaar pad liet zich gewoon opslaan
Some checks failed
Deploy server-up (dev) / deploy (push) Has been cancelled
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
2026-08-03 22:22:29 +02:00
Ramon
fc2e80fbda v0.10.00-beta - Server Up draait niet meer als root
Some checks failed
Deploy server-up (dev) / deploy (push) Failing after 2m8s
- 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
2026-08-02 22:02:36 +02:00
Ramon
f4b652e182 Eigenaar meenemen bij het verhuizen
All checks were successful
Deploy server-up (dev) / deploy (push) Successful in 15m32s
`shutil.copy2` neemt de rechten mee maar niet de eigenaar, en Server Up draait
als root. Verhuisde appdata werd daardoor root:root, waarna een container die
als PUID 1000 draait er niet meer in kon.

- elk bestand, elke map, elke symlink én de hoofdmap krijgen de uid/gid van het
  origineel
- lukt chownen niet (je draait niet als root), dan gaat de verhuizing door met
  een waarschuwing in plaats van te struikelen
- tests voor beide gevallen, en voor het feit dat de uid van de bron komt

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
2026-08-02 14:49:18 +02:00
Ramon
1530df277d Padcontrole toetsen zonder op de omgeving te leunen
All checks were successful
Deploy server-up (dev) / deploy (push) Successful in 17m42s
De CI draait zelf in een container, dus `bereikbaar()` viel daar al bij
`buiten_mount` uit voordat de schrijftest werd bereikt — de test slaagde alleen
op een machine zonder /.dockerenv.

- `_in_container()` afgesplitst, zodat de tests kiezen welke tak ze toetsen
- de schrijftest zet dat expliciet uit
- twee tests erbij voor de mountcontrole zelf, inclusief dat een gekoppelde
  /opt/serverup de map /opt/serverup-oud niet bereikbaar maakt

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
2026-08-02 14:12:37 +02:00
Ramon
90e4160727 v0.9.00-beta - één hoofdmap, paden kloppend en data verhuizen
Some checks failed
Deploy server-up (dev) / deploy (push) Failing after 2m40s
- LIBRARY_DIR, DATA_DIR en BACKUP_DIR worden afgeleid van BASE_DIR in plaats
  van hard op /opt/serverup te staan
- docker-compose geeft BASE_DIR nu ook aan de container door; die stond alleen
  in de mount, dus de app bleef /opt/serverup voorstellen bij een /srv-mount
- het installatieformulier vult appdata_dir met de ingestelde DATA_DIR, zodat
  alle 286 sjablonen de juiste map voorstellen
- Instellingen → Paden heeft een hoofdmap met afgeleide submappen, een
  kopieerknop per pad en "Alles overnemen"
- nieuw GET /api/paths/check: is het pad schrijfbaar en binnen de gemounte
  BASE_DIR, met de .env-regel als dat niet zo is
- nieuw POST /api/paths/move: stacks stoppen, kopiëren, controleren, paden in
  compose/.env/metadata omschrijven, stacks starten en pas dán het oude
  opruimen
- jobs.voortgang() plus een voortgangsbalk boven het terminallog
- core/paden.py met meten, bereikbaarheid, verhuizen en omschrijven
- docs/installeren.md en .env.example beschrijven BASE_DIR als de manier om
  alles te verplaatsen

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9eqpADJSRs49SoGGr4NAy
2026-08-02 14:06:17 +02:00