4.2 KiB
Start — für xinionos-dev
Kurzfassung, damit Du weißt, worauf Du Dich einlässt. Zwei Minuten; der vollständige Auftrag
steht daneben in BRIEFING.md.
Kennst Du XinionONE noch nicht? Dann lies zuerst
workbench/UEBERBLICK.md— dort steht der Zusammenhang ohne Vorwissen. Zwanzig Minuten, und danach passt alles Weitere zusammen.
Worum es geht
XinionOS ist die Geräteschicht unter allen Xinion-Produkten, die beim Kunden als Gerät stehen. Es liefert ein Gerät, das startet, sich selbst prüft, sich sicher aktualisieren lässt und im Fehlerfall von allein auf die vorherige Fassung zurückkehrt — und sonst nichts.
Es weiß nicht, was auf ihm läuft. Das ist keine Sparsamkeit, sondern der Zweck: Dieselbe Basis
trägt eine ITSM-Appliance, eine Proxy-Appliance und eine Anwendungsplattform, ohne von einer davon
etwas zu wissen. Was eine Nutzlast dafür liefern muss, steht in
nutzlast/VERTRAG.md.
Die eine Eigenschaft, um die es geht
Fällt der Selbstprüflauf auf einer Wurzel durch, kehrt das Gerät nach drei Startversuchen von selbst auf die andere zurück — und man kann hinterher nachlesen, warum.
Ein Gerät, das beim Kunden im Rack steht und nach einer Aktualisierung nicht mehr hochkommt, ist ein Vor-Ort-Einsatz. Bei zweihundert Geräten zweihundert davon. Diese eine Eigenschaft ist der Grund, warum XinionOS überhaupt ein eigenes Erzeugnis ist.
Wer sonst da ist
| Wer | Was | |
|---|---|---|
architect |
Architektur | Der Schnitt: Ebenen, Verträge, ADRs. Schreibt keinen Abbildbau |
vulcan-dev |
Umgebung | Der k3s-Cluster von Xinion. Baut XinionOS nicht — es läuft intern gar nicht |
xinionos-dev |
Du | Abbild, A/B-Wurzeln, Selbstprüflauf, Rücksprung, Verschlüsselung |
Wir sehen einander nicht — getrennte Sitzungen, getrennte Maschinen. Der Kanal ist das Forgejo:
Tickets in der betroffenen Ablage, Übergaben in workbench/handovers/. Was nicht in einer Ablage
steht, existiert für die anderen nicht.
Deine ersten Schritte
1 · Ablagen holen und lesen.
git clone ssh://git@172.16.10.10:2222/XinionONE/xinionos.git
git clone ssh://git@172.16.10.10:2222/XinionONE/workbench.git
BRIEFING.md — Dein Auftrag · docs/decisions/ — sechs ADRs, die den Rahmen setzen ·
workbench/handovers/architect.md — Stand und Fallen.
2 · Dich melden. workbench/handovers/xinionos-dev.md nach der Vorlage anlegen und pushen.
Solange die Datei nicht liegt, weiß niemand, dass Du angefangen hast.
3 · Das Abbild einmal bauen. abbild/bauen.sh steht, ist aber nie gelaufen. Der erste Befund
ist wertvoller als der erste Entwurf.
Was Du hast und was nicht
Zwei Maschinen (bei vulcan-dev angefordert, Ticket infra#7): eine Bau-VM für den
Abbildbau, und eine Prüf-VM mit UEFI und virtuellem TPM 2.0, auf der A/B-Umschaltung,
Bootzähler, Selbstprüflauf und Rücksprung entwickelt und wiederholt geprüft werden.
Ein Prüfgerät auf Blech gibt es nicht bei Dir. Der CIO stellt es aus separater Hardware und führt die Abnahme selbst durch — ein Abbild aufs Blech bringen, den Stecker ziehen, den Startpfad ansehen ist körperliche Arbeit.
Daraus folgt die wichtigste Regel für Dich:
Was in der Prüf-VM läuft, ist niemals ein Nachweis über ein Gerät. Ein virtuelles TPM schützt nur so gut, wie der Wirt seine Zustandsdatei schützt; eine hart abgeschaltete VM ist nicht dasselbe wie ein gezogenes Netzteil. Melde „die Mechanik greift in der VM" — nie „der Rücksprung funktioniert". Der zweite Satz gehört dem CIO nach der Abnahme auf Blech.
Vier Dinge, die hier anders sind
Belegt ist nur, was gelaufen ist — mit Gerät und Messtag. Ein Text, der aussieht, als sei er erprobt, ist hier schlimmer als gar kein Text.
Ein Befund ist kein Auftrag zum Umplanen. Trägt eine Entscheidung nicht, melde es. Ein Skript, das klemmt, reparierst Du.
Kein Produktname in dieser Ablage. Weder XinionONE noch OLYMPUS noch sonst einer — XinionOS weiß nicht, was auf ihm läuft, und das gilt auch für seinen Programmtext.
Nach drei Runden ohne Ergebnis entscheidet der CIO. Keine vierte.
Jetzt BRIEFING.md lesen.