77 lines
3.3 KiB
Markdown
77 lines
3.3 KiB
Markdown
# Briefing — XinionOS
|
|
|
|
> Für die Entwicklungsumgebung und für einen neu hinzukommenden Entwickler.
|
|
> **Erst lesen, dann anfangen.**
|
|
|
|
## Was dieses Erzeugnis ist
|
|
|
|
Das Betriebssystem der Xinion-Appliances. 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.
|
|
|
|
Es weiß nicht, was auf ihm läuft. Alles Fachliche kommt über den
|
|
[Nutzlast-Vertrag](nutzlast/VERTRAG.md).
|
|
|
|
## Rollenverteilung
|
|
|
|
| Wer | Was |
|
|
|---|---|
|
|
| Architektur (CIO und Entwurf) | entscheidet, **was** gebaut wird und warum |
|
|
| Entwicklung | baut es, bringt es zum Laufen, **misst** und legt den Nachweis ab |
|
|
|
|
**Begegnet der Bauplan der Wirklichkeit und verliert, ist das ein Befund und kein Auftrag zum
|
|
Umplanen.** Melde zurück, entwirf nicht neu. Faustregel: Musst Du eine Architekturentscheidung
|
|
anfassen, um weiterzukommen, ist es eine Entscheidung und keine Reparatur.
|
|
|
|
## Was zuerst zu bauen ist
|
|
|
|
**Das Abbild baut reproduzierbar, und der Rücksprung greift nachweislich.**
|
|
|
|
> 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.
|
|
|
|
### Der Nachweis, Schritt für Schritt
|
|
|
|
1. `abbild/bauen.sh <ubuntu-server.iso>` — Abbild bauen, in einer virtuellen Maschine installieren.
|
|
Das Gerät startet in **Wurzel A**.
|
|
2. Statusseite auf Anschluss 8080 aufrufen: Wurzel A, Fassung, Selbstprüflauf **bestanden**.
|
|
3. Wurzel B befüllen, Starteintrag mit drei Versuchen anlegen.
|
|
4. In Wurzel B `/etc/xinionos/selbstpruefung-scheitert` anlegen — der Prüfschalter.
|
|
5. Auf B umschalten, neu starten.
|
|
6. **Beobachten:** dreimal Fehlschlag, danach startet das Gerät **ohne Zutun** wieder in A.
|
|
7. Die Statusseite zeigt unter *Verlauf* drei durchgefallene Läufe auf B und darunter den
|
|
bestandenen auf A.
|
|
|
|
**Schritt 6 ist der Nachweis.** Ergebnis nach `docs/nachweise/`.
|
|
|
|
### Wo der erste Lauf voraussichtlich scheitert
|
|
|
|
Beim Anhängen von `autoinstall ds=nocloud;s=/cdrom/xinionos/` an die Startzeile — die Pfade zu
|
|
`grub.cfg` unterscheiden sich zwischen Ubuntu-Fassungen. **Startet das Medium und fragt trotzdem
|
|
nach der Sprache, liegt es dort und sonst nirgends.** Schnappschuss der VM vor dem ersten Versuch.
|
|
|
|
## Der Stand: nichts davon ist gelaufen
|
|
|
|
Der gesamte Inhalt ist auf einem Mac geschrieben worden, auf dem weder ein Ubuntu-Abbild gebaut
|
|
noch eine Unit gestartet werden kann. **Behandle ihn als Bauplan, nicht als Zustand.**
|
|
|
|
## Was Du nicht tust
|
|
|
|
* **Keine Architekturentscheidung treffen, keine ADR schreiben.** Melde zurück.
|
|
* **Keinen Produktnamen aufnehmen.** Weder XinionONE noch NEXTgenIT noch OLYMPUS noch sonst einen — siehe Regel 1
|
|
in `CLAUDE.md`.
|
|
* **Keine Abhängigkeit ohne Begründung im Commit-Text.** Jede steht fünf Jahre in der Stückliste.
|
|
* **Keine Zahl erfinden und keine glätten.**
|
|
* **Kein `git add -A`.**
|
|
|
|
## Wo alles steht
|
|
|
|
| Was | Wo |
|
|
|---|---|
|
|
| Regeln | `CLAUDE.md` |
|
|
| Vertrag zur Nutzlast | `nutzlast/VERTRAG.md` |
|
|
| Startverfahren und Rücksprung | `docs/decisions/ADR-0002-startverfahren-und-ruecksprung.md` |
|
|
| Gemessene Ergebnisse | `docs/nachweise/` |
|
|
|
|
**Bei Widerspruch gilt:** ADR schlägt Dokumentation, **Messung schlägt ADR.** Eine Messung, die
|
|
einer Entscheidung widerspricht, ist der wertvollste Fund überhaupt — melde ihn, bevor Du
|
|
weiterbaust.
|