03d6328dd53b0bb85c812f54826b409225d21af3
8
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Michael Sauer
|
cc398ef57a |
feat(station): Anzeige ausliefern, Migrationsprofil, display-Befehle
Schritt 8 des Plans: die fertige E-Paper-Anzeige wird endlich ausgeliefert und verdrahtet, dazu zwei liegengebliebene Dinge. - deploy.sh/setup_pi.sh uebertragen display/ (mit Panel-Treibern und HERKUNFT.md) und ninlight-display.service; setup_pi.sh installiert und aktiviert die Unit und zieht python3-pil nach - ohne Pillow beendet sich der Anzeigedienst still mit 0, das faellt sonst nirgends auf. - setup_pi.sh legt auch das Profil fuer den Migrations-Zugangspunkt an (qconnex-firmware, von der alten Klyqa-Firmware fest vorgegeben, gleiche Adresse wie das Rettungsprofil). Ohne das scheiterte "migrate on" auf einem frisch eingerichteten Pi an need_profile. Bestehende Profile bleiben unangetastet. - "ninlight-station display test|clear|off"; der Hilfetext erklaert die Revisionsbestimmung, denn EPD_REVISION laesst sich nur am Testbild bestimmen. - "off" nimmt die Anzeige mit: erst Dienst stoppen, dann Panel leeren (sonst schreibt der Daemon binnen 5 s sein altes Bild zurueck) und beides vor ap_switch, das bei haengendem NetworkManager abbricht. Ein stehengebliebenes "MIGRATION" wuerde einen Betriebszustand behaupten, den es nicht mehr gibt. - test_host.sh sammelt tools/mkimage als Ganzes ein: die 19 Tests in test_nl_mkimage.py liefen in keiner Suite mehr mit, darunter die Wache fuer die Python-3.8-Randbedingung des Build-Containers. Ein neuer Test haelt die Regel fest, dass keine Testdatei mehr herausfallen kann. - Nebenbei: die Temp-Datei mit dem WLAN-Passwort wird wieder zuverlaessig aufgeraeumt, und leere Konfigurationswerte legen kein kaputtes Profil an. |
||
|
Michael Sauer
|
1cb5359754 |
fix(station): Manifest-Merge robust gegen Fehlform, Version pro Eintrag
Fixrunde 2 zu "Migrationsimages beim Deploy signieren":
- N1 (Important): das Merge-Skript im SSH-Heredoc von deploy.sh fing beim
Bestandsmanifest nur Lesefehler und kaputtes JSON ab (OSError/ValueError).
War die Datei gueltiges JSON mit falscher Form ("[]", "null", ein String,
oder ein images-Eintrag, der selbst kein Objekt ist), krachte .get() mit
AttributeError - und das VOR der Installation von
server.py/products.py/CLI/Unit und vor dem Neustart, liess einen Pi also
mit neuen Images, aber altem Stationscode zurueck. Jetzt wird alte wie
neue Manifest-Struktur konsequent auf isinstance(dict)/isinstance(list)
geprueft, jede Fehlform faellt auf ein leeres Manifest zurueck statt
abzustuerzen. Neues Szenario 21 deckt alle vier Faelle aus der
Review-Tabelle ab (kaputt, leer, falsch geformtes JSON, kaputter Eintrag).
- N2 (Important): das zusammengefuehrte Manifest hat "ninlight_version"
bisher blind vom neuen Manifest uebernommen, obwohl uebernommene
Alt-Eintraege (deren Images unveraendert liegen bleiben, siehe Fixrunde 1
I1) eine andere Firmware-Version tragen koennen - eine konkrete falsche
Version beim Protokollieren ist schlechter als das vorherige "unbekannt".
Die Version wandert jetzt PRO EINTRAG ins Manifest (deploy.sh erzeugt sie
dort, der Merge behaelt sie); das manifestweite Feld bleibt nur als
Bestandskompatibilitaet und wird nur gesetzt, wenn wirklich alle Eintraege
uebereinstimmen. server.py liest beim Ausliefern jetzt die Version DES
AUSGELIEFERTEN EINTRAGS (Station.image_version(target, variant) ersetzt
manifest_version()) und faellt nur auf das manifestweite Feld zurueck,
wenn der Eintrag selbst keine eigene traegt. test_server.py bekommt einen
neuen Test fuer den Vorrang des Eintrags vor dem manifestweiten Feld,
Szenario 14 in test_deploy.sh prueft jetzt zusaetzlich unterschiedliche
Versionen zwischen zusammengefuehrten Eintraegen und dass das
manifestweite Feld dann fehlt statt falsch zu sein. Die Spec
(docs/superpowers/specs/.../design.md, Abschnitt 4, lokal/nicht
versioniert) ist nachgezogen. Die dadurch ueberfluessig gewordene
"sorted(versions)[0]"-Stelle aus Fixrunde 1 ist entfallen.
- Kleinigkeit: die Remote-Meldung, wenn migrate/ von diesem Rechner leer
ist, behauptet nicht mehr "kein Schluesselverzeichnis" (das stimmt im
Fall "Verzeichnis vorhanden, aber leer" nicht) - sie nennt jetzt keinen
bestimmten Grund mehr, nur die Konsequenz.
- Kleinigkeit: --exclude=manifest.json ist jetzt --exclude=/manifest.json,
konsistent mit dem daneben verankerten --exclude=/migrate.
Alle drei Aenderungen (N1, N2, beide Kleinigkeiten) sind vor dem Fix per
Rot-Probe an einer Kopie von deploy.sh verifiziert: mit den urspruenglichen
Fehlern schlagen Szenario 21 (N1) bzw. Szenario 14 (N2) zuverlaessig fehl.
Bewusst nicht angefasst (Review-Vorgabe): der fehlende HOME-Testfall, und
dass der Merge kein os.path.exists() prueft.
|
||
|
Michael Sauer
|
ad2f1b8486 |
fix(station): Manifest-Form, Teilschluessel-Faelle und Schluessel-Testisolation
Fixrunde 1 zu "Migrationsimages beim Deploy signieren":
- manifest.json traegt ninlight_version und ein neues built jetzt auf oberster
Ebene statt pro Eintrag, dazu "file" statt der Redundanz einer Version pro
Bild - genau die Form aus der Spec (Abschnitt 4) und aus server.py's
Station.manifest_version(), die vorher immer "unbekannt" gelesen hat, weil
sie ausschliesslich auf oberster Ebene sucht (C1). Ein Testfall schickt das
Manifest jetzt zusaetzlich durch genau diese Funktion statt nur durch
json.load.
- Ein Schluesselverzeichnis, das existiert, aber weder Produktions- noch
Entwicklungsschluessel enthaelt, legt kein STAGE/migrate mehr an - das
vorherige Verhalten liess dafuer trotzdem ein (leeres) migrate/ mit
Manifest entstehen, das der volle rsync-Abgleich dann mit --delete gegen
ein vorhandenes migrate/ auf dem Pi durchgesetzt und es geleert hat (C2).
Aus demselben Grund war die _gz.img-Pflichtpruefung faelschlich
unconditional: fehlte sie, brach sogar ein Deploy ab, der gar nicht
signieren wollte, und nahm die Rettungsimages gleich mit (C3).
- Ein neues MIGRATE_COMPLETE-Flag (nur 1, wenn dieser Lauf mit BEIDEN
Schluesseln signiert hat) entscheidet jetzt, ob der Abgleich auf dem Pi
--delete benutzen und das Manifest ersetzen darf. Bei nur einem der beiden
Schluessel oder einem gezielten Deploy synct migrate/ ohne --delete und
merged das Manifest serverseitig mit dem vorhandenen zusammen, statt es zu
ueberschreiben - vorher raeumte ein Voll-Deploy mit nur dem dev-Schluessel
saemtliche _prod.img weg (C2, Teilfall), und ein gezielter Deploy liess ein
Manifest zurueck, das die unveraendert gebliebenen Ziele nicht mehr
erwaehnte (I1).
- ${HOME:-} statt $HOME beim Ermitteln von SIGN_DIR, damit ein Aufruf unter
`set -u` ohne gesetztes HOME (cron, env -i) nicht unnoetig abbricht, obwohl
nur die Rettungsimages gebraucht werden.
- tests/test_deploy.sh: die Sicherheitsabsicherung aus dem letzten Durchgang
hatte selbst eine Luecke (C4) - "${NINLIGHT_SIGN_DIR:-default}" in
run_deploy() greift nur, wenn die Variable NICHT gesetzt ist, und genau die
ist es, mit der man auf ~/workspace/fw-sign (das ECHTE Schluesselverzeichnis
auf diesem Rechner) zeigt. run_deploy() setzt NINLIGHT_SIGN_DIR jetzt hart
und liest dafuer nur noch die eigene Testvariable TEST_SIGN_DIR, die
deploy.sh nicht kennt und die deshalb nie von aussen vorbelegt sein kann;
am Dateikopf werden zur Sicherheit beide Variablen ge-unset. Verifiziert:
die Suite bleibt gruen, wenn NINLIGHT_SIGN_DIR vorher exportiert ist wie in
einem echten Entwicklerprofil.
- Szenario 15 vergleicht jetzt ALLE Zeilen beider privater Testschluessel
gegen Ausgabe UND Log, nicht nur eine einzelne Zeile des Produktions-
schluessels gegen die Ausgabe.
Vier neue/erweiterte Testfaelle (18-20) plus die Ergaenzung an Szenario 14:
Verzeichnis vorhanden aber leer, Voll-Deploy mit nur dev-Schluessel, echter
Server-Leser fuer das Manifest, gezielter Deploy fuehrt das Manifest zusammen
statt es zu verkuerzen. Jeder der vier Critical-Befunde wurde vor dem Fix per
Rot-Probe am kaputten Code bestaetigt.
|
||
|
Michael Sauer
|
59c8c150bd |
feat(station): Migrationsimages beim Deploy signieren
deploy.sh signiert pro Ziel das rohe _gz.img (nie das _ota.img) mit den Produktions- und Entwicklungsschluesseln aus $NINLIGHT_SIGN_DIR und legt die entstandenen _prod.img/_dev.img samt manifest.json unter migrate/ ab. Fehlt das Schluesselverzeichnis oder einzelne Schluessel, entfaellt nur die jeweilige Migrationsvariante mit einer Meldung auf stderr - die Rettungsimages werden unveraendert weiter ausgeliefert. migrate/ wird beim rsync-Abgleich auf dem Pi bewusst getrennt von den _ota.img behandelt: fehlt es lokal (kein Schluesselverzeichnis auf dem Entwicklungsrechner), bleibt ein vorhandenes migrate/ auf dem Pi unangetastet statt durch --delete geleert zu werden - derselbe Fehler, der frueher schon einmal fremde Geraetetypen weggeraeumt hat, diesmal auf die Migrationsimages angewendet. test_deploy.sh bekommt acht neue Szenarien fuer die sieben im Task-Brief verlangten Faelle plus den zusaetzlichen Schutz vor dem geleerten migrate/. Alle Szenarien erzeugen ihre eigenen Wegwerf-Testschluessel ueber nl_sign.generate_test_key() und setzen NINLIGHT_SIGN_DIR bei jedem Aufruf explizit (auch im "ohne Schluessel"-Fall) - der Default $HOME/workspace/fw-sign zeigt auf diesem Rechner auf echte Schluessel, und kein Testlauf darf sie je lesen. |
||
|
Michael Sauer
|
b41ed51018 |
feat(station): Migrationsroute mit Horch- und Freigabephase
server.py bedient jetzt zwei Modi ueber denselben Dienst: --mode/--mode-file/--control legen fest, ob ninlight_<target>_ota.img (Rettung) oder qcx_firmware_<pid>_..._ota_light.img (Migration alter Klyqa-Lampen, via products.parse_request) ausgeliefert wird. Der Modus kommt wahlweise aus einer Datei statt einem Startparameter, damit Task 4 ihn spaeter ohne Dienst-Neustart umschalten kann. Die Steuerdatei control.json (Phase auto/listen/armed) wird bei jeder Anfrage frisch gelesen und atomar mit 0644 geschrieben - eine fehlende oder kaputte Steuerdatei blockiert eine Migration nie, sondern faellt auf "auto" zurueck. Nach einer erfolgreichen Auslieferung in Phase "armed" faellt die Freigabe erst nach dem vollstaendigen Senden auf "listen" zurueck, nie davor, damit ein abgebrochener Transfer die Freigabe fuer den naechsten Bootversuch stehen laesst. status.json bekommt die Migrationsfelder aus Spec 5.2 (mode, phase, armed_target, last_seen). deploy.sh liefert products.py mit aus, sonst startet der Dienst nach dem naechsten Deploy mit ModuleNotFoundError; test_deploy.sh zieht die Sandbox-Dummy-Datei entsprechend nach. Neue Tests in test_server.py verwenden eigene server/migration_server-Fixtures samt Testklient (get/status/set_control/read_control/delete_control/write_raw_control), ohne die bestehende station-Fixture und ihre Tests anzufassen. |
||
 Michael SauerandClaude Sonnet 5
