121 lines
5.1 KiB
Markdown
121 lines
5.1 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` 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 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`.
|
|
|
|
```bash
|
|
chmod +x csr-intake-x86_64
|
|
./csr-intake-x86_64
|
|
```
|
|
|
|
Ein anderer Datenordner kann mit `--data /pfad/zum/ordner` gewählt werden:
|
|
|
|
```bash
|
|
./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/`:
|
|
|
|
```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 --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](WERKSTATT-ABLAUF.md).
|