CS-R Intake ist eine eigenständige Linux-Anwendung für die Annahme und technische Prüfung gespendeter Computer. Sie erkennt das aktuelle Gerät über eine stabile Hardware-ID, verbindet es mit der Inventarverwaltung und speichert alle Arbeiten auch ohne Netzwerk lokal.

Ablauf in der Werkstatt

csr-intake-x86_64.run auf dem zu prüfenden Linux-Rechner starten.
Beim ersten Einsatz unter Einstellungen das Werkstatt-WLAN verbinden und WLAN speichern aktiviert lassen.
Das Gerät wird über DMI-UUID oder Hersteller und Seriennummer erkannt.
Die Inventarverwaltung liefert die vorhandene Gerätenummer oder vergibt eine neue.
Neue Geräte und Geräte im Status Eingang erhalten automatisch einen Kurzscan mit Modell, CPU, RAM und Datenträgern.
Danach kann der Techniker die Anwendung schließen oder die Inspektion starten.
Prüfstände und Ergebnisse werden als Inspektion synchronisiert. Offline gespeicherte Ergebnisse bleiben in der Warteschlange und werden später gesendet.

Die Oberfläche konzentriert sich auf Gerät, Inspektion und Einstellungen. Reparaturen, Berichte und die Synchronisationswarteschlange sind über das Menü erreichbar.

Funktionen

automatische Hardware-ID und serverseitig vergebene Gerätenummer
Schutz vor doppelten Datensätzen
gespeichertes Werkstatt-WLAN mit geschütztem Passwort
umschaltbare deutsche oder US-Tastaturbelegung
geräteabhängige Tests für Akku, Touchpad, Webcam und mehrere Laufwerke
getrennte Ergebnisse für Hardwarefehler, nicht verfügbaren Test, Einrichtungsproblem, nicht geprüft und nicht vorhanden
Wiederaufnahme nach Neustart oder Stromunterbrechung
Reparaturnotizen und erneute Prüfung betroffener Komponenten
druckbarer Abschlussbericht mit Messwerten und Freigabe
dauerhafte Offline-Warteschlange mit sicheren Wiederholungen
zentrale Sprache, Testdauer und Grenzwerte
verifizierbarer Build mit Versions- und Prüfsummenmanifest

Anwendung starten

Die Release-Datei enthält Oberfläche und Hardware-Scanner. Sie entpackt geprüfte Programmdateien in den Benutzer-Cache und speichert Einstellungen, Berichte und die Offline-Warteschlange standardmäßig unter ~/.local/share/csr-intake.

chmod +x csr-intake-x86_64.run
./csr-intake-x86_64.run

Ein anderer Datenordner kann mit --data /pfad/zum/ordner gewählt werden:

./csr-intake-x86_64.run --data "$HOME/csr-intake-daten"
./csr-intake-x86_64.run --version
./csr-intake-x86_64.run --check-bundle

Die Anwendung ist für x86-64 Linux gebaut. Sie benötigt eine grafische Sitzung, Python 3, SQLite und NetworkManager. Einzelne Diagnosen verwenden Systemwerkzeuge wie smartctl, stress-ng, ffmpeg, arecord, lsusb und xdg-open. Fehlt ein Werkzeug, wird der Test als nicht verfügbar und nicht als Hardwarefehler bewertet.

Konfiguration

Diese Dateien entstehen im Datenordner unter config/:

inventory.json
inventory-api-key
inventory-server.crt
workshop-wifi.json
workshop.json

API-Schlüssel und WLAN-Passwort gehören nie in Git. Ein privates CA-Zertifikat darf nur als öffentliches Zertifikat gespeichert werden. Sensible Konfigurationsdateien sind nur für den Besitzer lesbar.

Projekt bauen und prüfen

Voraussetzungen sind Rust, Cargo, Python 3 sowie die Entwicklungsbibliotheken für X11, Wayland und OpenGL. Der vollständige Build führt Rust-, Python- und Rauchtests aus und erzeugt anschließend genau ein verteilbares Artefakt:

bash scripts/build-release.sh
./dist/csr-intake-x86_64.run --check-bundle

Das Ergebnis liegt in dist/csr-intake-x86_64.run. build/release.json enthält Build-ID, Versionen und SHA-256-Prüfsummen der eingebetteten Programme. Die CI stellt bei jedem erfolgreichen Build eine neutrale .run-Datei ohne Zugangsdaten als Artefakt bereit.

Für eine werkstattgebundene Datei können inventory-api-key und inventory-server.crt vor dem Build in .bundle-secrets/ abgelegt werden. Der Build bettet sie dann zusammen mit der Serveradresse ein und setzt die fertige Datei auf Modus 0700. Beim ersten Start werden fehlende Konfigurationsdateien unter config/ angelegt; vorhandene Werte bleiben erhalten. Eine solche Datei enthält einen lesbaren Zugangsschlüssel und darf nur wie ein Passwort weitergegeben werden.

Projektaufbau

Pfad	Inhalt
`gui/`	Bedienoberfläche und geführte Tests
`scanner/`	Hardwareerkennung und Messwerte
`scripts/`	Build, Synchronisation und lokale Datenwerkzeuge
`tests/`	Python- und Rauchtests
`config.example/`	Beispiel für die Inventarverbindung

Der Inventory-Server wird in einem eigenen Repository gepflegt. Weitere Einzelheiten zum Arbeitsablauf stehen in WERKSTATT-ABLAUF.md.