SGINet: Aufbau, Protokoll und Lehren eines Rechnerverzeichnisses

NeXTnet
2. November 2026
PAP-033

SGINet ist ein Verzeichnis für Silicon-Graphics-Rechner unter IRIX, das der Betreiber flexion seit 2024 führt. Dieses Paper beschreibt, woraus es besteht, wie sich eine Maschine registriert, welches Protokoll der Client spricht, was die Website zeigt, was sich über das geschlossene Backend erschließen lässt und wie der Light-Client ältere Maschinen über ein Relay anbindet. Gelesen sind der vollständige Quelltext des Clients, der Light-Client, die Website und der Ankündigungs-Thread. Am Ende stehen die Lehren für ein Verzeichnis dieser Art: eine Identität, die ein Credential ist und keine Seriennummer, getrennte Schnittstellen für Clients und Website, und ein Protokoll, das ohne TLS und ohne richtige Uhr auskommt.

1. Gegenstand und Grenzen

Untersucht wird SGINet, ein Verzeichnis für Silicon-Graphics-Rechner unter IRIX. SGINet hat vier Schichten, und jede Aussage in diesem Paper nennt die Schicht, auf der sie beobachtet wurde.

• Der Client ist offen. Gelesen ist das Repository sginet/sginet-client auf GitHub im Stand des Commits c8007876 vom 30. Oktober 2026, jede Datei außer den mitgelieferten Fremdbibliotheken und den Bilddaten.¹ Aussagen über den Client sind damit Aussagen über diesen Stand. Im Anhang steht zu jeder Aussage Datei und Zeile.
• Der Light-Client ist ein eigener Tarball mit Quelltext und Binaries, gelesen im Stand vom 21. Februar 2026.²
• Die Website sginet.flexion.io ist am 2. November 2026 im Browser begangen worden, als Text und mit Blick auf die Aufrufe, die sie an ihre API richtet.³ Aussagen über die Website gelten für diesen Tag.
• Das Backend ist geschlossen. Alles über das Backend ist aus Hostnamen, Pfaden, Antwortfeldern und Fehlertexten erschlossen und ist als solches gekennzeichnet.
• Das Forum ist der Ankündigungs-Thread von flexion auf forums.sgi.sh mit seinen vier Beiträgen bis zum 19. Oktober 2026.⁴

Kein Programm von SGINet wurde gebaut oder ausgeführt. Der Quelltext liegt als Archiv unter sources/ neben diesem Dokument.

2. Woraus SGINet besteht

SGINet besteht aus fünf Teilen. Drei davon laufen auf dem SGI-Rechner, einer in der Cloud, einer im Browser.

Die Clients werden mit dem IRIX-eigenen Compiler gebaut und als tardist-Paket für IRIX 6.5 und IRIX 5.3 verteilt, das die Programme nach /usr/bin legt und ein init-Skript für den Daemon einrichtet.¹ Alle drei Programme sprechen TLS 1.2 mit der Cloud; die fünf Wurzelzertifikate von Amazon sind in die Binaries einkompiliert, und wo /dev/urandom fehlt, sammelt der Client Entropie aus Zeitmessungen und einer Seed-Datei.¹ Der Updater lädt ein neues Binary von einer Adresse, die das Backend nennt, und prüft nur dessen Dateigröße.¹

3. Registrierung und Identität

Die Identität einer Maschine ist ihre Hardware-Seriennummer. Der Client liest sie mit syssgi(SGI_SYSID) und schreibt sie als Hexstring in jede Anfrage.¹ Es gibt kein Token, keine Signatur und kein Passwort. Wer die Seriennummer einer fremden Maschine kennt, kann für sie pingen, ihr Inventar ersetzen oder sie umbenennen. Die Website zeigt die Seriennummer nicht; öffentlich ist eine Kennung aus Benutzername und gekürztem Hash.³

Die Registrierung läuft so ab: Beim Start sendet der Client hello. Antwortet das Backend mit dem Code 2, zeigt der Client einen Hinweis, dass Inventar und Benutzername öffentlich werden, fragt beim Backend die Modellnamen zum Maschinentyp aus uname ab, lässt den Benutzer das Modell wählen, fragt Benutzername und Maschinenname ab und sendet register. Das Backend kann in jeder Antwort mit requestHINV ein frisches Inventar anfordern.¹ Der Benutzername ist frei wählbar und an kein Konto gebunden. Wer seinen Eintrag löschen lassen will, schreibt dem Betreiber eine Nachricht im Forum.⁴

4. Das Protokoll des Clients

