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 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 ist ein statisch gelinktes Linux-ELF. Sie enthält Oberfläche, Hardware-Scanner, Python-Laufzeit, TLS, SQLite und alle unmittelbar benötigten Laufzeitbibliotheken. Sie benötigt weder eine installierte Python-Version noch Shell-, Archiv- oder glibc-Werkzeuge. Geprüfte Programmdateien werden in den Benutzer-Cache entpackt. Einstellungen, Berichte und die Offline-Warteschlange liegen standardmäßig unter ~/.local/share/csr-intake.

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

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

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

Die Anwendung ist für x86-64 Linux ab Kernel 4.4 gebaut. Clientprogramme für WLAN, HTTP, Audio, Video, SMART und USB werden in den Build übernommen, sofern sie auf dem Build-Rechner verfügbar sind. Benötigt werden nur eine grafische Linux-Sitzung, der Kernel und die Systemdienste für die tatsächlich verwendete Hardware, insbesondere der NetworkManager-Dienst für WLAN. Ein im Build nicht vorhandenes Diagnosewerkzeug macht nur den betreffenden Test nicht verfügbar.

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 --check-bundle

Das Ergebnis liegt in dist/csr-intake-x86_64. 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 ELF-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
`launcher/`	Statischer ELF-Starter und eingebettete Laufzeit
`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.