--from-env liest WERKBAUM_MASTER_PASSWORT aus der .env, --stdin die erste
Zeile von stdin. Beides ausdruecklich zu verlangen und nie stillschweigend:
Sonst setzte ein versehentlicher Aufruf ein Passwort, das in einer Datei
steht, die man gerade nicht im Kopf hat.
--stdin war noetig, um den Fernteil ueberhaupt ohne Terminal pruefen zu
koennen; --from-env macht die Datei nuetzlich, wenn man sie ohnehin behaelt.
Beides in .env.example dokumentiert, samt dem Preis: Ein Klartext-Passwort auf
der Platte ist so sicher wie die Platte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drei Fehler, alle drei ohne Fehlermeldung:
Skript per Heredoc UND Passwort per Pipe geht nicht — kommt das Skript ueber
stdin, frisst ein `cat` darin den Rest des eigenen Skripts. Die Fassung endete
nach drei Zeilen, schrieb nichts und meldete Erfolg. Gemessen: Pipe+Heredoc ->
0 Zeichen kommen an, Skript als Argument -> alles. Jetzt geht beides ueber
einen Strom: erste Zeile Passwort, dann das Skript.
`case "$PW" in *"$(printf '\n')"*` lehnte jedes Passwort ab: Die
Kommandosubstitution schneidet Zeilenumbrueche ab, das Muster ist leer, und
`*""*` passt immer.
`DIR=… read …` setzt DIR nur fuer das read; das folgende export exportierte
eine leere Variable.
Geprueft gegen ein Wegwerf-Verzeichnis auf dem echten Server, mit einem
Passwort voller Sonderzeichen, und danach unabhaengig nachgehalten: richtiges
Passwort akzeptiert, falsches abgelehnt. Das Verzeichnis ist wieder weg.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Schlusshinweis erklaerte einen Fehler, den man in dem Moment gar nicht
gemacht hat, in Begriffen von vorhin ('genauso wie beim Hashen') — nach einem
gelungenen Vorgang ist das ein Raetsel statt einer Hilfe.
Jetzt steht dort zuerst der fertige Befehl, mit der oeffentlichen Adresse aus
DEPLOY_TARGET eingesetzt, und was er liefern soll. Die Warnung kommt danach,
in einem Satz und ohne Rueckbezug.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Schlusshinweis empfahl 'curl -su werkbaum:<passwort>' — dieselbe Falle wie
beim Hashen, nur auf der anderen Seite: Die Shell fasst das Passwort an, und
die Antwort ist ein 401, obwohl der Hash stimmt. 'curl -su werkbaum' fragt
selbst danach.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Dienst lief einmal und stuerzte danach in einer Schleife: MODE=PostgreSQL
laesst H2 unquotierte Bezeichner klein anlegen, Liquibase sucht seine
Verwaltungstabellen gross, findet nichts, legt sie an — "Table
databasechangelog already exists". Der erste Start ging, jeder weitere nicht.
Gemessen mit dem echten Jar: ohne den Modus laufen beide. Liquibase auf
Kleinschreibung zu konfigurieren half nicht, es korrigiert den Namen selbst
zurueck — deshalb weicht der Modus ganz.
Die Testsuite konnte das nicht finden (jeder Test bekommt eine frische
In-Memory-DB), und der Regressionstest dafuer hat zweimal gelogen: erst reichte
er die URL als Default-Property herein, die die application.yaml ueberstimmt;
dann als Argument, aber damit pruefte er eine URL, die er sich selbst
ausgedacht hatte. Jetzt hat die URL einen Regler (werkbaum.data-dir), der Test
ueberschreibt nur den, und die Gegenprobe faellt.
Dieselbe Sorte Fehler eine Ebene hoeher: Die Testkonfiguration hiess
application.yaml und verdeckte damit die Hauptkonfiguration vollstaendig. Sie
ist jetzt eine Profil-Ueberlagerung.
Dazu GET /api/v1/info mit Name, Version und Bauzeitpunkt. Die Lebendprobe
erwartete bisher eine 404 von einem Dokument, das es nicht gibt — ein
erwarteter Fehler ist eine schlechte Zusicherung, dieselbe 404 liefert auch ein
falsch konfigurierter Proxy.
138 Backend-Tests. Gegenprobe: MODE=PostgreSQL zurueck -> genau der
Neustart-Test faellt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