Alles ist HTTPS-POST mit einem JSON-Objekt, dessen Feld action die Operation nennt. Der Client spricht fünf Endpunkte unter einem Pfad, der nach AWS API Gateway aussieht.¹

In jeder Anfrage steht ein Objekt client, das der Client aus seinem Zustand füllt. Der Ping ist nichts anderes als dieses Objekt.

Das Inventar ist ein Objekt hinv. Es verbindet drei Dinge: Werte aus Systemaufrufen, die erste Zeile zweier hinv-Kommandos und das rohe Inventar des Kernels aus getinvent().

Die Deutung der Zahlen in inv übernimmt das Backend: Die Website zeigt zu jedem Eintrag ein classLabel und ein deviceLabel, die der Client nicht sendet.³ Antworten sind flach: success, message, bei Fehlern code, bei Listen ein Array lst.

5. Was die Website zeigt

Am 2. November 2026 führte die Liste 78 Systeme, davon 4 online, mit zwölf Modellgruppen zum Filtern. Drei Zustände sind sichtbar: online, offline und ohne Zustand, letzteres bei Maschinen, die nur über den manuellen Upload in die Liste gekommen sind und nie gepingt haben.³

Die Website spricht dieselbe Cloud-Funktion wie der Client, aber über einen zweiten Hostnamen und mit eigenen Aktionen: getSystemsList, getSystemHINV, getHallOfFame, getDownloadLinks, listScreenshotsByUsername, getMarkersWeb. Eine Client-Aktion ohne das Objekt client weist das Backend mit der Meldung No client info ab.³ Die Shoutbox ist laut Forum nur in den Clients sichtbar und nicht auf der Website.⁴

6. Das Backend, aus Spuren erschlossen

Nichts in diesem Abschnitt ist gelesen. Es ist aus dem erschlossen, was Client und Website preisgeben.

7. Der Light-Client und das Relay

Für IRIX 4 und 5 ohne aktuelles TLS gibt es den Light-Client. Sein erstes Programm druckt dasselbe Inventar wie der große Client als eine JSON-Zeile mit action: hinv-upload, clientID, uptime und format: 1; der Besitzer fügt diese Zeile auf der Website im Dialog „Upload HINV“ ein.² Sein zweites Programm pingt mit action: ping-light über reines TCP und HTTP/1.1 ohne jede Verschlüsselung an einen Hostnamen und Port, die der Besitzer angibt.²

Dort steht ein nginx im LAN des Besitzers, der die Anfrage entgegennimmt und mit TLS an die Cloud weiterreicht; die mitgelieferte Konfiguration setzt dafür den Host-Header und den TLS-Servernamen.² Der Light-Client weiß von alldem nichts. Für ihn ist das Relay der Server. Für Maschinen mit einem alten curl gibt es daneben einen zweiten Gateway-Hostnamen, der noch TLS 1.0 annimmt.²

8. Was aus dem Befund nicht folgt

Dass das Backend keine weitere Prüfung der Identität vornimmt, folgt nicht. Gelesen ist, was der Client sendet, und das ist die Seriennummer ohne Signatur. Was das Backend daraus macht, ist nicht sichtbar. Eine IP-Bindung oder eine Plausibilitätsprüfung des Inventars wäre von außen nicht zu erkennen.

Dass die Emulatorprüfung an einem bestimmten Merkmal hängt, folgt nicht. Der Client sendet die Seriennummer, den Maschinentyp und das rohe Inventar; welches davon das Backend prüft, ist nicht sichtbar.

Dass die Website alle Felder zeigt, die das Backend speichert, folgt nicht. Die Antworten der Website-Aktionen enthalten die Felder aus Tabelle 5 und wenige mehr, etwa isNew und sort. Was sonst in der Datenbank liegt, bleibt offen.

Dass der Betrieb so bleibt, folgt nicht. Die Endpunkte, die Hostnamen und die Updater-Dateien sind der Stand des 2. November 2026; das Forum zeigt, dass flexion die Verteilung innerhalb eines Jahres zweimal umgestellt hat, von RPM auf tardist und von SGUG-RSE-Abhängigkeiten auf statische Binaries.⁴

9. Lehren für ein Verzeichnis dieser Art

Aus dem Befund folgen Lehren für jedes Verzeichnis, das alte Rechner über das Netz registriert und ihren Zustand zeigt. Sie gelten unabhängig von der Plattform.

