107 lines
4.2 KiB
Markdown
107 lines
4.2 KiB
Markdown
# CS-R Intake
|
|
|
|
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
|
|
|
|
1. `csr-intake-x86_64.run` auf dem zu prüfenden Linux-Rechner starten.
|
|
2. Beim ersten Einsatz unter **Einstellungen** das Werkstatt-WLAN verbinden und
|
|
**WLAN speichern** aktiviert lassen.
|
|
3. Das Gerät wird über DMI-UUID oder Hersteller und Seriennummer erkannt.
|
|
4. Die Inventarverwaltung liefert die vorhandene Gerätenummer oder vergibt eine neue.
|
|
5. Neue Geräte und Geräte im Status **Eingang** erhalten automatisch einen Kurzscan
|
|
mit Modell, CPU, RAM und Datenträgern.
|
|
6. Danach kann der Techniker die Anwendung schließen oder die Inspektion starten.
|
|
7. 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`.
|
|
|
|
```bash
|
|
chmod +x csr-intake-x86_64.run
|
|
./csr-intake-x86_64.run
|
|
```
|
|
|
|
Ein anderer Datenordner kann mit `--data /pfad/zum/ordner` gewählt werden:
|
|
|
|
```bash
|
|
./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/`:
|
|
|
|
```text
|
|
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
|
|
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
|
|
dieselbe `.run`-Datei bei jedem erfolgreichen Build als Artefakt bereit.
|
|
|
|
## 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](WERKSTATT-ABLAUF.md).
|