Die Geraeteschicht: Abbild, A/B-Wurzel mit Ruecksprung, Verschluesselung, Installation, Konsole. Nutzlast-unabhaengig.
Find a file
Thomas Reitz 34a2280aba ADR-0003: Ein Xinion-Geraet hat keinen Auslagerungsspeicher
Bei der Durchsicht der Aufbauten in infra aufgefallen: Der Tresor-Pod laeuft mit
disable_mlock. Im Behaelter ist das unvermeidlich und mit eingebautem Speicher vertretbar —
aber nur unter einer Bedingung, die bisher nirgends stand. Ohne Speicherfestnagel darf der
Arbeitsspeicher des Tresors ausgelagert werden, und das ist genau der Speicher mit den
entschluesselten Zugangsdaten aller Zielsysteme des Kunden. Es entstuende eine zweite,
unbewachte Kopie ausserhalb des Tresors, ausserhalb seiner Richtlinien und ausserhalb der
Pruefspur — die das Herunterfahren ueberlebt und die keine Loeschregel dieser Entscheidung
erfasst.

Die Anforderung gehoert in die Geraeteschicht und nicht in die Nutzlast: Ein Pod bestimmt
nicht, ob sein Wirt auslagert. Eine Anforderung, die nur die Nutzlast kennt aber nur der
Wirt erfuellen kann, ist die Art Luecke, die niemandem auffaellt.

Der Preis ist gering und faellt sogar guenstig aus: Ohne Auslagerung ist ein
Speicherueberlauf ein harter Abbruch statt einer Verlangsamung — ein zaehes Geraet sieht wie
ein Leistungsproblem aus und wird tagelang gesucht, ein abgebrochener Pod startet neu und
steht im Protokoll.

Suspend-to-Disk faellt aus demselben Grund weg. Das Absturzabbild des Kerns bleibt offen und
beruehrt das Diagnosepaket aus ADR-0007.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-02 18:57:25 +02:00
abbild XinionOS als eigenes Erzeugnis herausgeloest 2026-08-20 08:02:55 +02:00
docs ADR-0003: Ein Xinion-Geraet hat keinen Auslagerungsspeicher 2026-09-02 18:57:25 +02:00
nutzlast XinionOS als eigenes Erzeugnis herausgeloest 2026-08-20 08:02:55 +02:00
wurzel XinionOS als eigenes Erzeugnis herausgeloest 2026-08-20 08:02:55 +02:00
.gitignore XinionOS als eigenes Erzeugnis herausgeloest 2026-08-20 08:02:55 +02:00
BRIEFING.md Einstieg fuer xinionos-dev: zwei VMs, und was eine VM nicht beweisen kann 2026-08-31 22:26:51 +02:00
CLAUDE.md Verweis auf appliance/ADR-0004 richtiggestellt, Produktnamensverbot nennt auch XinionONE 2026-08-31 22:08:40 +02:00
README.md Schichtenmodell im README auf ADR-0005 nachgezogen 2026-08-21 17:32:50 +02:00
START.md Einstieg fuer xinionos-dev: zwei VMs, und was eine VM nicht beweisen kann 2026-08-31 22:26:51 +02:00

XinionOS — das Betriebssystem der Xinion-Appliances

XinionOS ist die Geräteschicht unter den Appliance-Produkten des Hauses. 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.

Wo es im Haus steht

Ebene Was Beispiele
Anwendungen Fachliche Produkte COSMOS, INSIGHT, ORION
Plattform Laufzeit- und Betriebsschicht OLYMPUS mit GAIA Lite · oder die Wirt-Dienste einer Fach-Appliance
Gerät XinionOS diese Ablage
Infrastruktur Rechenzentrum GAIA Full

Beim Kunden auf Blech ist XinionOS das, worauf die Verkaufsvariante der Plattform läuft.

Was es leistet

  • Ein Abbild, unbeaufsichtigt installierbar — der Techniker legt das Medium ein und geht.
  • Zwei abwechselnd beschriebene Wurzeln. Ein Update schreibt nie in die laufende Fassung.
  • Ein Selbstprüflauf entscheidet über den Start. Nicht „bootet" gilt als Erfolg, sondern „ist arbeitsfähig".
  • Rücksprung ohne Zutun. Kommt eine neue Fassung nicht sauber hoch, kehrt das Gerät nach begrenzten Versuchen von selbst zurück.
  • Betrieb ohne Internet. Nichts holt sich selbsttätig Aktualisierungen.
  • Eine Einhängestelle für genau eine Nutzlast — siehe nutzlast/.

Was es ausdrücklich nicht leistet

Keine Fachlichkeit, keine Anwendungslogik, keine Benutzerverwaltung, keine Mandantenfähigkeit. Das alles ist Sache der Nutzlast.

Einstieg