1. Die Identität einer Maschine ist ein Credential, keine Seriennummer. Eine Seriennummer, die im Klartext in jeder Anfrage steht, ist für jeden Mitleser und für jeden, der sie je gesehen hat, der Schlüssel zur Maschine. Ein Verzeichnis gibt jeder Maschine bei der Registrierung ein eigenes Geheimnis und prüft damit jede Anfrage.
2. Was von alten Maschinen kommt, wird im Klartext kommen. TLS auf einem System der Neunziger scheitert an Bibliotheken, an Wurzelzertifikaten, an Entropie und an der Uhr; SGINet braucht dafür einkompilierte Zertifikate, einen Entropie-Rückfall, einen zweiten Hostnamen für TLS 1.0 und am Ende ein Relay im LAN. Ein Protokoll, dessen Sicherheit in der Nachricht liegt, kommt ohne all das aus, und ein Relay bleibt trotzdem möglich, wenn der Client seine Serveradresse aus einer Konfiguration liest.
3. Die Uhr der Maschine ist nicht zu gebrauchen. Pufferbatterien sind leer, und ein Zertifikat ist dann abgelaufen oder noch nicht gültig. Ein Prüfmerkmal gegen Wiederholung darf deshalb nicht an der Zeit hängen, sondern an einem Zähler oder einer Nonce.
4. Client-Schnittstelle und Website-Schnittstelle sind zwei Dinge. SGINet trennt sie durch Aktionsnamen und ein Pflichtfeld und weist Anfragen ohne Client-Objekt ab. Die Trennung gehört an die Adresse, damit die eine Seite ohne Zertifikat auskommt und die andere Konten und Anmeldung bekommen kann.
5. Rohdaten sammeln, Deutung dem Server lassen. Der Client sendet die Zahlen des Kernel-Inventars, der Server macht daraus Klassen- und Gerätenamen. Der Client bleibt klein und muss für eine bessere Deutung nicht neu verteilt werden.
6. Den Produktnamen kennt der Kernel nicht. Er kennt eine Typnummer, der Besitzer kennt das Gerät auf seinem Tisch. Der Server liefert zur Typnummer eine Liste von Modellen, aus der der Besitzer wählt, mit einem Feld für alles, was nicht in der Liste steht.
7. Online ist ein Fenster, Uptime ist eine Rechnung. Ein Lebenszeichen im festen Takt, ein Fenster von zwei Takten für „online“ und daraus auf dem Server Gesamt-Uptime und längste Uptime; eine Hall of Fame aus diesen Zahlen hält die Besitzer bei der Stange.
8. Sagen, was öffentlich wird, bevor es öffentlich wird. SGINet zeigt den Hinweis vor der Registrierung. Ein Verzeichnis, das Besitzername und Standort zeigt, braucht dazu eine Einwilligung, die der Besitzer selbst widerrufen kann, und eine Löschung, für die er niemanden anschreiben muss.
9. Ein Updater, der nur die Dateigröße prüft, ersetzt das Binary durch alles, was die richtige Länge hat. Eine Aktualisierung über das Netz braucht eine Signatur, die der Client vor dem Austausch prüft, oder sie findet über das Paketsystem des Betriebssystems statt.
10. Stillschweigendes Abweisen ist für den Besitzer nicht von einem Fehler zu unterscheiden. Wer Emulatoren nicht will oder sie anders zeigt, sagt es in der Antwort und auf der Website.
11. Der Weg auf eine alte Maschine ist das Paketsystem und das Netz. SGINet liefert ein natives Paket je Systemgeneration, statisch gelinkt, mit init-Skript, und die Besitzer holen es auf einem heutigen Rechner und kopieren es auf die alte Maschine. Ein Download auf der alten Maschine selbst ist nicht die Regel.

Quellennachweis

Vier Quellen, in der Reihenfolge ihres Auftretens. Der Quelltext des Clients und des Light-Clients ist vollständig gelesen, die Website als Text begangen, der Thread vollständig gelesen.

1. sginet: sginet-client, Stand des Commits c8007876 vom 30. Oktober 2026. Quelltext vollständig gelesen Quelle↩↩↩↩↩↩↩
2. flexion: sginet-client-light V20260221-0830, Tarball mit README, Quelltext, Skripten und nginx-Konfiguration. Volltext gelesen Quelle↩↩↩↩↩
3. flexion: SGINet, Website, begangen am 2. November 2026: Startseite, Systemliste, Detail EMPIRICIST, Screenshots, Hall of Fame, Softwaresuche, Downloads, About, Weltkarte. Als Text gelesen, API-Aufrufe mitgeschrieben Quelle↩↩↩↩↩
4. flexion: SGINet, CLI client + daemon + X11 app for SGI systems running IRIX. Thread im Forum der Silicon Graphics User Group, 10. August 2024, mit Beiträgen vom 27. September 2025 und 19. Oktober 2026. Volltext gelesen Quelle↩↩↩↩