|
d464bb167e |
fix: Voll-Deploy der Rettungsstation gegen doppelte Images und stillen Loeschverlust absichern
Zwei Build-Verzeichnisse mit demselben Image-Dateinamen (z.B. build/evk und build/evk-onb, letzteres ohne WLAN-Zugangsdaten) landeten flach im selben Staging-Namen - die Sortierreihenfolge entschied zufaellig, welches gewinnt, und die Trailer-Pruefung merkt nichts, weil in beiden derselbe Geraetetyp steht. deploy.sh bricht jetzt ab und nennt beide Fundorte, statt zu raten. Der Voll-Deploy (deploy.sh <host> ohne target - der in README.md gezeigte Normalfall) loeschte per rsync --delete zudem die Images aller gerade nicht gebauten Geraetetypen, ohne je zu sagen, welche. Vor dem Loeschen wird jetzt per Namensvergleich ermittelt und ausgegeben, welche Dateien verschwinden - sichtbar statt still, ohne den Ablauf fuer Skripte zu blockieren. Neue Testszenarien 7-9 in tools/station/tests/test_deploy.sh decken beide Faelle ab. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Michael SauerandClaude Sonnet 5
|
456058956c |
fix: setup_pi.sh und deploy.sh nutzen /usr/bin/ssh und /usr/bin/scp
Auf dem Rechner des Nutzers liegt im PATH ein ssh, das sich anders verhaelt als das System-ssh - die Skripte sollen sich darauf nicht verlassen. setup_pi.sh und deploy.sh riefen ssh, scp und rsync bisher ohne vollen Pfad auf. Beide Skripte nutzen jetzt SSH_BIN/SCP_BIN mit Default /usr/bin/ssh bzw. /usr/bin/scp, ueberschreibbar per NINLIGHT_SSH_BIN/NINLIGHT_SCP_BIN - dasselbe Prinzip wie NINLIGHT_STATION_ROOT weiter unten in deploy.sh, das Tests ohne echten Pi ermoeglicht. rsync bekommt "-e $SSH_BIN", damit auch dessen Transport ueber /usr/bin/ssh laeuft. Die Beispielaufrufe in setup_pi.sh's Abschlussmeldung und in der README bleiben bewusst bei schlichtem "ssh" - dort geht es um das, was der Nutzer selbst eintippt. test: tools/station/tests/test_deploy.sh auf den neuen Override umgestellt (NINLIGHT_SSH_BIN zeigt auf den ssh-Stub) und um ein Szenario ergaenzt, das den /usr/bin/ssh- bzw. /usr/bin/scp-Default in beiden Skripten absichert. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Michael SauerandClaude Sonnet 5
|
d23b0d4e02 |
fix: Rechte-Bug und Passwort-Leck im NM-Profil, Loesch-Bug in deploy.sh
setup_pi.sh sourcte /etc/ninlight-station.conf (0600 root:root) als unprivilegierter Benutzer und scheiterte damit bei jedem Lauf, bevor das NetworkManager-Profil angelegt wurde. Die Konfiguration wird jetzt per "sudo cat" gelesen; ninlight-station macht denselben Fallback fuer den dokumentierten Aufruf als normaler Benutzer, ohne die Datei fuer alle lesbar zu machen. Das AP-Profil wird nicht mehr per "nmcli ... wifi-sec.psk $PSK" angelegt (das WLAN-Passwort waere sonst fuer jeden lokalen Prozess in der Kommandozeile sichtbar), sondern als NetworkManager-Keyfile (0600 root:root) geschrieben und per "nmcli connection load" eingelesen. deploy.sh loeschte bei einem gezielten Deploy eines einzelnen Geraetetyps per "rsync --delete" alle Images anderer Geraetetypen aus dem live ausgelieferten Verzeichnis. --delete laeuft jetzt nur noch beim Vollabgleich (kein target-Argument); ein gezielter Deploy ersetzt nur die genannten Dateien. Dabei zusaetzlich -c (Checksumme statt Groesse+Zeitstempel) ergaenzt, sonst uebersieht rsync ein neues Image mit zufaellig gleicher Byte-Groesse. Ausserdem meldet deploy.sh jetzt einen fehlgeschlagenen Dienst-Neustart als Fehler statt ihn mit "Dienst laeuft nicht" zu verwechseln. Stub-Tests unter tools/station/tests/test_deploy.sh (ssh/rsync im PATH ersetzt, Installationsschritt laeuft gegen ein Sandbox-Verzeichnis) decken beide Bugfixes sowie die bereits bestehenden Faelle ab: Image besteht die Trailer-Pruefung nicht, keine Images gefunden. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |