ich geh behindert
This commit is contained in:
@@ -1,123 +0,0 @@
|
||||
# Blueprint-Integration in app.py
|
||||
|
||||
## Übersicht
|
||||
|
||||
Alle Flask-Blueprints wurden erfolgreich in die zentrale `app.py` Datei integriert. Dies vereinfacht die Anwendungsstruktur und reduziert die Komplexität der Codebase.
|
||||
|
||||
## Durchgeführte Änderungen
|
||||
|
||||
### 1. Entfernte Blueprint-Dateien
|
||||
- `backend/app/blueprints/auth.py` - Authentifizierungs-Routen
|
||||
- `backend/app/blueprints/user.py` - Benutzer-Verwaltungsrouten
|
||||
- `backend/app/blueprints/api.py` - API-Routen
|
||||
- `backend/app/blueprints/kiosk_control.py` - Kiosk-Steuerungsrouten
|
||||
- `backend/app/blueprints/__init__.py` - Blueprint-Initialisierung
|
||||
- Gesamter `backend/app/blueprints/` Ordner wurde entfernt
|
||||
|
||||
### 2. Integrierte Funktionalitäten in app.py
|
||||
|
||||
#### Authentifizierungs-Routen (ehemals auth.py)
|
||||
- `/auth/login` - Login-Seite und -Verarbeitung (GET/POST)
|
||||
- `/auth/logout` - Logout-Funktionalität (GET/POST)
|
||||
- `/auth/api/login` - API-Login für Frontend
|
||||
- `/auth/api/callback` - API-Callback-Verarbeitung
|
||||
|
||||
#### Benutzer-Routen (ehemals user.py)
|
||||
- `/user/profile` - Benutzerprofil anzeigen
|
||||
- `/user/settings` - Benutzereinstellungen anzeigen
|
||||
- `/user/update-profile` - Profil aktualisieren (POST)
|
||||
- `/user/api/update-settings` - API für Einstellungen (POST)
|
||||
- `/user/update-settings` - Einstellungen aktualisieren (POST)
|
||||
- `/user/change-password` - Passwort ändern (POST)
|
||||
- `/user/export` - Benutzerdaten exportieren (GET)
|
||||
- `/user/profile` - Profil-API (PUT)
|
||||
|
||||
#### Kiosk-Steuerungsrouten (ehemals kiosk_control.py)
|
||||
- `/api/kiosk/status` - Kiosk-Status abfragen (GET)
|
||||
- `/api/kiosk/deactivate` - Kiosk deaktivieren (POST)
|
||||
- `/api/kiosk/activate` - Kiosk aktivieren (POST)
|
||||
- `/api/kiosk/restart` - System-Neustart (POST)
|
||||
|
||||
#### Job-Management-Routen (ehemals api.py)
|
||||
- `/api/jobs` - Jobs abrufen/erstellen (GET/POST)
|
||||
- `/api/jobs/<id>` - Spezifischen Job abrufen/löschen (GET/DELETE)
|
||||
- `/api/jobs/active` - Aktive Jobs abrufen (GET)
|
||||
- `/api/jobs/current` - Aktuellen Job abrufen (GET)
|
||||
- `/api/jobs/<id>/extend` - Job verlängern (POST)
|
||||
- `/api/jobs/<id>/finish` - Job beenden (POST)
|
||||
- `/api/jobs/<id>/cancel` - Job abbrechen (POST)
|
||||
|
||||
#### Drucker-Management-Routen (ehemals api.py)
|
||||
- `/api/printers` - Drucker abrufen/erstellen (GET/POST)
|
||||
- `/api/printers/status` - Drucker-Status mit Live-Check (GET)
|
||||
- `/api/printers/<id>` - Spezifischen Drucker abrufen/bearbeiten/löschen (GET/PUT/DELETE)
|
||||
|
||||
#### Admin-Routen
|
||||
- `/api/admin/users` - Benutzer verwalten (GET)
|
||||
- `/api/admin/users/<id>` - Benutzer bearbeiten/löschen (PUT/DELETE)
|
||||
- `/api/stats` - Statistiken abrufen (GET)
|
||||
|
||||
#### UI-Routen
|
||||
- `/` - Hauptseite
|
||||
- `/dashboard` - Dashboard
|
||||
- `/printers` - Drucker-Übersicht
|
||||
- `/jobs` - Jobs-Übersicht
|
||||
- `/stats` - Statistiken
|
||||
- `/admin-dashboard` - Admin-Panel
|
||||
- `/demo` - Komponenten-Demo
|
||||
|
||||
### 3. Hilfsfunktionen
|
||||
- `check_printer_status()` - Einzelner Drucker-Status-Check
|
||||
- `check_multiple_printers_status()` - Paralleler Status-Check für mehrere Drucker
|
||||
- `job_owner_required` - Decorator für Job-Besitzer-Berechtigung
|
||||
|
||||
### 4. Fehlerbehandlung
|
||||
- 404 - Seite nicht gefunden
|
||||
- 500 - Interner Serverfehler
|
||||
- 403 - Zugriff verweigert
|
||||
|
||||
### 5. Entfernte Imports
|
||||
Aus `app.py` entfernt:
|
||||
```python
|
||||
from blueprints.auth import auth_bp
|
||||
from blueprints.user import user_bp
|
||||
from blueprints.api import api_bp
|
||||
from blueprints.kiosk_control import kiosk_bp
|
||||
```
|
||||
|
||||
Und die entsprechenden Blueprint-Registrierungen:
|
||||
```python
|
||||
app.register_blueprint(auth_bp, url_prefix="/auth")
|
||||
app.register_blueprint(user_bp, url_prefix="/user")
|
||||
app.register_blueprint(api_bp, url_prefix="/api")
|
||||
app.register_blueprint(kiosk_bp, url_prefix="/api/kiosk")
|
||||
```
|
||||
|
||||
## Vorteile der Integration
|
||||
|
||||
1. **Vereinfachte Struktur**: Alle Routen sind in einer zentralen Datei
|
||||
2. **Reduzierte Komplexität**: Keine Blueprint-Verwaltung mehr nötig
|
||||
3. **Bessere Übersicht**: Alle Funktionalitäten auf einen Blick
|
||||
4. **Einfachere Wartung**: Weniger Dateien zu verwalten
|
||||
5. **Direkte Imports**: Keine Blueprint-spezifischen Imports mehr nötig
|
||||
|
||||
## Getestete Funktionalitäten
|
||||
|
||||
Alle ursprünglichen Funktionalitäten wurden beibehalten:
|
||||
- ✅ Benutzer-Authentifizierung
|
||||
- ✅ Job-Management
|
||||
- ✅ Drucker-Verwaltung
|
||||
- ✅ Admin-Funktionen
|
||||
- ✅ Kiosk-Modus
|
||||
- ✅ API-Endpunkte
|
||||
- ✅ Fehlerbehandlung
|
||||
|
||||
## Nächste Schritte
|
||||
|
||||
Die Anwendung ist jetzt bereit für den Betrieb ohne Blueprints. Alle Routen und Funktionalitäten sind vollständig in `app.py` integriert und funktionsfähig.
|
||||
|
||||
---
|
||||
|
||||
**Datum**: $(date)
|
||||
**Status**: ✅ Abgeschlossen
|
||||
**Getestet**: ✅ Alle Routen funktional
|
||||
@@ -1,230 +0,0 @@
|
||||
# Häufige Fehler und Lösungen
|
||||
|
||||
Dieses Dokument enthält häufig auftretende Probleme bei der Einrichtung und Nutzung von MYP im Kiosk-Modus und deren Lösungen.
|
||||
|
||||
## Installationsprobleme
|
||||
|
||||
### Fehler: "Paket nicht gefunden"
|
||||
|
||||
**Problem**: Beim Ausführen von `apt install` werden Pakete nicht gefunden.
|
||||
|
||||
**Lösung**:
|
||||
1. Führe zuerst `sudo apt update` aus, um die Paketlisten zu aktualisieren
|
||||
2. Stelle sicher, dass eine Internetverbindung besteht
|
||||
3. Bei älteren Raspberry Pi OS Versionen ggf. Repository hinzufügen:
|
||||
```bash
|
||||
sudo apt-add-repository universe
|
||||
sudo apt update
|
||||
```
|
||||
|
||||
### Fehler: "Permission denied" beim Kopieren nach /opt/myp
|
||||
|
||||
**Problem**: Beim Kopieren der Dateien nach /opt/myp wird ein Permission-Fehler angezeigt.
|
||||
|
||||
**Lösung**:
|
||||
1. Stelle sicher, dass du die Befehle in der richtigen Reihenfolge ausführst:
|
||||
```bash
|
||||
sudo mkdir -p /opt/myp
|
||||
sudo chown $USER:$USER /opt/myp
|
||||
```
|
||||
2. Falls das nicht hilft, führe den Kopierbefehl mit sudo aus:
|
||||
```bash
|
||||
sudo cp -r ./myp/* /opt/myp/
|
||||
sudo chown -R $USER:$USER /opt/myp/
|
||||
```
|
||||
|
||||
## Flask-Backend Probleme
|
||||
|
||||
### Fehler: "MYP-Dienst startet nicht"
|
||||
|
||||
**Problem**: Der systemd-Dienst für das Flask-Backend startet nicht.
|
||||
|
||||
**Lösung**:
|
||||
1. Überprüfe den Status des Dienstes:
|
||||
```bash
|
||||
sudo systemctl status myp.service
|
||||
```
|
||||
2. Schau in die Logs:
|
||||
```bash
|
||||
sudo journalctl -u myp.service -n 50
|
||||
```
|
||||
3. Häufige Ursachen:
|
||||
- Falscher Pfad in myp.service: Überprüfe WorkingDirectory und ExecStart
|
||||
- Python-Umgebung nicht korrekt: Überprüfe, ob die .venv-Umgebung existiert
|
||||
- Abhängigkeiten fehlen: Führe `pip install -r requirements.txt` aus
|
||||
|
||||
### Fehler: "ModuleNotFoundError: No module named X"
|
||||
|
||||
**Problem**: Beim Start der Flask-App wird ein Python-Modul nicht gefunden.
|
||||
|
||||
**Lösung**:
|
||||
1. Aktiviere die virtuelle Umgebung und installiere das fehlende Paket:
|
||||
```bash
|
||||
cd /opt/myp
|
||||
source .venv/bin/activate
|
||||
pip install <fehlende_module>
|
||||
```
|
||||
2. Überprüfe requirements.txt und installiere alle Abhängigkeiten:
|
||||
```bash
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
|
||||
### Fehler: "Address already in use"
|
||||
|
||||
**Problem**: Flask kann nicht starten, weil Port 5000 bereits verwendet wird.
|
||||
|
||||
**Lösung**:
|
||||
1. Finde den Prozess, der Port 5000 verwendet:
|
||||
```bash
|
||||
sudo lsof -i:5000
|
||||
```
|
||||
2. Beende den Prozess:
|
||||
```bash
|
||||
sudo kill <PID>
|
||||
```
|
||||
3. Falls nötig, ändere den Port in app.py:
|
||||
```python
|
||||
app.run(host="0.0.0.0", port=5001, debug=True)
|
||||
```
|
||||
(Und passe auch die URL im kiosk.sh an)
|
||||
|
||||
## Chromium Kiosk-Modus Probleme
|
||||
|
||||
### Fehler: "Chromium startet nicht im Kiosk-Modus"
|
||||
|
||||
**Problem**: Der Browser startet nicht automatisch oder nicht im Vollbildmodus.
|
||||
|
||||
**Lösung**:
|
||||
1. Überprüfe den Status des User-Services:
|
||||
```bash
|
||||
systemctl --user status kiosk.service
|
||||
```
|
||||
2. Führe kiosk.sh manuell aus, um Fehlermeldungen zu sehen:
|
||||
```bash
|
||||
/home/pi/kiosk.sh
|
||||
```
|
||||
3. Prüfe, ob die notwendigen Pakete installiert sind:
|
||||
```bash
|
||||
sudo apt install --reinstall chromium-browser unclutter
|
||||
```
|
||||
|
||||
### Fehler: "Chromium zeigt Fehlerdialoge statt der MYP-Oberfläche"
|
||||
|
||||
**Problem**: Der Browser zeigt Crash-Dialoge oder Warnungen an.
|
||||
|
||||
**Lösung**:
|
||||
1. Lösche die Chromium-Einstellungen und starte neu:
|
||||
```bash
|
||||
rm -rf ~/.config/chromium/
|
||||
```
|
||||
2. Füge zusätzliche Parameter zu chromium-browser in kiosk.sh hinzu:
|
||||
```bash
|
||||
chromium-browser --kiosk --noerrdialogs --disable-infobars --disable-session-crashed-bubble \
|
||||
--disable-features=DialMediaRouteProvider --window-position=0,0 \
|
||||
--app=http://localhost:5000/ &
|
||||
```
|
||||
|
||||
### Fehler: "Chromium öffnet sich, aber zeigt nicht die MYP-Seite"
|
||||
|
||||
**Problem**: Der Browser startet, aber die Anwendung wird nicht angezeigt.
|
||||
|
||||
**Lösung**:
|
||||
1. Überprüfe, ob der Flask-Dienst läuft:
|
||||
```bash
|
||||
systemctl status myp.service
|
||||
```
|
||||
2. Teste, ob die Anwendung im Browser erreichbar ist:
|
||||
```bash
|
||||
curl http://localhost:5000/
|
||||
```
|
||||
3. Prüfe, ob Chromium mit der richtigen URL startet:
|
||||
```bash
|
||||
# In kiosk.sh
|
||||
chromium-browser --kiosk --noerrdialogs --disable-infobars \
|
||||
--window-position=0,0 --app=http://localhost:5000/ &
|
||||
```
|
||||
|
||||
## Watchdog-Probleme
|
||||
|
||||
### Fehler: "Watchdog-Script funktioniert nicht"
|
||||
|
||||
**Problem**: Der Watchdog-Cronjob scheint nicht zu funktionieren.
|
||||
|
||||
**Lösung**:
|
||||
1. Überprüfe, ob der Cron-Job eingerichtet ist:
|
||||
```bash
|
||||
crontab -l
|
||||
```
|
||||
2. Prüfe die Berechtigungen des Watchdog-Scripts:
|
||||
```bash
|
||||
chmod +x /home/pi/watchdog.sh
|
||||
```
|
||||
3. Führe das Script manuell aus und prüfe auf Fehler:
|
||||
```bash
|
||||
/home/pi/watchdog.sh
|
||||
```
|
||||
4. Überprüfe die Logdatei:
|
||||
```bash
|
||||
cat /home/pi/myp-watchdog.log
|
||||
```
|
||||
|
||||
### Fehler: "Watchdog kann systemctl nicht ausführen"
|
||||
|
||||
**Problem**: Der Watchdog kann systemctl-Befehle nicht ausführen.
|
||||
|
||||
**Lösung**:
|
||||
1. Erlaubnis für den pi-Benutzer zum Ausführen von systemctl hinzufügen:
|
||||
```bash
|
||||
echo "pi ALL=NOPASSWD: /bin/systemctl restart myp.service" | sudo tee /etc/sudoers.d/myp-watchdog
|
||||
```
|
||||
|
||||
## Allgemeine Probleme
|
||||
|
||||
### Fehler: "Bildschirm wird nach einiger Zeit schwarz"
|
||||
|
||||
**Problem**: Trotz Konfiguration schaltet sich der Bildschirm nach einiger Zeit aus.
|
||||
|
||||
**Lösung**:
|
||||
1. Stelle sicher, dass die xset-Befehle in kiosk.sh korrekt ausgeführt werden:
|
||||
```bash
|
||||
xset s off
|
||||
xset s noblank
|
||||
xset -dpms
|
||||
```
|
||||
2. Aktualisiere die Autostart-Datei:
|
||||
```bash
|
||||
sudo nano /etc/xdg/lxsession/LXDE-pi/autostart
|
||||
```
|
||||
Füge folgende Zeilen hinzu:
|
||||
```
|
||||
@xset s off
|
||||
@xset -dpms
|
||||
@xset s noblank
|
||||
```
|
||||
3. Verwende ein Tool wie Caffeine:
|
||||
```bash
|
||||
sudo apt install caffeine
|
||||
```
|
||||
|
||||
### Fehler: "System bootet nicht automatisch in den Kiosk-Modus"
|
||||
|
||||
**Problem**: Der automatische Start des Kiosk-Modus funktioniert nicht.
|
||||
|
||||
**Lösung**:
|
||||
1. Überprüfe, ob der automatische Login aktiviert ist:
|
||||
```bash
|
||||
sudo raspi-config
|
||||
# 1 System Options → S5 Boot/Auto Login → B4 Desktop Autologin
|
||||
```
|
||||
2. Stelle sicher, dass der User-Service aktiviert ist:
|
||||
```bash
|
||||
systemctl --user enable kiosk.service
|
||||
```
|
||||
3. Aktiviere Linger für den pi-Benutzer:
|
||||
```bash
|
||||
sudo loginctl enable-linger pi
|
||||
```
|
||||
4. Reboote das System und überprüfe den Status der Dienste:
|
||||
```bash
|
||||
sudo reboot
|
||||
```
|
||||
@@ -1,14 +1,14 @@
|
||||
# Zugangsdaten für MYP-Plattform
|
||||
|
||||
Diese Datei enthält alle Zugangsdaten und Passwörter, die im Projekt verwendet werden. **Diese Datei sollte nie in ein öffentliches Repository hochgeladen werden!**
|
||||
|
||||
## Backend-Zugangsdaten
|
||||
|
||||
zur Übergabe zum Ausbilder
|
||||
|
||||
### Allgemeine Konfiguration
|
||||
- **SECRET_KEY**: `7445630171969DFAC92C53CEC92E67A9CB2E00B3CB2F`
|
||||
- **Kiosk-Deaktivierungspasswort**: `744563017196A`
|
||||
|
||||
### Smart-Steckdosen (TP-Link Tapo)
|
||||
### Einrichtungsdaten der Steckdosen (TP-Link Tapo) - wichtig zur offline API- Authentifizierung
|
||||
- **Benutzername**: `till.tomczak@mercedes-benz.com`
|
||||
- **Passwort**: `744563017196A`
|
||||
|
||||
@@ -16,9 +16,9 @@ Diese Datei enthält alle Zugangsdaten und Passwörter, die im Projekt verwendet
|
||||
- **E-Mail**: `admin@mercedes-benz.com`
|
||||
- **Passwort**: `744563017196A`
|
||||
|
||||
### Drucker-Steckdosen (TP-Link)
|
||||
- **Standard-Benutzername**: `admin`
|
||||
- **Standard-Passwort**: `admin`
|
||||
### Admin Panel - Access Point (Router-Zugang)
|
||||
- **Benutzername**: `admin`
|
||||
- **Passwort**: `vT6Vsd^p`
|
||||
|
||||
## Frontend-Zugangsdaten
|
||||
|
||||
@@ -26,17 +26,7 @@ Diese Datei enthält alle Zugangsdaten und Passwörter, die im Projekt verwendet
|
||||
- **Client ID**: `7c5d8bef1a5519ec1fdc`
|
||||
- **Client Secret**: `5f1e586204358fbd53cf5fb7d418b3f06ccab8fd`
|
||||
|
||||
## Weitere Zugangsdaten
|
||||
|
||||
### Router-Zugang (sofern konfiguriert)
|
||||
- **Benutzername**: `admin`
|
||||
- **Passwort**: `vT6Vsd^p`
|
||||
|
||||
### SSL-Zertifikate
|
||||
- Selbstsignierte Zertifikate werden automatisch für `localhost` generiert
|
||||
- Zertifikatsdateien: `backend/instance/ssl/myp.crt` und `backend/instance/ssl/myp.key`
|
||||
|
||||
## Hinweise
|
||||
- Alle Passwörter sollten in einer Produktionsumgebung geändert werden
|
||||
- Diese Datei dient nur zu Dokumentationszwecken für Entwicklungs- und Testumgebungen
|
||||
- In einer Produktionsumgebung sollten alle Zugangsdaten über sichere Umgebungsvariablen konfiguriert werden
|
||||
@@ -1,351 +0,0 @@
|
||||
# MYP Platform - Raspberry Pi Deployment Guide
|
||||
|
||||
## Übersicht
|
||||
|
||||
Diese Anleitung beschreibt die vollständige Installation und Konfiguration der MYP Platform auf Raspberry Pi Systemen.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
### Hardware
|
||||
- Raspberry Pi 4 (empfohlen) oder Raspberry Pi 3B+
|
||||
- Mindestens 4GB RAM
|
||||
- 32GB+ SD-Karte (Class 10)
|
||||
- Netzwerkverbindung (Ethernet oder WiFi)
|
||||
|
||||
### Software
|
||||
- Raspberry Pi OS (Bullseye oder neuer)
|
||||
- SSH-Zugang aktiviert
|
||||
- Benutzer `user` erstellt
|
||||
|
||||
## Installation
|
||||
|
||||
### 1. Projekt auf Raspberry Pi kopieren
|
||||
|
||||
```bash
|
||||
# Auf dem Entwicklungsrechner
|
||||
scp -r Projektarbeit-MYP user@raspberrypi:/home/user/
|
||||
|
||||
# Oder mit Git
|
||||
ssh user@raspberrypi
|
||||
cd /home/user
|
||||
git clone <repository-url> Projektarbeit-MYP
|
||||
```
|
||||
|
||||
### 2. Setup-Skript ausführen
|
||||
|
||||
```bash
|
||||
ssh user@raspberrypi
|
||||
cd /home/user/Projektarbeit-MYP/backend
|
||||
chmod +x setup_raspberry_pi.sh
|
||||
./setup_raspberry_pi.sh
|
||||
```
|
||||
|
||||
Das Setup-Skript führt automatisch folgende Schritte aus:
|
||||
|
||||
1. **System-Updates**: Aktualisiert alle Pakete
|
||||
2. **Abhängigkeiten**: Installiert Python, Nginx, Supervisor etc.
|
||||
3. **Virtual Environment**: Erstellt isolierte Python-Umgebung
|
||||
4. **Python-Pakete**: Installiert alle Requirements
|
||||
5. **Verzeichnisse**: Erstellt notwendige Ordnerstruktur
|
||||
6. **Datenbank**: Initialisiert SQLite-Datenbank
|
||||
7. **SSL-Zertifikate**: Generiert selbstsignierte Zertifikate
|
||||
8. **Services**: Konfiguriert Systemd, Nginx, Supervisor
|
||||
9. **Firewall**: Öffnet notwendige Ports
|
||||
10. **Drucker**: Trägt hardkodierte Drucker in DB ein
|
||||
|
||||
### 3. Manuelle Drucker-Konfiguration (optional)
|
||||
|
||||
Falls die Drucker separat konfiguriert werden sollen:
|
||||
|
||||
```bash
|
||||
cd /home/user/Projektarbeit-MYP/backend/app
|
||||
source ../venv/bin/activate
|
||||
python setup_drucker_db.py
|
||||
```
|
||||
|
||||
## Konfiguration
|
||||
|
||||
### Pfadstruktur
|
||||
|
||||
```
|
||||
/home/user/Projektarbeit-MYP/
|
||||
├── backend/
|
||||
│ ├── app/
|
||||
│ │ ├── database/
|
||||
│ │ │ └── myp.db
|
||||
│ │ ├── logs/
|
||||
│ │ │ ├── app/
|
||||
│ │ │ ├── auth/
|
||||
│ │ │ ├── jobs/
|
||||
│ │ │ ├── printers/
|
||||
│ │ │ ├── scheduler/
|
||||
│ │ │ └── errors/
|
||||
│ │ └── ...
|
||||
│ ├── certs/
|
||||
│ │ ├── myp.crt
|
||||
│ │ └── myp.key
|
||||
│ ├── venv/
|
||||
│ └── requirements.txt
|
||||
└── frontend/
|
||||
└── ssl/
|
||||
├── myp.crt
|
||||
└── myp.key
|
||||
```
|
||||
|
||||
### Hardkodierte Drucker
|
||||
|
||||
Die folgenden Drucker werden automatisch konfiguriert:
|
||||
|
||||
| Name | IP-Adresse | Status |
|
||||
|------|------------|--------|
|
||||
| Printer 1 | 192.168.0.100 | Available |
|
||||
| Printer 2 | 192.168.0.101 | Available |
|
||||
| Printer 3 | 192.168.0.102 | Available |
|
||||
| Printer 4 | 192.168.0.103 | Available |
|
||||
| Printer 5 | 192.168.0.104 | Available |
|
||||
| Printer 6 | 192.168.0.106 | Available |
|
||||
|
||||
### Standard-Anmeldedaten
|
||||
|
||||
- **E-Mail**: admin@mercedes-benz.com
|
||||
- **Passwort**: 744563017196A
|
||||
|
||||
## Services
|
||||
|
||||
### Systemd Service
|
||||
|
||||
```bash
|
||||
# Service-Status prüfen
|
||||
sudo systemctl status myp-platform
|
||||
|
||||
# Service neu starten
|
||||
sudo systemctl restart myp-platform
|
||||
|
||||
# Service aktivieren/deaktivieren
|
||||
sudo systemctl enable myp-platform
|
||||
sudo systemctl disable myp-platform
|
||||
|
||||
# Logs anzeigen
|
||||
sudo journalctl -u myp-platform -f
|
||||
```
|
||||
|
||||
### Nginx
|
||||
|
||||
```bash
|
||||
# Nginx-Status prüfen
|
||||
sudo systemctl status nginx
|
||||
|
||||
# Konfiguration testen
|
||||
sudo nginx -t
|
||||
|
||||
# Nginx neu laden
|
||||
sudo systemctl reload nginx
|
||||
```
|
||||
|
||||
### Supervisor
|
||||
|
||||
```bash
|
||||
# Supervisor-Status
|
||||
sudo supervisorctl status
|
||||
|
||||
# Service neu starten
|
||||
sudo supervisorctl restart myp-platform
|
||||
|
||||
# Logs anzeigen
|
||||
sudo supervisorctl tail -f myp-platform
|
||||
```
|
||||
|
||||
## Zugriff
|
||||
|
||||
### URLs
|
||||
|
||||
- **HTTPS**: https://raspberrypi
|
||||
- **HTTPS (IP)**: https://[IP-ADRESSE]
|
||||
- **HTTP**: Automatische Weiterleitung zu HTTPS
|
||||
|
||||
### SSL-Zertifikat
|
||||
|
||||
Das System verwendet selbstsignierte SSL-Zertifikate:
|
||||
|
||||
- Browser-Warnung beim ersten Zugriff ist normal
|
||||
- Zertifikat manuell akzeptieren
|
||||
- Für Produktionsumgebung: Echte Zertifikate verwenden
|
||||
|
||||
## Wartung
|
||||
|
||||
### Logs
|
||||
|
||||
```bash
|
||||
# Anwendungs-Logs
|
||||
tail -f /home/user/Projektarbeit-MYP/backend/app/logs/app/app.log
|
||||
|
||||
# System-Logs
|
||||
sudo journalctl -u myp-platform -f
|
||||
|
||||
# Nginx-Logs
|
||||
sudo tail -f /var/log/nginx/access.log
|
||||
sudo tail -f /var/log/nginx/error.log
|
||||
```
|
||||
|
||||
### Datenbank-Backup
|
||||
|
||||
```bash
|
||||
# Backup erstellen
|
||||
cp /home/user/Projektarbeit-MYP/backend/app/database/myp.db \
|
||||
/home/user/backup_$(date +%Y%m%d_%H%M%S).db
|
||||
|
||||
# Automatisches Backup (Crontab)
|
||||
crontab -e
|
||||
# Hinzufügen:
|
||||
# 0 2 * * * cp /home/user/Projektarbeit-MYP/backend/app/database/myp.db /home/user/backup_$(date +\%Y\%m\%d).db
|
||||
```
|
||||
|
||||
### Updates
|
||||
|
||||
```bash
|
||||
# Code aktualisieren
|
||||
cd /home/user/Projektarbeit-MYP
|
||||
git pull
|
||||
|
||||
# Python-Abhängigkeiten aktualisieren
|
||||
source backend/venv/bin/activate
|
||||
pip install -r backend/requirements.txt
|
||||
|
||||
# Service neu starten
|
||||
sudo systemctl restart myp-platform
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Häufige Probleme
|
||||
|
||||
#### Service startet nicht
|
||||
|
||||
```bash
|
||||
# Logs prüfen
|
||||
sudo journalctl -u myp-platform -n 50
|
||||
|
||||
# Manuell starten (Debug)
|
||||
cd /home/user/Projektarbeit-MYP/backend/app
|
||||
source ../venv/bin/activate
|
||||
python app.py
|
||||
```
|
||||
|
||||
#### SSL-Probleme
|
||||
|
||||
```bash
|
||||
# Zertifikate neu generieren
|
||||
cd /home/user/Projektarbeit-MYP/backend/app
|
||||
source ../venv/bin/activate
|
||||
python -c "from utils.ssl_manager import ssl_manager; ssl_manager.generate_mercedes_certificate()"
|
||||
|
||||
# Nginx neu starten
|
||||
sudo systemctl restart nginx
|
||||
```
|
||||
|
||||
#### Datenbank-Probleme
|
||||
|
||||
```bash
|
||||
# Datenbank neu initialisieren
|
||||
cd /home/user/Projektarbeit-MYP/backend/app
|
||||
source ../venv/bin/activate
|
||||
python -c "from models import init_database, create_initial_admin; init_database(); create_initial_admin()"
|
||||
|
||||
# Drucker neu einrichten
|
||||
python setup_drucker_db.py
|
||||
```
|
||||
|
||||
#### Port-Konflikte
|
||||
|
||||
```bash
|
||||
# Verwendete Ports prüfen
|
||||
sudo netstat -tlnp | grep :443
|
||||
sudo netstat -tlnp | grep :80
|
||||
|
||||
# Prozesse beenden
|
||||
sudo pkill -f "python app.py"
|
||||
```
|
||||
|
||||
### Performance-Optimierung
|
||||
|
||||
#### Systemressourcen
|
||||
|
||||
```bash
|
||||
# RAM-Nutzung prüfen
|
||||
free -h
|
||||
|
||||
# CPU-Nutzung prüfen
|
||||
htop
|
||||
|
||||
# Festplatte prüfen
|
||||
df -h
|
||||
```
|
||||
|
||||
#### Log-Rotation
|
||||
|
||||
```bash
|
||||
# Logrotate konfigurieren
|
||||
sudo tee /etc/logrotate.d/myp-platform > /dev/null <<EOF
|
||||
/home/user/Projektarbeit-MYP/backend/app/logs/*/*.log {
|
||||
daily
|
||||
missingok
|
||||
rotate 7
|
||||
compress
|
||||
delaycompress
|
||||
notifempty
|
||||
copytruncate
|
||||
}
|
||||
EOF
|
||||
```
|
||||
|
||||
## Sicherheit
|
||||
|
||||
### Firewall
|
||||
|
||||
```bash
|
||||
# UFW-Status prüfen
|
||||
sudo ufw status
|
||||
|
||||
# Zusätzliche Regeln
|
||||
sudo ufw allow from 192.168.0.0/24 to any port 22
|
||||
sudo ufw deny 22
|
||||
```
|
||||
|
||||
### SSL-Härtung
|
||||
|
||||
Für Produktionsumgebung:
|
||||
|
||||
1. Echte SSL-Zertifikate verwenden (Let's Encrypt)
|
||||
2. HSTS aktivieren
|
||||
3. Security Headers konfigurieren
|
||||
4. Regelmäßige Updates
|
||||
|
||||
### Backup-Strategie
|
||||
|
||||
1. Tägliche Datenbank-Backups
|
||||
2. Wöchentliche Vollbackups
|
||||
3. Externe Speicherung
|
||||
4. Restore-Tests
|
||||
|
||||
## Support
|
||||
|
||||
### Kontakt
|
||||
|
||||
- **E-Mail**: admin@mercedes-benz.com
|
||||
- **Dokumentation**: /home/user/Projektarbeit-MYP/docs/
|
||||
|
||||
### Nützliche Befehle
|
||||
|
||||
```bash
|
||||
# System-Informationen
|
||||
hostnamectl
|
||||
cat /etc/os-release
|
||||
python3 --version
|
||||
|
||||
# Netzwerk-Informationen
|
||||
ip addr show
|
||||
hostname -I
|
||||
|
||||
# Service-Übersicht
|
||||
systemctl list-units --type=service --state=running
|
||||
```
|
||||
@@ -1,32 +0,0 @@
|
||||
|
||||
Notizen:
|
||||
- Wollten zuerst OpenSUSE, haben uns dagegen entschieden, weil NixOS einfacher zu konfigurieren ist und besser geeignet für diesen Einsatzzweck
|
||||
- Mussten eine IP-Adresse und eine Domain organisieren von unserer IT-Abteilung
|
||||
- haben ein Netzwerkplan gemacht
|
||||
- haben uns die akutellen Prozesse und Konventionen bei der Organisation einer internen Domain angeguckt
|
||||
- haben uns für Raspberrys "entschieden", stand aber mehr oder weniger schon fest weil diese einfach perfekt für den Einsatzzweck sind
|
||||
- Da Till digitale Vernetzung hat macht er Backend, weil die Schnittstelle der Vernetzung zum cyberphysischen System dort lag
|
||||
- für die Dokumentation: Daten (Datums) müssen stimmen!
|
||||
|
||||
python schnittstelle funktionierte nicht
|
||||
nach etlichem rumprobieren festgestellt: geht nicht so einfach
|
||||
wireshark mitschnitt gemacht → auffällig: immer die selben responses bei verschlüsselter verbindung
|
||||
ohne erfolg beim simulieren einzelner anfragen
|
||||
dann: geistesblitz: anfragensequenz muss es sein!
|
||||
hat funktioniert → es hat klick gemacht!! .
|
||||
verbindung verschlüsselt und mit temporärem cookie
|
||||
→ proprietäre Verschlüsselung
|
||||
wie wird die verbindung ausgehandelt?
|
||||
|
||||
------
|
||||
|
||||
11.09 : Teile bestellt im internen Technikshop
|
||||
12.09 : DNS Alias festlegen / beantragen
|
||||
|
||||
- kiosk modus installieren -> testen in virtual box -> mercedes root ca zertifikate installieren
|
||||
-> shell skript erstellen zur installation, service datei erstellen für systemd
|
||||
-> openbox als desktop environment, chromium im kiosk modus
|
||||
-> 3 instanzen starten automatisch: eine 443, eine 80 als fallback -> api ; + eine instanz auf 5000 für kiosk modus auf localhost
|
||||
-> zertifikate werden selbst erstellt für https
|
||||
|
||||
-> firewalld als firewall service
|
||||
@@ -1,73 +0,0 @@
|
||||
# MYP IHK-Abgabe Finale Checkliste
|
||||
|
||||
**Abgabetermin: 5. Juni 2025**
|
||||
**Status: System produktionsreif - Dokumentation vervollständigen**
|
||||
|
||||
## ✅ **BEREITS FERTIG**
|
||||
|
||||
### Backend-System (Till Tomczak)
|
||||
|
||||
- ✅ **9.146 Zeilen** Flask-Backend vollständig implementiert
|
||||
- ✅ **Smart-Plug-Integration** (TP-Link Tapo P110) funktionsfähig
|
||||
- ✅ **100+ REST-API-Endpunkte** dokumentiert und getestet
|
||||
- ✅ **SQLite-Datenbank** mit 8 Tabellen optimiert
|
||||
- ✅ **Offline-Betrieb** konfiguriert und validiert
|
||||
- ✅ **Raspberry Pi Integration** mit Kiosk-Modus
|
||||
- ✅ **Umfangreiches Logging** und Monitoring implementiert
|
||||
- ✅ **Produktionsreife Sicherheitsfeatures**
|
||||
|
||||
### Frontend-System (Torben Haack)
|
||||
|
||||
- ✅ **Next.js 14** PWA funktionsfähig
|
||||
- ✅ **Analytics Dashboard** mit Recharts
|
||||
- ✅ **Responsive Design** implementiert
|
||||
- ✅ **Backend-API-Integration** vollständig
|
||||
|
||||
## 🚀 **FINALE SCHRITTE (1-2 Tage)**
|
||||
|
||||
### 1. IHK-Dokumentation finalisieren
|
||||
|
||||
- ✅ **Kapitel 3.1-3.3** technisch erweitert (gerade erledigt)
|
||||
- ⏳ **Kapitel 4** (Projektabschluss) ausführlicher gestalten
|
||||
- ⏳ **Technische Diagramme** hinzufügen
|
||||
- ⏳ **Code-Beispiele** für zentrale Funktionen
|
||||
- ⏳ **Performance-Metriken** dokumentieren
|
||||
|
||||
### 2. Projektpräsentation vorbereiten
|
||||
|
||||
- ⏳ **Live-Demo** des Systems vorbereiten
|
||||
- ⏳ **Powerpoint-Präsentation** (15-20 Folien)
|
||||
- ⏳ **Vorführung** der Smart-Plug-Steuerung
|
||||
- ⏳ **Kiosk-Modus** Demonstration
|
||||
|
||||
### 3. Finale Tests und Validierung
|
||||
|
||||
- ⏳ **Kompletter System-Test** auf Raspberry Pi
|
||||
- ⏳ **Alle API-Endpunkte** final validieren
|
||||
- ⏳ **Offline-Funktionalität** bestätigen
|
||||
- ⏳ **Backup der finalen Version** erstellen
|
||||
|
||||
## 📊 **IMPRESSIONEN FÜR IHK-PRÜFER**
|
||||
|
||||
### Technische Highlights
|
||||
|
||||
- **Cyber-physische Vernetzung**: Direkte IT-Hardware-Integration
|
||||
- **Produktionsreife Architektur**: 11.000+ Zeilen professioneller Code
|
||||
- **Offline-fähiges System**: Keine Internet-Abhängigkeiten
|
||||
- **Smart-Plug-Automatisierung**: Zeitgesteuerte Hardwaresteuerung
|
||||
- **Raspberry Pi Deployment**: Eingebettete Systeme Integration
|
||||
|
||||
### Geschäftlicher Nutzen
|
||||
|
||||
- **100% Automatisierung** des Reservierungsprozesses
|
||||
- **Energieoptimierung** durch bedarfsgerechte Schaltung
|
||||
- **Konfliktfreie Ressourcennutzung** in der Ausbildung
|
||||
- **Nachvollziehbare Nutzungsstatistiken**
|
||||
|
||||
## 🎯 **NÄCHSTE 48 STUNDEN**
|
||||
|
||||
1. **Heute**: Dokumentation Kapitel 4 vervollständigen
|
||||
2. **Morgen**: Präsentation erstellen und System final testen
|
||||
3. **Übermorgen**: Abgabevorbereitung und letzte Kontrollen
|
||||
|
||||
**STATUS: 95% FERTIG - HERVORRAGENDES IHK-PROJEKT!**
|
||||
@@ -1,168 +0,0 @@
|
||||
# Frontend-API-Konfiguration für separates Backend
|
||||
|
||||
## Übersicht
|
||||
|
||||
Das Frontend wurde konfiguriert, um mit einem Backend auf einem separaten Server unter `https://192.168.0.105:443` zu kommunizieren.
|
||||
|
||||
## Durchgeführte Änderungen
|
||||
|
||||
### 1. API-Basis-URL-Konfiguration (`frontend/src/utils/api-config.ts`)
|
||||
|
||||
**Primäre Backend-URL**: `https://192.168.0.105:443`
|
||||
|
||||
**Fallback-URLs**:
|
||||
- `https://192.168.0.105` (ohne expliziten Port)
|
||||
- `https://raspberrypi` (lokaler Raspberry Pi Fallback)
|
||||
|
||||
### 2. SSL-Zertifikat-Handling
|
||||
|
||||
- Selbstsignierte Zertifikate werden automatisch akzeptiert
|
||||
- `NODE_TLS_REJECT_UNAUTHORIZED = '0'` für Development
|
||||
|
||||
### 3. API-Endpunkt-Konfiguration
|
||||
|
||||
Alle API-Endpunkte wurden angepasst:
|
||||
|
||||
```typescript
|
||||
export const API_ENDPOINTS = {
|
||||
PRINTERS: 'https://192.168.0.105:443/api/printers',
|
||||
JOBS: 'https://192.168.0.105:443/api/jobs',
|
||||
USERS: 'https://192.168.0.105:443/api/users',
|
||||
HEALTH: 'https://192.168.0.105:443/health',
|
||||
AUTH: {
|
||||
LOGIN: 'https://192.168.0.105:443/api/auth/login',
|
||||
CALLBACK: 'https://192.168.0.105:443/api/auth/callback',
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
### 4. Fallback-Mechanismus
|
||||
|
||||
Das Frontend verfügt über einen robusten Fallback-Mechanismus:
|
||||
|
||||
1. **Primäre Verbindung**: `https://192.168.0.105:443`
|
||||
2. **Fallback 1**: `https://192.168.0.105` (Port 443 automatisch)
|
||||
3. **Fallback 2**: `https://raspberrypi` (lokaler Pi)
|
||||
|
||||
### 5. Health Check Integration
|
||||
|
||||
Der Health Check wurde angepasst, um die Backend-Konnektivität zu überwachen:
|
||||
|
||||
```typescript
|
||||
// Health Check prüft Backend unter https://192.168.0.105:443/health
|
||||
const backendStatus = await fetch(`${backendUrl}/health`);
|
||||
```
|
||||
|
||||
## Environment-Variablen (optional)
|
||||
|
||||
Falls gewünscht, kann die Backend-URL über Environment-Variablen überschrieben werden:
|
||||
|
||||
```bash
|
||||
# .env.local
|
||||
NEXT_PUBLIC_API_URL=https://192.168.0.105:443
|
||||
NODE_TLS_REJECT_UNAUTHORIZED=0
|
||||
```
|
||||
|
||||
## Netzwerk-Konfiguration
|
||||
|
||||
### Backend-Server-Anforderungen
|
||||
|
||||
1. **HTTPS aktiviert** auf Port 443
|
||||
2. **CORS konfiguriert** für Frontend-Domain
|
||||
3. **SSL-Zertifikat** (selbstsigniert oder gültig)
|
||||
4. **API-Endpunkte** verfügbar unter `/api/*`
|
||||
5. **Health Check** verfügbar unter `/health`
|
||||
|
||||
### Firewall-Regeln
|
||||
|
||||
```bash
|
||||
# Backend-Server (192.168.0.105)
|
||||
sudo ufw allow 443/tcp
|
||||
sudo ufw allow from 192.168.0.0/24 to any port 443
|
||||
```
|
||||
|
||||
## Entwicklung und Testing
|
||||
|
||||
### Backend-Verbindung testen
|
||||
|
||||
```bash
|
||||
# SSL-Verbindung testen
|
||||
curl -k https://192.168.0.105:443/health
|
||||
|
||||
# API-Endpunkte testen
|
||||
curl -k https://192.168.0.105:443/api/printers
|
||||
curl -k https://192.168.0.105:443/api/jobs
|
||||
```
|
||||
|
||||
### Frontend-Server starten
|
||||
|
||||
```bash
|
||||
cd frontend
|
||||
pnpm install
|
||||
pnpm dev
|
||||
```
|
||||
|
||||
Das Frontend läuft auf `http://localhost:3000` und verbindet sich automatisch mit dem Backend unter `https://192.168.0.105:443`.
|
||||
|
||||
## Fehlerbehebung
|
||||
|
||||
### SSL-Zertifikat-Probleme
|
||||
|
||||
Falls SSL-Zertifikat-Fehler auftreten:
|
||||
|
||||
1. **Browser**: Besuche `https://192.168.0.105:443` und akzeptiere das Zertifikat manuell
|
||||
2. **curl**: Verwende `-k` Flag für unsichere Verbindungen
|
||||
3. **fetch**: `NODE_TLS_REJECT_UNAUTHORIZED=0` ist bereits gesetzt
|
||||
|
||||
### Verbindungsprobleme
|
||||
|
||||
1. **Netzwerk**: Prüfe ob `192.168.0.105` erreichbar ist
|
||||
2. **Port**: Stelle sicher, dass Port 443 geöffnet ist
|
||||
3. **Backend**: Prüfe ob Backend-Service läuft
|
||||
4. **Logs**: Prüfe Browser-Konsole und Backend-Logs
|
||||
|
||||
### Fallback-Testing
|
||||
|
||||
Das Frontend versucht automatisch Fallback-URLs:
|
||||
|
||||
```javascript
|
||||
// In Browser-Konsole testen
|
||||
console.log('API_BASE_URL:', API_BASE_URL);
|
||||
fetch('/api/health').then(r => r.json()).then(console.log);
|
||||
```
|
||||
|
||||
## Produktions-Deployment
|
||||
|
||||
### Umgebungsspezifische Konfiguration
|
||||
|
||||
```bash
|
||||
# Production
|
||||
NEXT_PUBLIC_API_URL=https://192.168.0.105:443
|
||||
|
||||
# Staging
|
||||
NEXT_PUBLIC_API_URL=https://staging-backend:443
|
||||
|
||||
# Development
|
||||
NEXT_PUBLIC_API_URL=https://localhost:5000
|
||||
```
|
||||
|
||||
### Docker-Deployment
|
||||
|
||||
```yaml
|
||||
# docker-compose.yml
|
||||
services:
|
||||
frontend:
|
||||
build: ./frontend
|
||||
environment:
|
||||
- NEXT_PUBLIC_API_URL=https://192.168.0.105:443
|
||||
ports:
|
||||
- "3000:3000"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Status**: ✅ Konfiguration abgeschlossen
|
||||
**Backend-URL**: `https://192.168.0.105:443`
|
||||
**Fallback-Support**: Aktiviert
|
||||
**SSL-Handling**: Selbstsignierte Zertifikate akzeptiert
|
||||
**Getestet**: Bereit für Integration
|
||||
@@ -1,382 +0,0 @@
|
||||
# MYP Frontend - Installationsanleitung
|
||||
|
||||
## Übersicht
|
||||
|
||||
Das MYP Frontend ist eine Next.js-Anwendung, die mit Docker und Caddy als Reverse Proxy betrieben wird. Das konsolidierte Setup-Skript automatisiert die komplette Installation und Konfiguration.
|
||||
|
||||
## Systemanforderungen
|
||||
|
||||
- **Betriebssystem**: Debian/Raspbian (Raspberry Pi OS)
|
||||
- **Hardware**: Raspberry Pi 4 oder höher (empfohlen)
|
||||
- **RAM**: Mindestens 2GB
|
||||
- **Speicher**: Mindestens 8GB freier Speicherplatz
|
||||
- **Netzwerk**: Internetverbindung für Installation
|
||||
|
||||
## Schnellstart
|
||||
|
||||
### Automatische Installation
|
||||
|
||||
```bash
|
||||
# Als Root ausführen
|
||||
sudo bash frontend/setup.sh
|
||||
```
|
||||
|
||||
Das Skript bietet ein interaktives Menü mit folgenden Optionen:
|
||||
|
||||
1. **Vollständige Frontend-Installation** - Komplette Neuinstallation
|
||||
2. **SSL-Zertifikate neu generieren** - Erneuert nur die Zertifikate
|
||||
3. **Service-Status prüfen** - Diagnose und Monitoring
|
||||
4. **Beenden** - Script verlassen
|
||||
|
||||
## Detaillierte Installationsschritte
|
||||
|
||||
### 1. System-Vorbereitung
|
||||
|
||||
Das Skript führt automatisch folgende Schritte durch:
|
||||
|
||||
- **System-Update**: Paketlisten aktualisieren
|
||||
- **Grundtools installieren**: curl, wget, git, openssl, etc.
|
||||
- **Internetverbindung prüfen**: Verfügbarkeit der benötigten Ressourcen
|
||||
|
||||
### 2. Docker-Installation
|
||||
|
||||
- **Docker CE**: Container-Runtime
|
||||
- **Docker Compose**: Multi-Container-Orchestrierung
|
||||
- **Service-Aktivierung**: Automatischer Start beim Boot
|
||||
|
||||
### 3. SSL-Zertifikate (Mercedes)
|
||||
|
||||
Das Skript erstellt selbstsignierte SSL-Zertifikate mit folgenden Eigenschaften:
|
||||
|
||||
**Zertifikat-Details:**
|
||||
|
||||
- **Organisation**: Mercedes-Benz AG
|
||||
- **Abteilung**: IT-Abteilung
|
||||
- **Standort**: Stuttgart, Baden-Württemberg, Deutschland
|
||||
- **Primäre Domain**: `m040tbaraspi001.de040.corpintra.net`
|
||||
|
||||
**Subject Alternative Names (SAN):**
|
||||
|
||||
- `m040tbaraspi001.de040.corpintra.net`
|
||||
- `m040tbaraspi001`
|
||||
- `localhost`
|
||||
- `raspberrypi`
|
||||
- `127.0.0.1`
|
||||
- `192.168.0.109`
|
||||
|
||||
**Speicherorte:**
|
||||
|
||||
- Zertifikat: `/etc/ssl/certs/myp/frontend.crt`
|
||||
- Privater Schlüssel: `/etc/ssl/certs/myp/frontend.key`
|
||||
- System-CA-Store: `/usr/local/share/ca-certificates/`
|
||||
|
||||
### 4. Frontend-Deployment
|
||||
|
||||
- **Zielverzeichnis**: `/opt/myp-frontend`
|
||||
- **Dateisynchronisation**: Exclude node_modules, .git, ssl
|
||||
- **Berechtigungen**: Root-Ownership mit korrekten Permissions
|
||||
|
||||
### 5. Docker Compose Konfiguration
|
||||
|
||||
**Services:**
|
||||
|
||||
1. **frontend-app**
|
||||
|
||||
- Build: Next.js Application
|
||||
- Port: 3000 (intern)
|
||||
- Environment: Production
|
||||
- Health Check: `/health` Endpoint
|
||||
2. **caddy**
|
||||
|
||||
- Image: caddy:latest
|
||||
- Ports: 80 (HTTP), 443 (HTTPS)
|
||||
- SSL-Termination und Reverse Proxy
|
||||
- Security Headers und Compression
|
||||
3. **db**
|
||||
|
||||
- SQLite-Container mit persistenten Volumes
|
||||
- Datenverzeichnis: `/data`
|
||||
|
||||
**Volumes:**
|
||||
|
||||
- `caddy_data`: Caddy-Daten persistent
|
||||
- `caddy_config`: Caddy-Konfiguration
|
||||
- `db_data`: Datenbank-Dateien
|
||||
|
||||
### 6. Systemd-Service
|
||||
|
||||
**Service-Name**: `myp-frontend.service`
|
||||
|
||||
**Eigenschaften:**
|
||||
|
||||
- **Auto-Start**: Beim Boot aktiviert
|
||||
- **Dependencies**: Startet nach Docker
|
||||
- **Management**: Standard systemctl-Befehle
|
||||
- **Logging**: Journald-Integration
|
||||
- **Sicherheit**: Sandboxed mit eingeschränkten Berechtigungen
|
||||
|
||||
### 7. Firewall-Konfiguration
|
||||
|
||||
**UFW-Regeln:**
|
||||
|
||||
- **SSH**: Port 22 (Remote-Zugang)
|
||||
- **HTTP**: Port 80 (Redirect zu HTTPS)
|
||||
- **HTTPS**: Port 443 (Hauptzugang)
|
||||
- **Lokale Verbindungen**: 127.0.0.1, ::1
|
||||
- **Mercedes-Netzwerke**: 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12
|
||||
|
||||
## Zugang zur Anwendung
|
||||
|
||||
Nach erfolgreicher Installation ist das Frontend verfügbar unter:
|
||||
|
||||
- **Primär**: https://m040tbaraspi001.de040.corpintra.net
|
||||
- **Lokal**: https://localhost
|
||||
- **IP-Direkt**: https://192.168.0.109
|
||||
|
||||
## Service-Management
|
||||
|
||||
### Status prüfen
|
||||
|
||||
```bash
|
||||
# Systemd Service Status
|
||||
sudo systemctl status myp-frontend
|
||||
|
||||
# Docker Container Status
|
||||
cd /opt/myp-frontend
|
||||
sudo docker compose ps
|
||||
|
||||
# Live-Logs anzeigen
|
||||
sudo docker compose logs -f
|
||||
```
|
||||
|
||||
### Service-Kontrolle
|
||||
|
||||
```bash
|
||||
# Service starten
|
||||
sudo systemctl start myp-frontend
|
||||
|
||||
# Service stoppen
|
||||
sudo systemctl stop myp-frontend
|
||||
|
||||
# Service neustarten
|
||||
sudo systemctl restart myp-frontend
|
||||
|
||||
# Service deaktivieren
|
||||
sudo systemctl disable myp-frontend
|
||||
```
|
||||
|
||||
### Container-Management
|
||||
|
||||
```bash
|
||||
# Alle Container neustarten
|
||||
cd /opt/myp-frontend
|
||||
sudo docker compose restart
|
||||
|
||||
# Einzelnen Container neustarten
|
||||
sudo docker compose restart caddy
|
||||
sudo docker compose restart frontend-app
|
||||
|
||||
# Container-Logs einzeln
|
||||
sudo docker compose logs caddy
|
||||
sudo docker compose logs frontend-app
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Häufige Probleme
|
||||
|
||||
#### 1. Frontend nicht erreichbar
|
||||
|
||||
**Diagnose:**
|
||||
|
||||
```bash
|
||||
# Service-Status prüfen
|
||||
sudo systemctl status myp-frontend
|
||||
|
||||
# Container-Status prüfen
|
||||
cd /opt/myp-frontend
|
||||
sudo docker compose ps
|
||||
|
||||
# Netzwerk-Test
|
||||
curl -k -I https://localhost/health
|
||||
```
|
||||
|
||||
**Lösungsansätze:**
|
||||
|
||||
- Container neu starten: `sudo docker compose restart`
|
||||
- Service neu starten: `sudo systemctl restart myp-frontend`
|
||||
- Logs prüfen: `sudo docker compose logs`
|
||||
|
||||
#### 2. SSL-Zertifikat-Probleme
|
||||
|
||||
**Diagnose:**
|
||||
|
||||
```bash
|
||||
# Zertifikat-Gültigkeit prüfen
|
||||
openssl x509 -in /etc/ssl/certs/myp/frontend.crt -noout -dates
|
||||
|
||||
# SSL-Verbindung testen
|
||||
openssl s_client -connect localhost:443 -servername m040tbaraspi001.de040.corpintra.net
|
||||
```
|
||||
|
||||
**Lösung:**
|
||||
|
||||
```bash
|
||||
# Zertifikate neu generieren
|
||||
sudo bash frontend/setup.sh
|
||||
# Dann Option 2 wählen (SSL-Zertifikate neu generieren)
|
||||
```
|
||||
|
||||
#### 3. Docker-Build Fehler
|
||||
|
||||
**Diagnose:**
|
||||
|
||||
```bash
|
||||
# Build-Logs prüfen
|
||||
cd /opt/myp-frontend
|
||||
sudo docker compose build --no-cache
|
||||
|
||||
# Speicherplatz prüfen
|
||||
df -h
|
||||
```
|
||||
|
||||
**Lösungsansätze:**
|
||||
|
||||
- Docker aufräumen: `sudo docker system prune -a`
|
||||
- Neuinstallation: Frontend-Verzeichnis löschen und setup.sh erneut ausführen
|
||||
|
||||
#### 4. Port-Konflikte
|
||||
|
||||
**Diagnose:**
|
||||
|
||||
```bash
|
||||
# Port-Belegung prüfen
|
||||
sudo netstat -tlnp | grep -E ':(80|443)'
|
||||
sudo ss -tlnp | grep -E ':(80|443)'
|
||||
```
|
||||
|
||||
**Lösung:**
|
||||
|
||||
- Konflikt-Services stoppen
|
||||
- UFW-Regeln prüfen: `sudo ufw status`
|
||||
|
||||
### Log-Dateien
|
||||
|
||||
**Installation:**
|
||||
|
||||
- `/var/log/myp-frontend-install.log`
|
||||
|
||||
**Caddy:**
|
||||
|
||||
- `/var/log/caddy/access.log`
|
||||
- `/var/log/caddy/error.log`
|
||||
|
||||
**Docker:**
|
||||
|
||||
```bash
|
||||
# Container-Logs
|
||||
sudo docker compose logs frontend-app
|
||||
sudo docker compose logs caddy
|
||||
|
||||
# Systemd-Journal
|
||||
sudo journalctl -u myp-frontend -f
|
||||
```
|
||||
|
||||
## Sicherheitshinweise
|
||||
|
||||
### SSL/TLS
|
||||
|
||||
- Selbstsignierte Zertifikate erfordern Ausnahmen im Browser
|
||||
- Für Produktion sollten CA-signierte Zertifikate verwendet werden
|
||||
- Automatische HTTP-zu-HTTPS-Weiterleitung ist aktiviert
|
||||
|
||||
### Firewall
|
||||
|
||||
- Restriktive Einstellungen - nur notwendige Ports geöffnet
|
||||
- Mercedes-interne Netzwerke sind zugelassen
|
||||
- Externe Zugriffe werden standardmäßig blockiert
|
||||
|
||||
### Container-Sicherheit
|
||||
|
||||
- Container laufen mit minimalen Berechtigungen
|
||||
- Sensitive Dateien sind read-only gemountet
|
||||
- Netzwerk-Isolation zwischen Containern
|
||||
|
||||
## Backup und Wartung
|
||||
|
||||
### Backup wichtiger Dateien
|
||||
|
||||
```bash
|
||||
# SSL-Zertifikate
|
||||
sudo cp -r /etc/ssl/certs/myp /backup/ssl-certificates-$(date +%Y%m%d)
|
||||
|
||||
# Anwendungsdaten
|
||||
sudo cp -r /opt/myp-frontend /backup/frontend-$(date +%Y%m%d)
|
||||
|
||||
# Docker Volumes
|
||||
sudo docker run --rm -v myp-frontend_db_data:/data -v /backup:/backup alpine \
|
||||
tar czf /backup/db-data-$(date +%Y%m%d).tar.gz -C /data .
|
||||
```
|
||||
|
||||
### Regelmäßige Wartung
|
||||
|
||||
```bash
|
||||
# Docker-System aufräumen (monatlich)
|
||||
sudo docker system prune -f
|
||||
|
||||
# Log-Dateien rotieren (wöchentlich)
|
||||
sudo logrotate -f /etc/logrotate.conf
|
||||
|
||||
# SSL-Zertifikat-Ablauf prüfen (monatlich)
|
||||
openssl x509 -in /etc/ssl/certs/myp/frontend.crt -noout -dates
|
||||
```
|
||||
|
||||
## Performance-Optimierung
|
||||
|
||||
### Raspberry Pi spezifisch
|
||||
|
||||
- **Memory Swappiness**: Reduziert auf 10
|
||||
- **I/O Scheduler**: Optimiert für SD-Karten
|
||||
- **CPU Scheduling**: Verbesserte Interaktivität
|
||||
- **Caching**: Effiziente Nutzung des verfügbaren RAMs
|
||||
|
||||
### Container-Optimierung
|
||||
|
||||
- **Multi-Stage Builds**: Reduzierte Image-Größen
|
||||
- **Health Checks**: Automatische Fehlerbehandlung
|
||||
- **Resource Limits**: Verhindert Memory-Leaks
|
||||
- **Restart Policies**: Automatische Wiederherstellung
|
||||
|
||||
## Support und Weiterentwicklung
|
||||
|
||||
### Konfiguration anpassen
|
||||
|
||||
- **Caddy**: `frontend/docker/caddy/Caddyfile` bearbeiten
|
||||
- **Docker Compose**: `docker-compose.yml` in `/opt/myp-frontend`
|
||||
- **SSL**: Setup-Skript mit Option 2 für neue Zertifikate
|
||||
|
||||
### Monitoring
|
||||
|
||||
- **Health Endpoints**: `/health` für Verfügbarkeitsprüfung
|
||||
- **Logs**: Strukturierte JSON-Logs von Caddy
|
||||
- **Metrics**: Docker-Container-Statistiken
|
||||
|
||||
### Updates
|
||||
|
||||
```bash
|
||||
# Frontend-Code aktualisieren
|
||||
cd /opt/myp-frontend
|
||||
sudo git pull origin main
|
||||
sudo docker compose build --no-cache
|
||||
sudo docker compose up -d
|
||||
|
||||
# System-Updates
|
||||
sudo apt update && sudo apt upgrade -y
|
||||
sudo reboot
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Version**: 1.0.0
|
||||
**Letzte Aktualisierung**: $(date '+%Y-%m-%d')
|
||||
**Autor**: MYP Development Team
|
||||
@@ -1,296 +0,0 @@
|
||||
# Frontend Setup - Changelog und Verbesserungen
|
||||
|
||||
## Übersicht der Änderungen
|
||||
|
||||
**Datum**: 2025-01-06
|
||||
**Bearbeiter**: Claude AI Assistant
|
||||
**Auftrag**: Konsolidierung der Frontend-Installation mit Mercedes SSL-Zertifikaten
|
||||
|
||||
## ✅ Durchgeführte Änderungen
|
||||
|
||||
### 1. Bereinigung unnötiger Skripte
|
||||
|
||||
#### Gelöschte Dateien:
|
||||
|
||||
- `frontend/docker/legacy_deploy.sh` - Veraltetes Deployment-Skript
|
||||
|
||||
#### Begründung:
|
||||
|
||||
- Das legacy Skript war nicht mehr zeitgemäß
|
||||
- Funktionalität wird durch das neue konsolidierte Setup-Skript ersetzt
|
||||
- Reduziert Verwirrung und Wartungsaufwand
|
||||
|
||||
### 2. Neues konsolidiertes Setup-Skript
|
||||
|
||||
#### Erstellt: `frontend/setup.sh`
|
||||
|
||||
- **Größe**: ~700 Zeilen umfassendes Bash-Skript
|
||||
- **Struktur**: Nach Vorbild des Backend `setup.sh` erstellt
|
||||
- **Funktionalität**: Vollständige Frontend-Installation und -Konfiguration
|
||||
|
||||
#### Kernfunktionen:
|
||||
|
||||
1. **Systemvalidierung**
|
||||
|
||||
- Root-Berechtigung prüfen
|
||||
- Debian/Raspbian-System erkennen
|
||||
- Internetverbindung testen
|
||||
2. **Docker-Installation**
|
||||
|
||||
- Docker CE automatisch installieren
|
||||
- Docker Compose Plugin einrichten
|
||||
- Service-Aktivierung für Boot-Start
|
||||
3. **Mercedes SSL-Zertifikate**
|
||||
|
||||
- Selbstsignierte Zertifikate generieren
|
||||
- Subject Alternative Names (SAN) konfigurieren
|
||||
- System-CA-Store Integration
|
||||
4. **Frontend-Deployment**
|
||||
|
||||
- Anwendung nach `/opt/myp-frontend` kopieren
|
||||
- Docker Compose Konfiguration erstellen
|
||||
- Systemd Service einrichten
|
||||
5. **Systemintegration**
|
||||
|
||||
- UFW-Firewall konfigurieren
|
||||
- Automatischer Boot-Start
|
||||
- Umfassende Tests und Monitoring
|
||||
|
||||
### 3. Mercedes SSL-Zertifikat Konfiguration
|
||||
|
||||
#### Zertifikat-Details:
|
||||
|
||||
```
|
||||
Organisation: Mercedes-Benz AG
|
||||
Abteilung: IT-Abteilung
|
||||
Standort: Stuttgart, Baden-Württemberg, Deutschland
|
||||
Land: DE
|
||||
Primäre Domain: m040tbaraspi001.de040.corpintra.net
|
||||
```
|
||||
|
||||
#### Subject Alternative Names (SAN):
|
||||
|
||||
- `m040tbaraspi001.de040.corpintra.net`
|
||||
- `m040tbaraspi001`
|
||||
- `localhost`
|
||||
- `raspberrypi`
|
||||
- `127.0.0.1`
|
||||
- `192.168.0.109`
|
||||
|
||||
#### Speicherorte:
|
||||
|
||||
- Zertifikat: `/etc/ssl/certs/myp/frontend.crt`
|
||||
- Privater Schlüssel: `/etc/ssl/certs/myp/frontend.key`
|
||||
- OpenSSL Konfiguration: `/etc/ssl/certs/myp/openssl.conf`
|
||||
|
||||
### 4. Docker Compose Konfiguration
|
||||
|
||||
#### Erstellt automatisch: `docker-compose.yml`
|
||||
|
||||
```yaml
|
||||
services:
|
||||
frontend-app: # Next.js Application (Port 3000 intern)
|
||||
caddy: # Reverse Proxy (Port 80/443)
|
||||
db: # SQLite Container mit persistenten Volumes
|
||||
```
|
||||
|
||||
#### Volumes:
|
||||
|
||||
- `caddy_data`: Caddy-Daten persistent
|
||||
- `caddy_config`: Caddy-Konfiguration
|
||||
- `db_data`: Datenbank-Dateien
|
||||
|
||||
### 5. Systemd Service Integration
|
||||
|
||||
#### Service-Name: `myp-frontend.service`
|
||||
|
||||
- **Auto-Start**: Beim Boot aktiviert
|
||||
- **Dependencies**: Startet nach Docker-Service
|
||||
- **Working Directory**: `/opt/myp-frontend`
|
||||
- **Restart Policy**: Automatische Wiederherstellung bei Fehlern
|
||||
- **Sicherheit**: Sandboxed mit eingeschränkten Berechtigungen
|
||||
|
||||
### 6. Firewall-Konfiguration (UFW)
|
||||
|
||||
#### Erlaubte Verbindungen:
|
||||
|
||||
- **SSH**: Port 22 (Remote-Zugang)
|
||||
- **HTTP**: Port 80 (Redirect zu HTTPS)
|
||||
- **HTTPS**: Port 443 (Hauptzugang)
|
||||
- **Lokale Verbindungen**: 127.0.0.1, ::1
|
||||
- **Mercedes-Netzwerke**: 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12
|
||||
|
||||
### 7. Interaktives Setup-Menü
|
||||
|
||||
#### Optionen:
|
||||
|
||||
1. **Vollständige Frontend-Installation**
|
||||
|
||||
- Docker, SSL-Zertifikate, Caddy, Services
|
||||
- Komplette Neuinstallation für Produktionsumgebung
|
||||
2. **SSL-Zertifikate neu generieren**
|
||||
|
||||
- Erneuert nur die Zertifikate
|
||||
- Services-Neustart inklusive
|
||||
3. **Service-Status prüfen**
|
||||
|
||||
- Systemd Service Status
|
||||
- Docker Container Gesundheit
|
||||
- Netzwerk-Tests und SSL-Validierung
|
||||
4. **Beenden**
|
||||
|
||||
- Skript verlassen
|
||||
|
||||
### 8. Umfassende Dokumentation
|
||||
|
||||
#### Erstellt: `docs/FRONTEND_INSTALLATION.md`
|
||||
|
||||
- **Umfang**: ~300 Zeilen detaillierte Dokumentation
|
||||
- **Inhalt**:
|
||||
- Schnellstart-Anleitung
|
||||
- Detaillierte Installationsschritte
|
||||
- Service-Management
|
||||
- Troubleshooting-Guide
|
||||
- Backup und Wartung
|
||||
- Performance-Optimierung
|
||||
|
||||
#### Aktualisiert: `README.md`
|
||||
|
||||
- Neue Schnellstart-Sektion mit automatischer Installation
|
||||
- Frontend-Setup-Skript Features dokumentiert
|
||||
- SSL-Zertifikat-Informationen hinzugefügt
|
||||
- Deployment-Szenarien erweitert
|
||||
|
||||
## 🔄 Migrationshinweise
|
||||
|
||||
### Von altem System zu neuem Setup
|
||||
|
||||
#### Alte Methode (Manuell):
|
||||
|
||||
```bash
|
||||
cd frontend
|
||||
pnpm install
|
||||
pnpm build
|
||||
pnpm start # Port 3000
|
||||
```
|
||||
|
||||
#### Neue Methode (Automatisch):
|
||||
|
||||
```bash
|
||||
cd frontend
|
||||
sudo ./setup.sh # Option 1 wählen
|
||||
# Verfügbar unter https://m040tbaraspi001.de040.corpintra.net
|
||||
```
|
||||
|
||||
#### Vorteile der neuen Methode:
|
||||
|
||||
- **Produktions-ready**: HTTPS auf Port 443 statt HTTP auf Port 3000
|
||||
- **Automatisiert**: Komplette Installation ohne manuelle Schritte
|
||||
- **Sicher**: SSL-verschlüsselt mit Mercedes-Zertifikaten
|
||||
- **Wartungsfreundlich**: Systemd-Integration für Service-Management
|
||||
- **Skalierbar**: Docker-basiert für bessere Ressourcenverwaltung
|
||||
|
||||
## 🧪 Tests und Validierung
|
||||
|
||||
### Automatische Tests im Setup-Skript:
|
||||
|
||||
1. **System-Validierung**
|
||||
|
||||
- Root-Berechtigung
|
||||
- Debian/Raspbian-Erkennung
|
||||
- Internetverbindung
|
||||
2. **Installation-Verification**
|
||||
|
||||
- Docker-Service Status
|
||||
- SSL-Zertifikat Gültigkeit
|
||||
- Container-Gesundheit
|
||||
3. **Netzwerk-Tests**
|
||||
|
||||
- HTTPS-Verbindung zu Domain
|
||||
- localhost-Fallback
|
||||
- Health-Endpoint Verfügbarkeit
|
||||
4. **Service-Integration**
|
||||
|
||||
- Systemd Service Status
|
||||
- Automatischer Boot-Start
|
||||
- Log-Dateien Zugriff
|
||||
|
||||
## 📊 Performance-Verbesserungen
|
||||
|
||||
### Container-Optimierungen:
|
||||
|
||||
- **Multi-Stage Builds**: Reduzierte Image-Größen
|
||||
- **Health Checks**: Automatische Fehlerbehandlung (30s Intervall)
|
||||
- **Resource Limits**: Verhindert Memory-Leaks
|
||||
- **Restart Policies**: Automatische Wiederherstellung
|
||||
|
||||
### Raspberry Pi spezifisch:
|
||||
|
||||
- **Memory Management**: Swappiness reduziert auf 10
|
||||
- **I/O Scheduler**: Optimiert für SD-Karten
|
||||
- **CPU Scheduling**: Verbesserte Interaktivität für Touch-Interface
|
||||
- **Caching**: Effiziente RAM-Nutzung
|
||||
|
||||
## 🔐 Sicherheitsverbesserungen
|
||||
|
||||
### SSL/TLS:
|
||||
|
||||
- **4096-bit RSA**: Stärkere Verschlüsselung als Standard 2048-bit
|
||||
- **Subject Alternative Names**: Unterstützt mehrere Domain-Namen
|
||||
- **System-CA-Integration**: Automatische Vertrauensstellung
|
||||
- **HTTP-zu-HTTPS-Redirect**: Automatische Sicherheitsweiterleitung
|
||||
|
||||
### Container-Sicherheit:
|
||||
|
||||
- **Sandboxed Execution**: NoNewPrivileges, PrivateTmp
|
||||
- **Read-Only Mounts**: SSL-Zertifikate schreibgeschützt
|
||||
- **Network Isolation**: Container-zu-Container Kommunikation begrenzt
|
||||
- **Privilege Restriction**: Minimale erforderliche Berechtigungen
|
||||
|
||||
### Firewall:
|
||||
|
||||
- **Restriktive Standard-Policy**: Deny incoming, allow outgoing
|
||||
- **Whitelist-Ansatz**: Nur explizit erlaubte Verbindungen
|
||||
- **Netzwerk-Segmentierung**: Mercedes-interne Bereiche definiert
|
||||
|
||||
## 🚀 Nächste Schritte
|
||||
|
||||
### Geplante Erweiterungen:
|
||||
|
||||
1. **Monitoring-Dashboard**: Integration von Prometheus/Grafana für Container-Metriken
|
||||
2. **Automatische Updates**: Rolling-Updates für Container ohne Downtime
|
||||
3. **Backup-Automation**: Regelmäßige Sicherung von Datenbank und Konfiguration
|
||||
4. **Load Balancing**: Horizontal-Skalierung bei höherer Last
|
||||
|
||||
### Wartungsaufgaben:
|
||||
|
||||
1. **Zertifikat-Rotation**: Automatische Erneuerung vor Ablauf
|
||||
2. **Log-Rotation**: Automatisches Archivieren großer Log-Dateien
|
||||
3. **Security Updates**: Regelmäßige Container-Image Updates
|
||||
4. **Performance-Monitoring**: Überwachung von Ressourcenverbrauch
|
||||
|
||||
## 📝 Fazit
|
||||
|
||||
Die Konsolidierung des Frontend-Setups bietet erhebliche Verbesserungen:
|
||||
|
||||
### ✅ Erreichte Ziele:
|
||||
|
||||
- **Ein einziges Setup-Skript**: Ersetzt alle manuellen Installationsschritte
|
||||
- **Produktions-ready**: HTTPS unter korrekter Mercedes-Domain verfügbar
|
||||
- **Automatisiert**: Minimaler manueller Aufwand für Deployment
|
||||
- **Dokumentiert**: Umfassende Anleitung für alle Szenarien
|
||||
- **Sicher**: SSL-verschlüsselt mit Mercedes-konformen Zertifikaten
|
||||
|
||||
### 🎯 Bewertung:
|
||||
|
||||
- **Wartbarkeit**: Deutlich verbessert durch Systemd-Integration
|
||||
- **Skalierbarkeit**: Docker-basiert für flexible Ressourcenverteilung
|
||||
- **Sicherheit**: Produktions-konforme SSL-Verschlüsselung
|
||||
- **Benutzerfreundlichkeit**: Interaktives Menü für alle Administrationsaufgaben
|
||||
|
||||
---
|
||||
|
||||
**Erstellt**: 2025-01-06
|
||||
**Autor**: Claude AI Assistant
|
||||
**Version**: 1.0.0
|
||||
**Zweck**: Dokumentation der Frontend-Setup-Konsolidierung für MYP-Projekt
|
||||
@@ -1,160 +0,0 @@
|
||||
# Glassmorphism Enhancement Documentation
|
||||
|
||||
## Übersicht
|
||||
Die Glassmorphism-Effekte in der MYP-Anwendung wurden erheblich verstärkt, um eine modernere und visuell ansprechendere Benutzeroberfläche zu schaffen. Diese Verbesserungen betreffen sowohl den Light- als auch den Dark-Mode.
|
||||
|
||||
## Implementierte Verbesserungen
|
||||
|
||||
### 1. Verstärkte Backdrop-Filter
|
||||
- **Blur-Werte erhöht**: Von 12px-16px auf 20px-24px
|
||||
- **Sättigung hinzugefügt**: saturate(180%-200%) für lebendigere Farben
|
||||
- **Helligkeit angepasst**: brightness(110%-120%) für bessere Sichtbarkeit
|
||||
|
||||
### 2. Verbesserte Transparenz-Werte
|
||||
- **Light Mode**: Hintergrund-Transparenz von 70% auf 60-70%
|
||||
- **Dark Mode**: Hintergrund-Transparenz von 70% auf 60-80%
|
||||
- **Rahmen**: Transparenz von 50% auf 20-40% für subtilere Grenzen
|
||||
|
||||
### 3. Erweiterte Box-Shadow-Effekte
|
||||
- **Mehrschichtige Schatten**: Kombination aus großen weichen Schatten und feinen Rahmen-Highlights
|
||||
- **Light Mode**: `0 25px 50px rgba(0, 0, 0, 0.15), 0 0 0 1px rgba(255, 255, 255, 0.1)`
|
||||
- **Dark Mode**: `0 25px 50px rgba(0, 0, 0, 0.3), 0 0 0 1px rgba(255, 255, 255, 0.05)`
|
||||
|
||||
## Betroffene Komponenten
|
||||
|
||||
### Navigation (Navbar)
|
||||
```css
|
||||
backdrop-filter: blur(24px) saturate(200%) brightness(120%);
|
||||
background: rgba(255, 255, 255, 0.5); /* Light Mode */
|
||||
background: rgba(0, 0, 0, 0.5); /* Dark Mode */
|
||||
```
|
||||
|
||||
### Karten (Cards)
|
||||
```css
|
||||
backdrop-filter: blur(20px) saturate(180%) brightness(110%);
|
||||
background: rgba(255, 255, 255, 0.7); /* Light Mode */
|
||||
background: rgba(0, 0, 0, 0.7); /* Dark Mode */
|
||||
```
|
||||
|
||||
### Buttons
|
||||
```css
|
||||
backdrop-filter: blur(16px) saturate(150%) brightness(110%);
|
||||
box-shadow: 0 20px 40px rgba(0, 0, 0, 0.2), 0 0 0 1px rgba(255, 255, 255, 0.1);
|
||||
```
|
||||
|
||||
### Dropdown-Menüs
|
||||
```css
|
||||
backdrop-filter: blur(24px) saturate(200%) brightness(120%);
|
||||
box-shadow: 0 25px 50px rgba(0, 0, 0, 0.25), 0 0 0 1px rgba(255, 255, 255, 0.1);
|
||||
```
|
||||
|
||||
### Formulare
|
||||
```css
|
||||
backdrop-filter: blur(16px) saturate(150%);
|
||||
background: rgba(255, 255, 255, 0.6); /* Light Mode */
|
||||
background: rgba(0, 0, 0, 0.6); /* Dark Mode */
|
||||
```
|
||||
|
||||
## Neue CSS-Klassen
|
||||
|
||||
### Utility-Klassen
|
||||
- `.glass-light` - Basis-Glaseffekt für Light Mode
|
||||
- `.glass-dark` - Basis-Glaseffekt für Dark Mode
|
||||
- `.glass-strong` - Verstärkter Glaseffekt
|
||||
- `.glass-subtle` - Subtiler Glaseffekt
|
||||
|
||||
### Komponenten-Klassen
|
||||
- `.glass-card-enhanced` - Erweiterte Karten mit Hover-Effekten
|
||||
- `.glass-nav` - Navigation mit starkem Glaseffekt
|
||||
- `.glass-btn` - Buttons mit Glasmorphism
|
||||
- `.glass-modal` - Modale Dialoge mit intensivem Glaseffekt
|
||||
- `.glass-input` - Formulareingaben mit Glaseffekt
|
||||
- `.glass-dropdown` - Dropdown-Menüs mit Glaseffekt
|
||||
|
||||
### Interaktive Effekte
|
||||
- `.glass-interactive` - Hover-Effekte mit verstärktem Blur
|
||||
- `.glass-float` - Schwebende Animation für Glaselemente
|
||||
|
||||
## Responsive Anpassungen
|
||||
|
||||
### Mobile Geräte (max-width: 768px)
|
||||
- Reduzierte Blur-Werte für bessere Performance
|
||||
- Angepasste Schatten für kleinere Bildschirme
|
||||
|
||||
### Barrierefreiheit
|
||||
- **High Contrast Mode**: Verstärkte Rahmen und reduzierte Blur-Werte
|
||||
- **Reduced Motion**: Deaktivierte Animationen und Übergänge
|
||||
|
||||
## Performance-Optimierungen
|
||||
|
||||
### Browser-Kompatibilität
|
||||
- `-webkit-backdrop-filter` für Safari-Unterstützung
|
||||
- Fallback-Schatten für ältere Browser
|
||||
|
||||
### Hardware-Beschleunigung
|
||||
- `transform` und `backdrop-filter` nutzen GPU-Beschleunigung
|
||||
- Optimierte Animationen mit `cubic-bezier` Timing-Funktionen
|
||||
|
||||
## Implementierte Dateien
|
||||
|
||||
### Backend
|
||||
- `backend/app/static/css/input.css` - Hauptstyles mit verstärkten Glassmorphism-Effekten
|
||||
- `backend/app/static/css/glassmorphism.css` - Dedizierte Glassmorphism-Utility-Klassen
|
||||
- `backend/app/static/css/output.css` - Kompilierte und minifizierte Styles
|
||||
|
||||
### Frontend
|
||||
- `frontend/src/app/globals.css` - Erweiterte Glassmorphism-Utilities
|
||||
- `frontend/tailwind.config.ts` - Erweiterte Backdrop-Blur und Box-Shadow Utilities
|
||||
- `frontend/src/components/ui/card.tsx` - Verbesserte Card-Komponente
|
||||
|
||||
## Visuelle Verbesserungen
|
||||
|
||||
### Light Mode
|
||||
- Hellere, luftigere Glaseffekte
|
||||
- Subtile weiße Rahmen-Highlights
|
||||
- Warme Farbsättigung
|
||||
|
||||
### Dark Mode
|
||||
- Tiefere, mystischere Glaseffekte
|
||||
- Dezente weiße Akzente
|
||||
- Erhöhter Kontrast für bessere Lesbarkeit
|
||||
|
||||
## Browser-Support
|
||||
- **Chrome/Edge**: Vollständige Unterstützung
|
||||
- **Firefox**: Vollständige Unterstützung (ab Version 103)
|
||||
- **Safari**: Vollständige Unterstützung mit `-webkit-` Präfix
|
||||
- **Mobile Browser**: Optimierte Performance mit reduzierten Effekten
|
||||
|
||||
## Wartung und Updates
|
||||
|
||||
### CSS-Build-Prozess
|
||||
```bash
|
||||
cd backend/app
|
||||
npx tailwindcss -i static/css/input.css -o static/css/output.css --minify
|
||||
```
|
||||
|
||||
### Frontend-Build
|
||||
```bash
|
||||
cd frontend
|
||||
npm run build
|
||||
```
|
||||
|
||||
## Zukünftige Erweiterungen
|
||||
|
||||
### Geplante Features
|
||||
- Adaptive Glasstärke basierend auf Systemleistung
|
||||
- Dynamische Farbverläufe in Glaseffekten
|
||||
- Erweiterte Animationen für Glasübergänge
|
||||
- Benutzerdefinierte Glasstärke-Einstellungen
|
||||
|
||||
### Performance-Monitoring
|
||||
- Überwachung der Render-Performance
|
||||
- Automatische Fallbacks für schwächere Geräte
|
||||
- Progressive Enhancement für moderne Browser
|
||||
|
||||
---
|
||||
|
||||
**Erstellt**: 26. Mai 2025
|
||||
**Version**: 1.0
|
||||
**Autor**: AI Assistant
|
||||
**Status**: Implementiert und getestet
|
||||
@@ -1,127 +0,0 @@
|
||||
# Glassmorphism Enhancement - Arbeitsabschluss
|
||||
|
||||
## Zusammenfassung der durchgeführten Arbeiten
|
||||
|
||||
### 🎯 Ziel erreicht
|
||||
Die Glassmorphism-Effekte in der MYP-Anwendung wurden erfolgreich verstärkt und modernisiert. Alle geplanten Verbesserungen wurden implementiert und dokumentiert.
|
||||
|
||||
## ✅ Abgeschlossene Aufgaben
|
||||
|
||||
### 1. CSS-Verbesserungen
|
||||
- **`backend/app/static/css/input.css`** - Hauptstyles mit verstärkten Glassmorphism-Effekten
|
||||
- Backdrop-Filter von 12px-16px auf 20px-24px erhöht
|
||||
- Sättigung (180%-200%) und Helligkeit (110%-120%) hinzugefügt
|
||||
- Transparenz-Werte für Light/Dark Mode optimiert (60-80%)
|
||||
- Mehrschichtige Box-Shadow-Effekte implementiert
|
||||
- Button-Styles (.btn-primary, .btn-secondary, .btn-outline) verbessert
|
||||
|
||||
### 2. Dedizierte Glassmorphism-Bibliothek
|
||||
- **`backend/app/static/css/glassmorphism.css`** - Neue Utility-Klassen erstellt
|
||||
- Basis-Glaseffekte: `.glass-base`, `.glass-strong`, `.glass-subtle`
|
||||
- Mode-spezifische Klassen: `.glass-light`, `.glass-dark`
|
||||
- Komponenten-Klassen: `.glass-nav`, `.glass-card-enhanced`, `.glass-btn`
|
||||
- Interaktive Effekte: `.glass-interactive`, `.glass-float`
|
||||
- Responsive Anpassungen für mobile Geräte
|
||||
- Barrierefreiheit: High Contrast Mode und Reduced Motion Support
|
||||
|
||||
### 3. Build-Prozess
|
||||
- **CSS erfolgreich kompiliert** mit `npx tailwindcss`
|
||||
- **Minifizierte Ausgabe** in `backend/app/static/css/output.css`
|
||||
- **Warnung behoben**: caniuse-lite Datenbank aktualisiert
|
||||
|
||||
### 4. Dokumentation
|
||||
- **`GLASSMORPHISM_ENHANCEMENT.md`** - Vollständige technische Dokumentation
|
||||
- Detaillierte Beschreibung aller Verbesserungen
|
||||
- Code-Beispiele für alle Komponenten
|
||||
- Browser-Kompatibilität und Performance-Hinweise
|
||||
- Wartungsanweisungen und Build-Prozess
|
||||
- **`backend/ROADMAP.md`** - Aktualisiert mit UI/UX-Verbesserungen
|
||||
- Neue Sektion für Glassmorphism-Design-System
|
||||
- Status als "abgeschlossen" markiert
|
||||
|
||||
## 🔧 Technische Details
|
||||
|
||||
### Implementierte Effekte
|
||||
```css
|
||||
/* Beispiel für verstärkte Glassmorphism-Effekte */
|
||||
backdrop-filter: blur(24px) saturate(200%) brightness(120%);
|
||||
background: rgba(255, 255, 255, 0.6);
|
||||
box-shadow: 0 25px 50px rgba(0, 0, 0, 0.15),
|
||||
0 0 0 1px rgba(255, 255, 255, 0.1);
|
||||
border: 1px solid rgba(255, 255, 255, 0.2);
|
||||
```
|
||||
|
||||
### Browser-Support
|
||||
- ✅ Chrome/Edge: Vollständige Unterstützung
|
||||
- ✅ Firefox: Vollständige Unterstützung (ab Version 103)
|
||||
- ✅ Safari: Vollständige Unterstützung mit `-webkit-` Präfix
|
||||
- ✅ Mobile Browser: Optimierte Performance
|
||||
|
||||
### Performance-Optimierungen
|
||||
- GPU-Beschleunigung durch `transform` und `backdrop-filter`
|
||||
- Reduzierte Blur-Werte für mobile Geräte
|
||||
- Hardware-beschleunigte Animationen mit `cubic-bezier`
|
||||
- Fallback-Schatten für ältere Browser
|
||||
|
||||
## 📁 Betroffene Dateien
|
||||
|
||||
### Neue Dateien
|
||||
- `backend/app/static/css/glassmorphism.css` - Dedizierte Glassmorphism-Utilities
|
||||
- `GLASSMORPHISM_ENHANCEMENT.md` - Technische Dokumentation
|
||||
- `GLASSMORPHISM_SUMMARY.md` - Diese Zusammenfassung
|
||||
|
||||
### Modifizierte Dateien
|
||||
- `backend/app/static/css/input.css` - Verstärkte Hauptstyles
|
||||
- `backend/app/static/css/output.css` - Neu kompilierte CSS-Ausgabe
|
||||
- `backend/ROADMAP.md` - Aktualisiert mit UI/UX-Verbesserungen
|
||||
|
||||
## 🎨 Visuelle Verbesserungen
|
||||
|
||||
### Light Mode
|
||||
- Hellere, luftigere Glaseffekte
|
||||
- Subtile weiße Rahmen-Highlights
|
||||
- Warme Farbsättigung für bessere Lesbarkeit
|
||||
|
||||
### Dark Mode
|
||||
- Tiefere, mystischere Glaseffekte
|
||||
- Dezente weiße Akzente
|
||||
- Erhöhter Kontrast für bessere Sichtbarkeit
|
||||
|
||||
### Interaktive Elemente
|
||||
- Verstärkte Hover-Effekte mit erhöhtem Blur
|
||||
- Schwebende Animationen für Glaselemente
|
||||
- Sanfte Übergänge mit optimierten Timing-Funktionen
|
||||
|
||||
## 🚀 Nächste Schritte
|
||||
|
||||
### Sofort verfügbar
|
||||
- Alle Glassmorphism-Effekte sind implementiert und einsatzbereit
|
||||
- CSS ist kompiliert und optimiert
|
||||
- Dokumentation ist vollständig
|
||||
|
||||
### Empfohlene Folgeaktionen
|
||||
1. **Server-Neustart** für vollständige CSS-Aktualisierung
|
||||
2. **Browser-Cache leeren** für sofortige Sichtbarkeit der Änderungen
|
||||
3. **Cross-Browser-Tests** zur Verifikation der Kompatibilität
|
||||
4. **Performance-Monitoring** bei intensiver Nutzung
|
||||
|
||||
### Zukünftige Erweiterungen
|
||||
- Adaptive Glasstärke basierend auf Systemleistung
|
||||
- Dynamische Farbverläufe in Glaseffekten
|
||||
- Benutzerdefinierte Glasstärke-Einstellungen
|
||||
- Erweiterte Animationen für Glasübergänge
|
||||
|
||||
## ✨ Ergebnis
|
||||
|
||||
Die MYP-Anwendung verfügt jetzt über ein modernes, professionelles Glassmorphism-Design-System mit:
|
||||
- **Verstärkten visuellen Effekten** für bessere Ästhetik
|
||||
- **Optimierter Performance** für alle Geräte
|
||||
- **Vollständiger Barrierefreiheit** für alle Benutzer
|
||||
- **Umfassender Dokumentation** für zukünftige Wartung
|
||||
|
||||
---
|
||||
|
||||
**Arbeitsabschluss**: 26. Mai 2025, 18:15 Uhr
|
||||
**Status**: ✅ Vollständig abgeschlossen
|
||||
**Qualität**: Produktionsreif
|
||||
**Dokumentation**: Vollständig
|
||||
Binary file not shown.
@@ -1,22 +0,0 @@
|
||||
# Glossar - MYP (Manage Your Printer)
|
||||
|
||||
| Begriff | Beschreibung |
|
||||
|---------|--------------|
|
||||
| **API** | Programmierschnittstelle zur Kommunikation zwischen Softwarekomponenten. MYP-System verfügt über REST-API mit 100+ Endpunkten |
|
||||
| **Authentifizierung** | Benutzeridentifikation mittels Anmeldedaten. Nutzt bcrypt-Hashing mit Cost-Faktor 12 für sichere Passwort-Speicherung |
|
||||
| **Cyber-physisches System** | Integration digitaler und physischer Komponenten zur automatisierten Steuerung. Smart-Plug-gesteuerte 3D-Drucker |
|
||||
| **Flask** | Python-basiertes Web-Framework für Backend-Entwicklung. Grundgerüst des MYP-Servers mit REST-API und Session-Management |
|
||||
| **MYP (Manage Your Printer)** | Projektname des Systems zur digitalen Verwaltung und automatisierten Steuerung von 3D-Druckern bei Mercedes-Benz |
|
||||
| **Raspberry Pi** | Einplatinencomputer als zentrale Serverplattform. Upgrade von Pi 4 auf Pi 5 wegen Performance-Anforderungen |
|
||||
| **REST** | Architekturstil für verteilte Systeme basierend auf HTTP-Protokoll. Grundlage der MYP-API mit über 100 Endpunkten |
|
||||
| **Scheduler** | Zeitgesteuertes System zur automatischen Ausführung geplanter Aufgaben. Eigenständiger Thread für Smart-Plug-Operationen |
|
||||
| **Smart-Plug** | Netzwerkfähige Steckdose zur Fernsteuerung elektrischer Geräte. TP-Link TAPO P110 als Hardware-Schnittstelle |
|
||||
| **SQLite** | Leichtgewichtige, dateibasierte Datenbank ohne separaten Server-Prozess. Optimal für Offline-Anforderung des Systems |
|
||||
| **TAPO** | TP-Link Produktlinie für Smart-Home-Geräte. TAPO P110 Smart-Plugs bilden Hardware-Basis für 3D-Drucker-Steuerung |
|
||||
| **TBA** | Technische Berufsausbildungsstätte der Mercedes-Benz AG Berlin mit sechs 3D-Druckern verschiedener Hersteller |
|
||||
|
||||
---
|
||||
|
||||
*Erstellt für das MYP-Projekt (Manage Your Printer)*
|
||||
*Mercedes-Benz AG - Technische Berufsausbildungsstätte Berlin*
|
||||
*Version 1.0 - Juni 2025*
|
||||
@@ -1,241 +0,0 @@
|
||||
# Projektdokumentation
|
||||
|
||||
**MYP – Manage Your Printer**
|
||||
*Digitalisierung des 3D-Drucker-Reservierungsprozesses durch Etablierung der cyberphysischen Kommunikation mit relevanten Hardwarekomponenten*
|
||||
|
||||
**IHK Abschlussprüfung Sommer 2025**
|
||||
**Fachinformatiker für digitale Vernetzung**
|
||||
|
||||
---
|
||||
|
||||
**Prüfungsbewerber:** Till Tomczak
|
||||
**Ausbildungsbetrieb:** Mercedes-Benz AG, Berlin
|
||||
**Projektbetreuung:** [Ausbilder Name]
|
||||
**Projektdurchführung:** 15. April – 20. Mai 2025
|
||||
|
||||
---
|
||||
|
||||
## Inhaltsverzeichnis
|
||||
|
||||
1. Ausgangssituation
|
||||
- 1.1 Ausgangssituation
|
||||
- 1.2 Grobkonzept und Zielsetzung
|
||||
2. Ressourcenplanung
|
||||
- 2.1 Ablaufplanung/Zeitplanung
|
||||
- 2.2 Personalplanung
|
||||
- 2.3 Sachmittelplanung
|
||||
3. Durchführung und Auftragsbearbeitung
|
||||
- 3.1 Arbeitspaketbeschreibung
|
||||
- 3.2 Abweichungen
|
||||
4. Projektergebnis
|
||||
- 4.1 Projektergebnis
|
||||
- 4.2 Qualitätskontrolle
|
||||
- 4.3 Wirtschaftlichkeit
|
||||
5. Gestaltung der Dokumentation
|
||||
6. Kundendokumentation
|
||||
7. Anhang
|
||||
|
||||
---
|
||||
|
||||
# 1. Ausgangssituation
|
||||
|
||||
## 1.1 Ausgangssituation
|
||||
|
||||
Die Technische Berufsausbildungsstätte (TBA) der Mercedes-Benz AG am Standort Berlin verfügt über sechs 3D-Drucker verschiedener Hersteller (Prusa, Anycubic; B-Ware im Vergleich zu 3D-Druckern von Kostenstellen höherer Priorität sozusagen). Diese Geräte stellen eine wichtige Ressource für die praktische Ausbildung dar, weisen jedoch erhebliche technische Limitierungen auf; beispielsweise verfügen die Drucker weder über Funk- noch Netzwerkschnittstellen oder andere gesamteinheitliche Steuerungsmöglichkeiten. Diese technischen Einschränkungen verhinderten bislang eine koordinierte digitale Verwaltung und eine damit einhergehende Übersicht von Reservierungen und Nutzungsplänen der Azubis.
|
||||
|
||||
Das bestehende 'Reservierungssystem' - wenn man es nun so nennen kann - basierte auf einem analogen Whiteboard, welches neben den Druckern positioniert war. Dies führte zu systematischen Problemen: Doppelbuchungen traten regelmäßig auf, wenn mehrere Nutzer zeitgleich Reservierungen vornahmen, die manuelle Aktivierung und Deaktivierung der Geräte wurde häufig versäumt - was zu unnötigem Energieverbrauch und erhöhtem Verschleiß führte - und eine verlässliche Dokumentation der tatsächlichen Nutzungszeiten existierte nicht, wodurch weder aussagekräftige Betätigungs- und Verantwortungszuordnung (bspw. für Aufräumarbeiten), noch eine verursachungsgerechte Kostenzuordnung möglich waren.
|
||||
|
||||
Ein erstmaliger Lösungsansatz durch den ehemaligen Auszubildenden Torben Haack hatte einen vielversprechenden Frontend-Prototypen auf Basis von Next.js hervorgebracht. Der Prototyp verfügte über eine moderne Benutzeroberfläche und gute Analysefunktionen, allerdings jedoch fehlte ganz fundamental die essentielle Backend-Funktionalität; ohne dies blieb die auf Prototypen-basierende Projektarbeit des Torben Haacks in der praktischen Anwendung ohne jegliche Funktion. Ich sah für mich also die Chance, die Idee hinter dem Prototypen aufzugreifen und mich ihrer im Rahmen meiner hier dargelegten Projektarbeit anzunehmen, da ich sofort mehrere Möglichkeiten zur Einbringung meiner Fachrichtung identifizieren konnte und ich keine notwendige Obligation - wie bei anderen Projektmöglichkeiten die sich mir boten - verspürte, sondern einen Anflug von Ideen, Tatendrang und intrinsischer Motivation; sprich: es kitzelte meine Leidenschaft.
|
||||
|
||||
Die Herausforderung, analoge Prozesse in eine digitale Welt zu überführen, manifestierte sich hier in ihrer reinsten Form - nicht als theoretisches Konstrukt, sondern als greifbares Problem mit spürbaren Auswirkungen auf den Ausbildungsalltag. Die Vision einer cyber-physischen Lösung, die nicht nur verwaltet, sondern aktiv steuert, kristallisierte sich als Kernaspekt meiner Fachrichtung heraus.
|
||||
|
||||
## 1.2 Grobkonzept und Zielsetzung
|
||||
|
||||
Nach erfolgter Zulassung des Abschlussprojekts durch die IHK kristallisierte sich die Zielsetzung in ihrer vollen Komplexität heraus: Die Transformation eines dysfunktionalen analogen Systems in eine moderne cyber-physische Lösung, die unter dem prägnanten Namen "MYP - Manage Your Printer" nicht nur die digitale Verwaltung der Reservierungen orchestrieren, sondern die physischen Geräte in einem automatisierten Tanz von Aktivierung und Deaktivierung dirigieren sollte.
|
||||
|
||||
Die zentrale Herausforderung - und hier offenbarte sich die Eleganz des Problems in seiner technischen Reinheit - bestand in der Überbrückung der kommunikativen Kluft zwischen digitaler Steuerungslogik und analogen Druckern, die in ihrer technologischen Isolation verharrten. Da eine direkte Kommunikation mit den Geräten aufgrund fehlender Schnittstellen einer digitalen Quadratur des Kreises gleichkam, musste ein alternativer, gleichwohl raffinierter Ansatz zur Hardware-Steuerung entwickelt werden.
|
||||
|
||||
Die Lösung manifestierte sich in Form intelligenter Zwischensteckdosen - TP-Link Tapo P110 Smart-Plugs -, die als kommunikative Brückenköpfe zwischen der digitalen und physischen Welt fungieren sollten. Diese Geräte, ausgestattet mit lokaler API und unabhängig von Cloud-Zwängen, versprachen die grundlegenden Funktionen der Stromversorgungssteuerung sowie die Extraktion wertvoller Metadaten wie Verbrauchswerte und Betriebszustände.
|
||||
|
||||
Das architektonische Konzept folgte einer dreischichtigen Symphonie: Die Präsentationsschicht, basierend auf Haacks Next.js-Frontend, sollte durch meine Backend-Ergänzungen zur vollen Blüte gebracht werden. Die Geschäftslogikschicht würde sich in einem Python-basierten Flask-Backend materialisieren, welches über die PyP100-Bibliothek die linguistische Übersetzung zur Hardware-Ebene bewerkstelligen würde. Als persistente Grundlage diente eine SQLite-Datenbank - bewusst gewählt für ihre Autarkie und Offline-Tauglichkeit, perfekt harmonierend mit den stringenten Sicherheitsanforderungen der Mercedes-Benz AG.
|
||||
|
||||
# 2. Ressourcenplanung
|
||||
|
||||
## 2.1 Ablaufplanung/Zeitplanung
|
||||
|
||||
Die temporale Orchestrierung des Projekts folgte einem agilen Crescendo, strukturiert in fünf einwöchige Sprints, die sich vom 15. April bis zum 20. Mai 2025 erstreckten. Diese iterative Herangehensweise - weniger starres Korsett als vielmehr flexibles Skelett - ermöglichte die notwendige Adaptivität gegenüber den unvermeidlichen Kapriolen technischer Realität.
|
||||
|
||||
**Sprint 1 (15.-19. April):** Der Auftakt widmete sich der forensischen Analyse des Haack'schen Erbes. Mit chirurgischer Präzision sezierte ich die Frontend-Codebasis, extrahierte ihre Stärken und identifizierte die neuralgischen Punkte für die Backend-Integration. Die erfolgreiche Etablierung der Kommunikation mit den Smart-Plugs - jener kritische Handschlag zwischen Software und Hardware - markierte den ersten triumphalen Meilenstein.
|
||||
|
||||
**Sprint 2 (22.-26. April):** Hier offenbarte sich die kafkaeske Natur korporativer Bürokratie in ihrer vollen Pracht. Die Erlangung administrativer Privilegien mutierte zu einer Odyssee durch digitale Instanzen. Parallel dazu entfaltete sich eine technische Detektivarbeit: Mittels Wireshark-Analysen dekodierte ich das kryptische Kommunikationsprotokoll der Smart-Plugs - eine Übung in digitalem Reverse-Engineering, die gleichermaßen frustrierend wie erhellend war.
|
||||
|
||||
**Sprint 3 (29. April - 3. Mai):** Der geplante Integrationssprint transformierte sich in ein Lehrstück über Murphy's Gesetz. Die versehentliche Vernichtung hart erkämpfter SSL-Zertifikate - ein digitaler Pyrrhussieg der besonderen Art - zwang zu improvisierter Schadensbegrenzung. Die Untiefen unternehmenseigener OAuth-Implementierungen und npm-Konfigurationen erwiesen sich als unerwartet tückisch.
|
||||
|
||||
**Sprint 4 (6.-10. Mai):** Unter dem Damoklesschwert der nahenden Deadline mutierte dieser Sprint zur Bewährungsprobe. Die ursprüngliche Optimierungsagenda wich einer pragmatischen Fokussierung auf das Essenzielle. In marathonartigen Coding-Sessions - getrieben von einer Mischung aus Koffein und Determination - entstand das funktionale Herzstück des Systems.
|
||||
|
||||
**Sprint 5 (13.-17. Mai):** Der finale Akt diente der Konsolidierung. Bugs wurden gejagt und eliminiert, die Systemstabilität auf ein produktionsreifes Niveau gehoben. Die geplanten Anwenderschulungen fielen dem Primat der technischen Perfektion zum Opfer - eine schmerzhafte, aber notwendige Priorisierung.
|
||||
|
||||
## 2.2 Personalplanung
|
||||
|
||||
Die personelle Konstellation des Projekts zeichnete sich durch ihre bewusste Schlankheit aus - ein Soloprojekt im wahrsten Sinne, jedoch eingebettet in ein unterstützendes Ökosystem. Als alleiniger Entwickler trug ich die Gesamtverantwortung, agierte simultan als Architekt, Implementierer und Qualitätssicherer.
|
||||
|
||||
Die Ausbildungsleitung fungierte als strategischer Sparringspartner, gewährte notwendige Freiräume und intervenierte unterstützend bei administrativen Hürden. Die IT-Abteilung - anfangs skeptisch beäugt, später als unverzichtbare Alliierte geschätzt - ermöglichte durch ihre Kooperation erst die netzwerktechnische Integration.
|
||||
|
||||
Der Schatten Torben Haacks schwebte als inspirierender Geist über dem Projekt. Seine Frontend-Vorarbeit bildete das Fundament, auf dem ich aufbauen konnte - eine posthume Kollaboration der besonderen Art, bei der sein Code zur Blaupause meiner Erweiterungen wurde.
|
||||
|
||||
## 2.3 Sachmittelplanung
|
||||
|
||||
Die materielle Ausstattung des Projekts spiegelte die Spannung zwischen technischer Ambition und budgetärer Realität wider. Als zentrale Recheneinheit kristallisierte sich - nach initialen Performance-Evaluierungen - ein Raspberry Pi 5 mit 8 GB RAM heraus. Die ursprüngliche Hoffnung, mit dem schwächeren Pi 4 auszukommen, zerschellte an den Ressourcenhunger des Next.js-Frameworks.
|
||||
|
||||
Die sechs TP-Link Tapo P110 Smart-Plugs - á 15 Euro ein Schnäppchen verglichen mit industriellen Alternativen - bildeten das nervöse System der Hardware-Steuerung. Ihre Konfiguration mit statischen IP-Adressen (192.168.0.151-156) schuf ein deterministisches Kommunikationsumfeld, essentiell für die Fehlerdiagnose.
|
||||
|
||||
Die Beschaffung eines 19-Zoll-Serverschranks geriet zur Geduldsprobe. Die trägen Mühlen korporativer Einkaufsprozesse zwangen zu privater Initiative - Lüftereinheiten und Kabelmanagement aus eigener Tasche finanziert, ein Investment in professionelle Präsentation und thermische Stabilität.
|
||||
|
||||
Softwareseitig setzte ich konsequent auf Open-Source-Technologien: Python 3.11 als linguistisches Rückgrat, Flask 2.3 als Web-Framework, SQLAlchemy 2.0 für elegante Datenbankabstraktion. Diese Entscheidung - gleichsam philosophisch wie pragmatisch - garantierte Unabhängigkeit von Lizenzmodellen und harmonierte perfekt mit der Offline-Anforderung.
|
||||
|
||||
# 3. Durchführung und Auftragsbearbeitung
|
||||
|
||||
## 3.1 Arbeitspaketbeschreibung
|
||||
|
||||
Die Dekomposition des Gesamtvorhabens in verdauliche Arbeitspakete folgte einer Logik, die gleichermaßen technische Abhängigkeiten wie auch RisikoMinimierung berücksichtigte. Jedes Paket stellte einen in sich geschlossenen Meilenstein dar, dessen Erreichung messbar und verifizierbar war.
|
||||
|
||||
**AP1: Smart-Plug Integration (40h)** - Die Etablierung der Hardware-Kommunikation bildete das kritische Fundament. Ohne funktionierende Gerätesteuerung wäre das gesamte Projekt zur digitalen Fata Morgana verkommen. Die PyP100-Bibliothek erwies sich als widerspenstiger Partner - ihre Dokumentation lückenhaft, ihr Verhalten kapriziös. Durch methodisches Reverse-Engineering mittels Wireshark gelang es, die Kommunikationsprotokolle zu entschlüsseln und eine robuste Abstraktionsschicht zu implementieren. Der entwickelte SmartPlugController kapselt sämtliche Hardware-Interaktionen, implementiert Retry-Mechanismen mit exponentiellem Backoff und gewährleistet graceful degradation bei Kommunikationsfehlern.
|
||||
|
||||
**AP2: Backend-Architektur (60h)** - Das Flask-Backend entstand als modulares Kunstwerk, strukturiert durch Blueprints, die funktionale Domänen elegant segregieren. Die API-Entwicklung folgte REST-Prinzipien mit obsessiver Konsequenz. Über 100 Endpunkte entstanden - jeder dokumentiert, validiert und gegen Missbrauch gehärtet. Die Authentifizierungslogik, gewürzt mit bcrypt und verfeinert durch Session-Management, bildete das Sicherheitsfundament. Die Implementierung des Job-Schedulers als eigenständiger Thread - eine Designentscheidung von bemerkenswerter Tragweite - ermöglichte die asynchrone Orchestrierung der Hardware-Steuerung ohne Beeinträchtigung der API-Responsivität.
|
||||
|
||||
**AP3: Datenbankdesign (30h)** - Die Modellierung der Persistenzschicht offenbarte sich als Übung in vorausschauender Abstraktion. Vier Kernentitäten - User, Printer, Job und diverse Log-Tabellen - bildeten das relationale Grundgerüst. Die Job-Entität, konzipiert als State-Machine mit den Zuständen "scheduled", "running", "finished" und "aborted", ermöglichte die lückenlose Nachverfolgung des Reservierungslebenszyklus. Spezialisierte Log-Tabellen - PlugStatusLog für Hardware-Interaktionen, EnergyUsageLog für Verbrauchsanalysen, SystemPerformanceLog für Metriken - schufen die Datenbasis für zukünftige Optimierungen.
|
||||
|
||||
**AP4: Frontend-Backend Integration (50h)** - Die Verheiratung von Haacks Frontend mit meinem Backend gestaltete sich als delikater Balanceakt. CORS-Konfigurationen mussten justiert, API-Contracts harmonisiert, Authentifizierungsflüsse synchronisiert werden. Die Implementierung eines einheitlichen Error-Handlings über beide Schichten hinweg erforderte chirurgische Eingriffe in die Frontend-Codebasis. Die Integration der SSL-Verschlüsselung - nach dem traumatischen Zertifikatsverlust mit dreifacher Backup-Strategie abgesichert - krönte die Verbindung.
|
||||
|
||||
**AP5: Testing und Deployment (40h)** - Die Qualitätssicherung folgte einem mehrschichtigen Ansatz. Unit-Tests validierten isolierte Komponenten, Integrationstests verifizierten das Zusammenspiel, End-to-End-Tests simulierten komplette Nutzerszenarien. Das Deployment auf dem Raspberry Pi 5 erforderte die Erstellung automatisierter Installationsskripte, die Konfiguration von systemd-Services und die Implementierung robuster Backup-Mechanismen. Der eingerichtete Kiosk-Modus transformierte das System zur dedizierten Appliance.
|
||||
|
||||
## 3.2 Abweichungen
|
||||
|
||||
Die Projektrealiät erwies sich - wenig überraschend für den erfahrenen Praktiker - als deutlich kapriziöser als die initiale Planung suggerierte. Die gravierendste Abweichung manifestierte sich in der unterschätzten Komplexität administrativer Prozesse. Die Erlangung notwendiger Systemrechte, ursprünglich als zweistündige Formalität eingeplant, mutierte zu einer mehrtägigen Odyssee durch die Instanzen der IT-Governance.
|
||||
|
||||
Der Verlust der SSL-Zertifikate in Sprint 3 - ein Moment digitaler Tragik - zwang zu ungeplanten Recoveries-Maßnahmen. Die daraus resultierende Implementierung einer redundanten Backup-Strategie, obwohl zeitraubend, erwies sich retrospektiv als wertvolle Härtung der Systemresilienz.
|
||||
|
||||
Die Performance-Anforderungen des Next.js-Frontends übertrafen die Prognosen erheblich. Der notwendige Hardware-Upgrade vom Raspberry Pi 4 auf das leistungsfähigere Modell 5 verursachte zusätzliche Beschaffungszeiten und Konfigurationsaufwände. Diese ungeplante Iteration lehrte die Wichtigkeit konservativer Ressourcenschätzungen bei JavaScript-lastigen Anwendungen.
|
||||
|
||||
Die ursprünglich geplanten Anwenderschulungen fielen dem Zeitdruck zum Opfer - eine schmerzhafte, aber notwendige Priorisierung. Stattdessen wurde die Entwicklung einer intuitiven Benutzeroberfläche intensiviert, die selbsterklärend genug sein sollte, um formale Einweisungen obsolet zu machen.
|
||||
|
||||
# 4. Projektergebnis
|
||||
|
||||
## 4.1 Projektergebnis
|
||||
|
||||
Das realisierte MYP-System manifestiert sich als gelungene Synthese aus technischer Raffinesse und pragmatischer Problemlösung. Die vollständige Digitalisierung des Reservierungsprozesses - vom anarchischen Whiteboard zur strukturierten Datenbank - markiert einen Quantensprung in der Ressourcenverwaltung der TBA.
|
||||
|
||||
Die technischen Eckdaten lesen sich wie eine Hymne an die Ingenieurskunst: Über 9.000 Zeilen sorgfältig strukturierten Python-Codes, mehr als 100 REST-API-Endpunkte, eine Uptime von 99,8% seit Produktivstart. Der Scheduler hat in den ersten Betriebswochen keine einzige geplante Schaltung versäumt - eine Zuverlässigkeit, die das manuelle System nie erreichte.
|
||||
|
||||
Die cyber-physische Integration - jenes Herzstück meiner Fachrichtung - funktioniert mit bemerkenswerter Präzision. Die Smart-Plugs reagieren binnen Sekunden auf Steuerbefehle, die Statusrückmeldungen fließen in Echtzeit. Die implementierte Pufferlogik verhindert elegant die vorzeitige Unterbrechung laufender Druckvorgänge - ein Detail, das die Nutzerakzeptanz maßgeblich steigerte.
|
||||
|
||||
Die Benutzererfahrung hat sich fundamental gewandelt. Wo früher Unsicherheit und Konfliktpotenzial regierten, herrscht nun transparente Planbarkeit. Die digitale Reservierung ist intuitiv, die automatische Aktivierung befreit von manuellen Routinen. Erste Nutzerfeedbacks sprechen von "endlich zeitgemäßer Verwaltung" und "spürbarer Arbeitserleichterung".
|
||||
|
||||
## 4.2 Qualitätskontrolle
|
||||
|
||||
Die Qualitätssicherung folgte einem mehrschichtigen Ansatz, der technische Exzellenz mit praktischer Robustheit vereinte. Automatisierte Tests bildeten das Fundament - über 200 Unit-Tests validierten die Geschäftslogik, Integrationstests verifizierten die API-Contracts, End-to-End-Tests simulierten komplette Nutzerworkflows.
|
||||
|
||||
Die Penetrationstests offenbarten die Wehrhaftigkeit des Systems. SQL-Injection-Versuche prallten an parametrisierten Queries ab, Cross-Site-Scripting scheiterte an konsequenter Output-Sanitization. Die implementierte Rate-Limiting-Logik erwies sich als effektive Barriere gegen Brute-Force-Attacken.
|
||||
|
||||
Performance-Messungen auf der Zielplattform bestätigten die Tragfähigkeit der Architektur. Selbst bei simultanen Zugriffen von 20 Nutzern blieb die Response-Zeit unter 200ms. Die Smart-Plug-Operationen, potenzieller Flaschenhals, wurden durch intelligentes Caching und Parallelisierung optimiert.
|
||||
|
||||
Die Dokumentation - oft stiefmütterlich behandelt, hier mit Hingabe gepflegt - umfasst technische Spezifikationen, API-Dokumentation, Deployment-Anleitungen und Troubleshooting-Guides. Jede Funktion ist kommentiert, jeder Algorithmus erläutert. Code-Reviews durch die Ausbildungsleitung attestierten "vorbildliche Strukturierung" und "professionelle Umsetzung".
|
||||
|
||||
## 4.3 Wirtschaftlichkeit
|
||||
|
||||
Die ökonomische Bilanz des Projekts liest sich wie ein Lehrstück in Effizienz. Mit Gesamtkosten von unter 600 Euro - inklusive der privat finanzierten Komponenten - wurde eine Lösung geschaffen, die kommerziellen Alternativen im fünfstelligen Bereich ebenbürtig ist.
|
||||
|
||||
Die Amortisation erfolgt auf mehreren Ebenen. Die Energieeinsparungen durch automatisierte Abschaltung summieren sich auf geschätzte 200 Euro jährlich. Die Reduzierung von Geräteverschleiß durch kontrollierte Nutzung verlängert die Lebensdauer der Drucker schätzungsweise um 30%. Die gewonnenen Nutzungsdaten ermöglichen erstmals fundierte Entscheidungen über Kapazitätserweiterungen.
|
||||
|
||||
Der immaterielle Nutzen übersteigt die materiellen Einsparungen deutlich. Die Eliminierung von Reservierungskonflikten steigert die Arbeitszufriedenheit, die transparente Ressourcenverwaltung reduziert administrative Overhead. Die gewonnene Professionalität in der Ausbildungsumgebung sendet positive Signale an Auszubildende und Ausbilder gleichermaßen.
|
||||
|
||||
Die Skalierbarkeit der Lösung verspricht zukünftige Effizienzgewinne. Die modulare Architektur erlaubt die Integration weiterer Gerätetypen ohne grundlegende Systemänderungen. Die vorbereiteten Schnittstellen für Active-Directory-Integration werden perspektivisch den Verwaltungsaufwand weiter reduzieren.
|
||||
|
||||
# 5. Gestaltung der Dokumentation
|
||||
|
||||
Die Dokumentation des MYP-Systems folgt einem ganzheitlichen Ansatz, der technische Präzision mit didaktischer Klarheit vereint. Verschiedene Zielgruppen - von technischen Administratoren bis zu Endanwendern - finden maßgeschneiderte Informationen in adäquater Tiefe und Komplexität.
|
||||
|
||||
Die technische Dokumentation umfasst detaillierte Architekturbeschreibungen, UML-Diagramme der Systemkomponenten und ausführliche API-Spezifikationen im OpenAPI-Format. Jeder Endpunkt ist mit Beispielrequests und -responses dokumentiert, Fehlercodes sind katalogisiert und mit Lösungsansätzen versehen. Die Codedokumentation folgt Python-Docstring-Konventionen, ergänzt durch inline-Kommentare an algorithmisch komplexen Stellen.
|
||||
|
||||
Für Administratoren existiert ein umfassendes Deployment-Handbuch. Von der Erstinstallation über Konfigurationsoptionen bis zu Backup-Strategien werden alle operativen Aspekte abgedeckt. Troubleshooting-Guides adressieren häufige Problemszenarien, Log-Analyse-Anleitungen ermöglichen effiziente Fehlerdiagnose.
|
||||
|
||||
Die Anwenderdokumentation verzichtet bewusst auf technischen Jargon. Illustrierte Schritt-für-Schritt-Anleitungen führen durch Standardprozesse wie Reservierungserstellung und -verwaltung. FAQ-Sektionen antizipieren typische Nutzerfragen, Video-Tutorials visualisieren komplexere Abläufe. Die Dokumentation liegt sowohl als durchsuchbare Online-Hilfe als auch als druckbares PDF vor.
|
||||
|
||||
Ein besonderes Augenmerk galt der Prozessdokumentation. Workflows wurden in BPMN 2.0 modelliert, Entscheidungsbäume visualisieren Eskalationspfade. Diese Transparenz ermöglicht kontinuierliche Prozessoptimierung und erleichtert die Einarbeitung neuer Teammitglieder.
|
||||
|
||||
# 6. Kundendokumentation
|
||||
|
||||
Die Kundendokumentation - hier primär für die internen Nutzer der TBA konzipiert - zeichnet sich durch ihre Zugänglichkeit und Praxisorientierung aus. Der Fokus liegt auf der Vermittlung des Nutzens, nicht der zugrundeliegenden Technologie.
|
||||
|
||||
Ein Quick-Start-Guide ermöglicht den sofortigen Einstieg. In maximal fünf Minuten führt er vom ersten Login zur ersten erfolgreichen Reservierung. Screenshots begleiten jeden Schritt, Hinweisboxen warnen vor häufigen Anfängerfehlern. Die Dokumente sind bewusst kurz gehalten - nie mehr als eine Bildschirmseite pro Thema.
|
||||
|
||||
Für verschiedene Nutzertypen existieren rollenspezifische Anleitungen. Reguläre Nutzer lernen die Grundfunktionen, Administratoren erhalten Einblick in erweiterte Features wie Nutzerverwaltung und Systemüberwachung. Use-Case-basierte Tutorials demonstrieren Best Practices für häufige Szenarien.
|
||||
|
||||
Die Fehlerbehebung wurde nutzerfreundlich gestaltet. Statt kryptischer Fehlercodes präsentiert das System verständliche Meldungen mit konkreten Handlungsempfehlungen. Ein visueller Systemstatus auf der Startseite signalisiert die Verfügbarkeit aller Komponenten auf einen Blick.
|
||||
|
||||
Feedback-Mechanismen sind tief in die Dokumentation integriert. Jede Seite bietet die Möglichkeit zur Bewertung und Kommentierung. Häufige Rückfragen fließen in FAQ-Updates ein, unklare Passagen werden kontinuierlich überarbeitet. Diese lebendige Dokumentation evolviert mit den Nutzerbedürfnissen.
|
||||
|
||||
# 7. Anhang
|
||||
|
||||
## 7.1 Projekttagebuch (Auszug)
|
||||
|
||||
**15.04.2025:** Projektstart mit Euphorie und Koffein. Erste Sichtung des Haack-Frontends offenbart solide Grundlagen, aber auch architektonische Herausforderungen. Mental Note: State-Management ist suboptimal implementiert.
|
||||
|
||||
**18.04.2025:** Durchbruch bei Smart-Plug-Kommunikation! Nach drei Tagen Protokoll-Analyse endlich verstanden, warum die Authentifizierung sporadisch fehlschlug. Die Lösung: Millisekunden-genaue Timestamps. Wer hätte gedacht, dass IoT-Geräte so pedantisch sind?
|
||||
|
||||
**23.04.2025:** Administratorrechte endlich erhalten. Der Antrag wanderte durch mehr Instanzen als ein Paket bei der Post. Lehre: Niemals die Trägheit korporativer Bürokratie unterschätzen.
|
||||
|
||||
**02.05.2025:** Katastrophe - SSL-Zertifikate durch fehlerhaftes Backup-Skript überschrieben. Vier Stunden Recovery-Arbeit. Silberstreif: Backup-Strategie nun bombensicher. Aus Schaden wird man klug, aus großem Schaden paranoid.
|
||||
|
||||
**08.05.2025:** Marathon-Coding-Session, 14 Stunden am Stück. Die API nimmt Form an, der Scheduler läuft. Erste erfolgreiche End-to-End-Tests. Das Gefühl, wenn alles zusammenkommt: unbezahlbar.
|
||||
|
||||
**16.05.2025:** System läuft stabil im Testbetrieb. Erste Nutzer-Feedbacks überwältigend positiv. "Endlich kein Whiteboard-Chaos mehr!" - Musik in meinen Ohren.
|
||||
|
||||
## 7.2 Technische Spezifikationen
|
||||
|
||||
**Hardware:**
|
||||
|
||||
- Server: Raspberry Pi 5, 8GB RAM, 128GB NVMe SSD
|
||||
- Netzwerk: Gigabit Ethernet, statische IP 192.168.0.105
|
||||
- Smart-Plugs: 6x TP-Link Tapo P110, Firmware 1.2.3
|
||||
- Infrastruktur: 19" Serverschrank, redundante Lüftung
|
||||
|
||||
**Software-Stack:**
|
||||
|
||||
- OS: Raspberry Pi OS Lite (64-bit)
|
||||
- Runtime: Python 3.11.2
|
||||
- Framework: Flask 2.3.2, SQLAlchemy 2.0.19
|
||||
- Frontend: Next.js 13.4.12, React 18.2.0
|
||||
- Datenbank: SQLite 3.41.2
|
||||
|
||||
**Netzwerkkonfiguration:**
|
||||
|
||||
- Subnetz: 192.168.0.0/24 (isoliertes IoT-Netzwerk)
|
||||
- Firewall: iptables mit restriktiven Regeln
|
||||
- SSL: Selbstsigniertes Zertifikat, RSA 4096-bit
|
||||
|
||||
## 7.3 Lessons Learned
|
||||
|
||||
Die wichtigste Erkenntnis: Technische Herausforderungen sind meist lösbar, organisatorische erfordern Geduld und Diplomatie. Die Kunst liegt darin, beide Sphären zu navigieren ohne die Motivation zu verlieren.
|
||||
|
||||
Die Bedeutung robuster Fehlerbehandlung kann nicht überbetont werden. Jede Netzwerkoperation kann fehlschlagen, jede Hardwarekomponente ausfallen. Defensive Programmierung ist keine Paranoia, sondern Professionalität.
|
||||
|
||||
Open-Source-Bibliotheken sind Segen und Fluch zugleich. Die PyP100-Library ersparte Entwicklungszeit, ihre mangelnde Dokumentation kostete sie wieder. Merke: Immer den Source-Code als ultimative Dokumentation betrachten.
|
||||
|
||||
Agile Methodik bewährte sich, erforderte aber Disziplin. Die Versuchung, "nur noch schnell" Features einzubauen, ist groß. Sprint-Ziele müssen sakrosankt bleiben, sonst wird aus Agilität Chaos.
|
||||
|
||||
Der Wert guter Dokumentation offenbart sich oft erst später. Die investierte Zeit zahlt sich aus, wenn Wochen später ein obskurer Bug auftritt und die eigenen Notizen den Weg zur Lösung weisen.
|
||||
|
||||
## 7.4 Danksagung
|
||||
|
||||
Mein Dank gilt der Ausbildungsleitung für das Vertrauen und die gewährten Freiräume. Der IT-Abteilung für die Geduld mit meinen "nur noch eine kleine Firewall-Regel"-Anfragen. Torben Haack für das solide Frontend-Fundament. Und nicht zuletzt dem Koffein, treuer Begleiter in langen Coding-Nächten.
|
||||
|
||||
---
|
||||
|
||||
**Anlagen:**
|
||||
|
||||
- Quellcode-Repository (GitLab-Link)
|
||||
- API-Dokumentation (OpenAPI 3.0)
|
||||
- Netzwerkdiagramme und Systemarchitektur
|
||||
- Screenshots der Benutzeroberfläche
|
||||
- Testprotokolle und Abnahmedokumentation
|
||||
@@ -1,121 +0,0 @@
|
||||
# MYP Installationsanleitung
|
||||
|
||||
Diese Anleitung beschreibt die Schritte zur Installation und Konfiguration des Mercedes-Benz 3D-Druck-Management-Systems (MYP) für den Standort Berlin Werk 040.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- Windows 10/11 oder aktuelles Linux/macOS
|
||||
- Docker Desktop installiert und konfiguriert
|
||||
- OpenSSL installiert (für Windows: [Win64 OpenSSL v3.1.1](https://slproweb.com/products/Win32OpenSSL.html))
|
||||
- Administratorrechte für die Hostnamen-Konfiguration
|
||||
|
||||
## Installationsschritte
|
||||
|
||||
### 1. Projekt herunterladen
|
||||
|
||||
Klonen Sie das Repository oder entpacken Sie das Archiv in ein Verzeichnis Ihrer Wahl.
|
||||
|
||||
### 2. Hostnamen konfigurieren
|
||||
|
||||
#### Windows:
|
||||
|
||||
1. PowerShell als Administrator starten (Rechtsklick -> "Als Administrator ausführen")
|
||||
2. Zum Projektverzeichnis navigieren:
|
||||
```powershell
|
||||
cd C:\Pfad\zum\Projektarbeit-MYP
|
||||
```
|
||||
3. Hostnamen-Konfigurationsskript ausführen:
|
||||
```powershell
|
||||
.\setup_hosts.ps1
|
||||
```
|
||||
|
||||
#### Linux/macOS:
|
||||
|
||||
1. Terminal öffnen
|
||||
2. Zum Projektverzeichnis navigieren:
|
||||
```bash
|
||||
cd /pfad/zum/Projektarbeit-MYP
|
||||
```
|
||||
3. Hostnamen-Konfigurationsskript ausführen:
|
||||
```bash
|
||||
sudo ./setup_hosts.sh
|
||||
```
|
||||
|
||||
### 3. SSL-Zertifikate generieren
|
||||
|
||||
#### Windows:
|
||||
|
||||
1. PowerShell als Administrator starten (falls nicht bereits offen)
|
||||
2. Zum Projektverzeichnis navigieren
|
||||
3. SSL-Zertifikat-Generierungsskript ausführen:
|
||||
```powershell
|
||||
.\generate_ssl_certs.ps1
|
||||
```
|
||||
|
||||
#### Linux/macOS:
|
||||
|
||||
1. Terminal öffnen (falls nicht bereits offen)
|
||||
2. Zum Projektverzeichnis navigieren
|
||||
3. SSL-Zertifikat-Generierungsskript ausführen:
|
||||
```bash
|
||||
sudo ./generate_ssl_certs.sh
|
||||
```
|
||||
|
||||
### 4. Docker-Container starten
|
||||
|
||||
Nachdem die Hostnamen und SSL-Zertifikate konfiguriert wurden, können Sie die Anwendung starten:
|
||||
|
||||
```
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
Dies startet alle erforderlichen Container:
|
||||
- Backend (Flask) auf `raspberrypi:443` mit HTTPS
|
||||
- Frontend (Next.js) auf Port 3000
|
||||
- Caddy Proxy auf `m040tbaraspi001.de040.corpintra.net:443` mit HTTPS
|
||||
|
||||
### 5. Zugriff auf die Anwendung
|
||||
|
||||
Nach dem Start können Sie auf die Anwendung über folgende URLs zugreifen:
|
||||
|
||||
- **Frontend**: https://m040tbaraspi001.de040.corpintra.net/
|
||||
- **Backend API**: https://raspberrypi/
|
||||
|
||||
Da selbstsignierte Zertifikate verwendet werden, zeigt Ihr Browser beim ersten Zugriff eine Sicherheitswarnung an. Klicken Sie auf "Erweitert" und dann auf "Fortfahren" (oder ähnliche Option je nach Browser), um auf die Anwendung zuzugreifen.
|
||||
|
||||
## Fehlerbehebung
|
||||
|
||||
### Problem: Zertifikatsfehler im Browser
|
||||
|
||||
1. Überprüfen Sie, ob die SSL-Zertifikate korrekt generiert wurden
|
||||
2. Führen Sie `generate_ssl_certs.ps1` (Windows) oder `generate_ssl_certs.sh` (Linux/macOS) erneut aus
|
||||
3. Starten Sie die Docker-Container neu: `docker-compose restart`
|
||||
|
||||
### Problem: Hostnamen werden nicht aufgelöst
|
||||
|
||||
1. Überprüfen Sie, ob die Hosts-Einträge korrekt in der Hosts-Datei vorhanden sind:
|
||||
- Windows: `type C:\Windows\System32\drivers\etc\hosts`
|
||||
- Linux/macOS: `cat /etc/hosts`
|
||||
2. Führen Sie das Hostnamen-Konfigurationsskript erneut aus
|
||||
3. Stellen Sie sicher, dass die Hostnamen in den Docker-Container-Konfigurationen übereinstimmen
|
||||
|
||||
### Problem: Docker-Container starten nicht
|
||||
|
||||
1. Überprüfen Sie die Docker-Logs: `docker-compose logs`
|
||||
2. Stellen Sie sicher, dass Docker Desktop läuft
|
||||
3. Überprüfen Sie, ob die Ports 80 und 443 bereits verwendet werden:
|
||||
- Windows: `netstat -an | findstr "80 443"`
|
||||
- Linux/macOS: `sudo lsof -i :80,443`
|
||||
|
||||
## Update und Neustart
|
||||
|
||||
Um die Anwendung zu aktualisieren oder nach Änderungen neu zu starten:
|
||||
|
||||
1. Stoppen Sie die Container: `docker-compose down`
|
||||
2. Aktualisieren Sie das Repository (falls erforderlich)
|
||||
3. Bauen Sie die Container neu: `docker-compose build`
|
||||
4. Starten Sie die Container neu: `docker-compose up -d`
|
||||
|
||||
## Zusätzliche Informationen
|
||||
|
||||
Weitere Informationen zur SSL-Konfiguration finden Sie in der Datei `SSL_KONFIGURATION.md`.
|
||||
@@ -7,240 +7,278 @@ Diese Anleitung beschreibt, wie MYP (Manage Your Printer) auf einem Raspberry Pi
|
||||
- Raspberry Pi 4 (oder kompatibel) mit Raspbian/Raspberry Pi OS
|
||||
- Internetverbindung für die Installation (nach der Installation wird keine Verbindung mehr benötigt)
|
||||
- Bildschirm, Tastatur und Maus für die Einrichtung
|
||||
- Mindestens 2GB freier Festplattenplatz
|
||||
- Mindestens 512MB RAM (empfohlen: 1GB+)
|
||||
|
||||
## Komponenten des Kiosk-Modus
|
||||
|
||||
Die Kiosk-Einrichtung besteht aus mehreren Komponenten:
|
||||
|
||||
1. **Flask-Backend-Dienst**: Systemd-Service zum Starten der MYP-Anwendung
|
||||
2. **Chromium im Kiosk-Modus**: Browserinstanz, die das Dashboard anzeigt
|
||||
3. **Watchdog**: Überwacht den Browser und das Backend, startet bei Bedarf neu
|
||||
1. **MYP HTTPS-Backend-Dienst**: Systemd-Service zum Starten der MYP-Anwendung auf Port 5000
|
||||
2. **Kiosk-Benutzer**: Separater Benutzer für den Browser-Betrieb
|
||||
3. **Chromium im Kiosk-Modus**: Optimierte Browserinstanz mit erweiterten Kiosk-Features
|
||||
4. **Watchdog-Services**: Mehrere Überwachungsdienste für Backend und Browser
|
||||
5. **Firewall-Service**: Automatische Netzwerksicherheit
|
||||
|
||||
## Automatische Installation
|
||||
## Automatische Installation (Empfohlen)
|
||||
|
||||
Für die automatische Installation kann das mitgelieferte Setup-Script verwendet werden:
|
||||
Die automatische Installation erfolgt über das konsolidierte Setup-Script im Backend-Verzeichnis:
|
||||
|
||||
```bash
|
||||
chmod +x setup.sh
|
||||
./setup.sh
|
||||
cd backend
|
||||
sudo chmod +x setup.sh
|
||||
sudo ./setup.sh
|
||||
```
|
||||
|
||||
Dieses Script führt alle notwendigen Schritte aus:
|
||||
- Installation der benötigten Pakete
|
||||
- Kopieren der MYP-Anwendung nach `/opt/myp`
|
||||
- Einrichtung der Python-Umgebung und Installation der Abhängigkeiten
|
||||
- Konfiguration der Systemd-Dienste
|
||||
- Einrichtung des Kiosk-Modus
|
||||
- Einrichtung des Watchdogs
|
||||
Das Setup-Script bietet folgende Features:
|
||||
- **Robuste Installation** mit Retry-Mechanismen
|
||||
- **Umfangreiches Logging** in `backend/logs/`
|
||||
- **System-Validierung** vor Installation
|
||||
- **Automatische Abhängigkeitsauflösung**
|
||||
- **Konfiguration aller Services**
|
||||
- **Firewall-Setup**
|
||||
- **Automatischer Kiosk-Benutzer**
|
||||
|
||||
Nach der Ausführung des Scripts muss noch der automatische Login aktiviert werden:
|
||||
```bash
|
||||
sudo raspi-config
|
||||
# 1 System Options → S5 Boot/Auto Login → B4 Desktop Autologin
|
||||
```
|
||||
### Installation-Logs
|
||||
|
||||
## Manuelle Installation
|
||||
Das Setup-Script erstellt detaillierte Logs:
|
||||
- `backend/logs/install.log` - Vollständiges Installations-Log
|
||||
- `backend/logs/errors.log` - Nur Fehler
|
||||
- `backend/logs/warnings.log` - Nur Warnungen
|
||||
- `backend/logs/debug.log` - Debug-Informationen
|
||||
- `backend/logs/install-summary.txt` - Zusammenfassung
|
||||
|
||||
Falls eine manuelle Installation bevorzugt wird, können die folgenden Schritte ausgeführt werden:
|
||||
## Systemd-Services (Automatisch installiert)
|
||||
|
||||
### 1. Pakete installieren
|
||||
|
||||
```bash
|
||||
sudo apt update
|
||||
sudo apt install -y python3 python3-pip python3-venv chromium-browser \
|
||||
unclutter xdotool xscreensaver git
|
||||
```
|
||||
|
||||
### 2. MYP nach /opt/myp kopieren
|
||||
|
||||
```bash
|
||||
sudo mkdir -p /opt/myp
|
||||
sudo chown $USER:$USER /opt/myp
|
||||
cp -r ./myp/* /opt/myp
|
||||
cd /opt/myp
|
||||
```
|
||||
|
||||
### 3. Python-Umgebung und Abhängigkeiten einrichten
|
||||
|
||||
```bash
|
||||
python3 -m venv .venv
|
||||
source .venv/bin/activate
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
|
||||
### 4. Systemd-Dienst für das Flask-Backend
|
||||
|
||||
Datei erstellen: `/etc/systemd/system/myp.service`
|
||||
Das Setup-Script installiert folgende Services:
|
||||
|
||||
### 1. MYP HTTPS-Backend (`myp-https.service`)
|
||||
```ini
|
||||
[Unit]
|
||||
Description=MYP Flask Backend
|
||||
Description=MYP Druckerverwaltung HTTP Backend (Port 5000)
|
||||
After=network-online.target
|
||||
Wants=network-online.target
|
||||
|
||||
[Service]
|
||||
User=pi
|
||||
Type=simple
|
||||
User=root
|
||||
WorkingDirectory=/opt/myp
|
||||
ExecStart=/opt/myp/.venv/bin/python /opt/myp/app.py
|
||||
ExecStart=/usr/bin/python3 /opt/myp/app.py --production
|
||||
Restart=always
|
||||
Environment=PYTHONUNBUFFERED=1
|
||||
Environment=FLASK_ENV=production
|
||||
Environment=FLASK_PORT=5000
|
||||
Environment=KIOSK_MODE=true
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
Dienst aktivieren:
|
||||
### 2. Kiosk-Browser (`myp-kiosk.service`)
|
||||
- Startet Chromium im optimierten Kiosk-Modus
|
||||
- Wartet automatisch auf Backend-Verfügbarkeit
|
||||
- Umfangreiche Browser-Optimierungen
|
||||
- Automatischer Neustart bei Fehlern
|
||||
|
||||
### 3. Watchdog-Services
|
||||
- `kiosk-watchdog.service` - Überwacht Browser und Backend
|
||||
- `kiosk-watchdog-python.service` - Python-basierte Überwachung
|
||||
|
||||
### 4. Firewall-Service (`myp-firewall.service`)
|
||||
- Automatische Netzwerksicherheit
|
||||
- Port-Management
|
||||
|
||||
## Manuelle Installation (Nur bei Bedarf)
|
||||
|
||||
Falls die automatische Installation nicht verwendet werden kann:
|
||||
|
||||
### 1. Pakete installieren
|
||||
```bash
|
||||
sudo apt update
|
||||
sudo apt install -y python3 python3-pip python3-venv chromium-browser \
|
||||
unclutter xdotool curl git
|
||||
```
|
||||
|
||||
### 2. MYP-Backend nach /opt/myp kopieren
|
||||
```bash
|
||||
sudo mkdir -p /opt/myp
|
||||
sudo cp -r ./backend/* /opt/myp/
|
||||
cd /opt/myp
|
||||
sudo pip3 install -r requirements.txt --break-system-packages
|
||||
```
|
||||
|
||||
### 3. Kiosk-Benutzer erstellen
|
||||
```bash
|
||||
sudo useradd -m -s /bin/bash kiosk
|
||||
sudo usermod -a -G video,audio kiosk
|
||||
```
|
||||
|
||||
### 4. Systemd-Services installieren
|
||||
```bash
|
||||
sudo cp /opt/myp/systemd/*.service /etc/systemd/system/
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl enable --now myp.service
|
||||
sudo systemctl enable myp-https.service
|
||||
sudo systemctl enable myp-kiosk.service
|
||||
sudo systemctl enable kiosk-watchdog.service
|
||||
sudo systemctl enable myp-firewall.service
|
||||
```
|
||||
|
||||
### 5. Kiosk-Script einrichten
|
||||
|
||||
Datei erstellen: `/home/pi/kiosk.sh`
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
|
||||
# Bildschirm-Blanking verhindern
|
||||
xset s off
|
||||
xset s noblank
|
||||
xset -dpms
|
||||
|
||||
# Mauszeiger ausblenden
|
||||
unclutter -idle 0.5 -root &
|
||||
|
||||
# Chromium-Crash-Dialoge unterdrücken
|
||||
sed -i 's/"exited_cleanly":false/"exited_cleanly":true/' \
|
||||
"$HOME/.config/chromium/Default/Preferences" 2>/dev/null || true
|
||||
sed -i 's/"exit_type":"Crashed"/"exit_type":"Normal"/' \
|
||||
"$HOME/.config/chromium/Default/Preferences" 2>/dev/null || true
|
||||
|
||||
# Browser starten
|
||||
chromium-browser --kiosk --noerrdialogs --disable-infobars \
|
||||
--window-position=0,0 --app=http://localhost:5000/ &
|
||||
```
|
||||
|
||||
Ausführbar machen:
|
||||
|
||||
```bash
|
||||
chmod +x /home/pi/kiosk.sh
|
||||
```
|
||||
|
||||
### 6. Systemd-User-Dienst für den Browser
|
||||
|
||||
Verzeichnis erstellen:
|
||||
|
||||
```bash
|
||||
mkdir -p /home/pi/.config/systemd/user
|
||||
```
|
||||
|
||||
Datei erstellen: `/home/pi/.config/systemd/user/kiosk.service`
|
||||
|
||||
```ini
|
||||
[Unit]
|
||||
Description=Chromium Kiosk
|
||||
PartOf=graphical-session.target
|
||||
|
||||
[Service]
|
||||
Type=forking
|
||||
ExecStart=/home/pi/kiosk.sh
|
||||
Restart=on-abort
|
||||
|
||||
[Install]
|
||||
WantedBy=xsession.target
|
||||
```
|
||||
|
||||
Dienst aktivieren:
|
||||
|
||||
```bash
|
||||
systemctl --user daemon-reload
|
||||
systemctl --user enable kiosk.service
|
||||
sudo loginctl enable-linger pi
|
||||
```
|
||||
|
||||
### 7. Watchdog einrichten
|
||||
|
||||
Datei erstellen: `/home/pi/watchdog.sh`
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
# MYP Watchdog für Chromium Browser
|
||||
|
||||
# Funktion zum Loggen von Nachrichten
|
||||
log() {
|
||||
echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" >> /home/pi/myp-watchdog.log
|
||||
}
|
||||
|
||||
# Prüfen, ob Chromium läuft
|
||||
if ! pgrep -x "chromium-browse" > /dev/null; then
|
||||
log "Chromium nicht gefunden - starte neu"
|
||||
|
||||
# Alle eventuell noch vorhandenen Chromium-Prozesse beenden
|
||||
pkill -f chromium || true
|
||||
|
||||
# Warten bis alle Prozesse beendet sind
|
||||
sleep 2
|
||||
|
||||
# Kiosk-Script neu starten
|
||||
/home/pi/kiosk.sh
|
||||
|
||||
log "Chromium neugestartet"
|
||||
fi
|
||||
|
||||
# Prüfen, ob MYP Flask-Dienst läuft
|
||||
if ! systemctl is-active --quiet myp.service; then
|
||||
log "MYP Flask-Dienst ist nicht aktiv - starte neu"
|
||||
|
||||
# Dienst neustarten
|
||||
sudo systemctl restart myp.service
|
||||
|
||||
log "MYP Flask-Dienst neugestartet"
|
||||
fi
|
||||
|
||||
exit 0
|
||||
```
|
||||
|
||||
Ausführbar machen und Cron-Job einrichten:
|
||||
|
||||
```bash
|
||||
chmod +x /home/pi/watchdog.sh
|
||||
(crontab -l 2>/dev/null || echo "") | grep -v "watchdog.sh" | { cat; echo "*/5 * * * * /home/pi/watchdog.sh > /dev/null 2>&1"; } | crontab -
|
||||
```
|
||||
|
||||
### 8. Automatischen Desktop-Login einschalten
|
||||
|
||||
### 5. Automatischen Desktop-Login einschalten
|
||||
```bash
|
||||
sudo raspi-config
|
||||
# 1 System Options → S5 Boot/Auto Login → B4 Desktop Autologin
|
||||
```
|
||||
|
||||
### 9. Bildschirm nie ausschalten
|
||||
|
||||
```bash
|
||||
sudo sed -i 's/#BLANK_TIME=.*/BLANK_TIME=0/' /etc/xdg/lxsession/LXDE-pi/autostart
|
||||
```
|
||||
|
||||
## Ablauf beim Booten
|
||||
|
||||
1. Der Raspberry Pi startet und fährt bis zum Multi-User-Target hoch
|
||||
2. `myp.service` wird gestartet und das Flask-Backend sowie der Plug-Scheduler laufen
|
||||
3. LightDM startet und meldet den Benutzer `pi` automatisch an
|
||||
4. Nach dem Anmelden wird der User-Scope geladen und `kiosk.service` gestartet
|
||||
5. `kiosk.sh` startet Chromium im Kiosk-Modus und öffnet die MYP-Oberfläche
|
||||
6. Der Watchdog-Cron-Job überwacht alle 5 Minuten, ob alles läuft
|
||||
1. **System-Start**: Raspberry Pi fährt bis zum Multi-User-Target hoch
|
||||
2. **Backend-Start**: `myp-https.service` startet das Flask-Backend auf Port 5000
|
||||
3. **Firewall-Start**: `myp-firewall.service` konfiguriert Netzwerksicherheit
|
||||
4. **Desktop-Login**: LightDM startet und meldet den Benutzer automatisch an
|
||||
5. **Kiosk-Start**: `myp-kiosk.service` wartet auf Backend und startet Chromium
|
||||
6. **Watchdog-Aktivierung**: Überwachungsservices starten kontinuierliche Überwachung
|
||||
|
||||
## Browser-Optimierungen
|
||||
|
||||
Der Kiosk-Service startet Chromium mit umfangreichen Optimierungen:
|
||||
|
||||
### Performance-Optimierungen
|
||||
- `--disable-gpu-sandbox`
|
||||
- `--disable-software-rasterizer`
|
||||
- `--enable-features=VaapiVideoDecoder`
|
||||
- `--memory-pressure-off`
|
||||
- `--max_old_space_size=512`
|
||||
|
||||
### Kiosk-spezifische Features
|
||||
- `--kiosk` (Vollbild-Modus)
|
||||
- `--hide-scrollbars`
|
||||
- `--disable-pinch`
|
||||
- `--no-first-run`
|
||||
- `--autoplay-policy=no-user-gesture-required`
|
||||
|
||||
### Sicherheits-Anpassungen
|
||||
- `--ignore-certificate-errors`
|
||||
- `--disable-web-security` (für lokale Anwendung)
|
||||
- `--no-sandbox`
|
||||
|
||||
## Fehlerbehebung
|
||||
|
||||
- **MYP startet nicht**: `systemctl status myp.service` zeigt den Status des Dienstes
|
||||
- **Browser startet nicht**: `systemctl --user status kiosk.service` zeigt den Status des Kiosk-Dienstes
|
||||
- **Watchdog-Logs**: In `/home/pi/myp-watchdog.log` werden Probleme und Neustarts protokolliert
|
||||
### Service-Status prüfen
|
||||
```bash
|
||||
# Backend-Status
|
||||
sudo systemctl status myp-https.service
|
||||
|
||||
## Anpassung für andere Benutzer
|
||||
# Kiosk-Status
|
||||
sudo systemctl status myp-kiosk.service
|
||||
|
||||
Falls ein anderer Benutzer als `pi` verwendet wird, müssen folgende Anpassungen vorgenommen werden:
|
||||
# Watchdog-Status
|
||||
sudo systemctl status kiosk-watchdog.service
|
||||
|
||||
1. In `myp.service`: `User=` auf den entsprechenden Benutzer ändern
|
||||
2. Pfade in `kiosk.sh` und `kiosk.service` anpassen
|
||||
3. `loginctl enable-linger` für den entsprechenden Benutzer aktivieren
|
||||
# Alle MYP-Services
|
||||
sudo systemctl status myp-*
|
||||
```
|
||||
|
||||
### Logs einsehen
|
||||
```bash
|
||||
# Backend-Logs
|
||||
sudo journalctl -u myp-https.service -f
|
||||
|
||||
# Kiosk-Logs
|
||||
sudo journalctl -u myp-kiosk.service -f
|
||||
|
||||
# System-Logs
|
||||
tail -f /var/log/myp-kiosk.log
|
||||
|
||||
# Installation-Logs (falls verfügbar)
|
||||
cat backend/logs/install-summary.txt
|
||||
```
|
||||
|
||||
### Häufige Probleme
|
||||
|
||||
**Backend startet nicht:**
|
||||
- Prüfen: `sudo systemctl status myp-https.service`
|
||||
- Log: `sudo journalctl -u myp-https.service`
|
||||
- Port-Konflikt: `sudo netstat -tulpn | grep :5000`
|
||||
|
||||
**Browser startet nicht:**
|
||||
- X11-Display prüfen: `DISPLAY=:0 xset q`
|
||||
- Kiosk-Benutzer prüfen: `id kiosk`
|
||||
- Browser installiert: `which chromium-browser`
|
||||
|
||||
**Watchdog meldet Probleme:**
|
||||
- Watchdog-Log: `sudo journalctl -u kiosk-watchdog.service`
|
||||
- System-Ressourcen: `free -m && df -h`
|
||||
|
||||
## Konfiguration anpassen
|
||||
|
||||
### Backend-Port ändern
|
||||
Bearbeiten Sie `/etc/systemd/system/myp-https.service`:
|
||||
```ini
|
||||
Environment=FLASK_PORT=8080
|
||||
```
|
||||
|
||||
### Browser-Startseite ändern
|
||||
Bearbeiten Sie `/etc/systemd/system/myp-kiosk.service` und ändern Sie:
|
||||
```bash
|
||||
TARGET_URL="http://localhost:5000"
|
||||
```
|
||||
|
||||
### Watchdog-Intervall anpassen
|
||||
Die Watchdog-Services können über ihre Konfigurationsdateien angepasst werden.
|
||||
|
||||
## Sicherheitshinweise
|
||||
|
||||
- Das System läuft mit root-Berechtigung für das Backend (für Druckerzugriff erforderlich)
|
||||
- Der Browser läuft als separater `kiosk`-Benutzer
|
||||
- Firewall ist automatisch konfiguriert
|
||||
- Nur Port 5000 ist für lokale Verbindungen geöffnet
|
||||
- HTTPS-Zertifikate werden automatisch generiert
|
||||
|
||||
## Performance-Optimierung
|
||||
|
||||
Für optimale Performance auf Raspberry Pi:
|
||||
|
||||
1. **GPU-Memory erhöhen:**
|
||||
```bash
|
||||
echo "gpu_mem=128" | sudo tee -a /boot/config.txt
|
||||
```
|
||||
|
||||
2. **Swap verringern:**
|
||||
```bash
|
||||
echo "vm.swappiness=10" | sudo tee -a /etc/sysctl.conf
|
||||
```
|
||||
|
||||
3. **I/O-Scheduler optimieren:**
|
||||
```bash
|
||||
echo "deadline" | sudo tee /sys/block/mmcblk0/queue/scheduler
|
||||
```
|
||||
|
||||
## Updates
|
||||
|
||||
Updates der MYP-Anwendung:
|
||||
```bash
|
||||
cd /opt/myp
|
||||
sudo git pull # falls Git-Repository
|
||||
sudo systemctl restart myp-https.service
|
||||
sudo systemctl restart myp-kiosk.service
|
||||
```
|
||||
|
||||
## Deinstallation
|
||||
|
||||
Vollständige Entfernung:
|
||||
```bash
|
||||
sudo systemctl disable --now myp-https.service myp-kiosk.service
|
||||
sudo systemctl disable --now kiosk-watchdog.service myp-firewall.service
|
||||
sudo rm /etc/systemd/system/myp-*.service
|
||||
sudo rm /etc/systemd/system/kiosk-*.service
|
||||
sudo systemctl daemon-reload
|
||||
sudo userdel -r kiosk
|
||||
sudo rm -rf /opt/myp
|
||||
```
|
||||
|
||||
## Support
|
||||
|
||||
Bei Problemen:
|
||||
1. Prüfen Sie die Logs in `backend/logs/`
|
||||
2. Verwenden Sie `sudo journalctl -u service-name` für Service-Logs
|
||||
3. Stellen Sie sicher, dass alle Voraussetzungen erfüllt sind
|
||||
4. Führen Sie das Setup-Script erneut aus bei Installations-Problemen
|
||||
@@ -1,153 +0,0 @@
|
||||
# MYP Frontend Produktions-Deployment
|
||||
|
||||
## Übersicht
|
||||
|
||||
Das Frontend läuft jetzt auf **Port 80/443** mit **selbstsigniertem Zertifikat** über **Caddy** als Reverse Proxy. Port 3000 wurde komplett entfernt.
|
||||
|
||||
## Architektur
|
||||
|
||||
```
|
||||
Internet/LAN → Caddy (Port 80/443) → Next.js Frontend (Port 80) → Backend API (raspberrypi:443)
|
||||
```
|
||||
|
||||
## Deployment
|
||||
|
||||
### Schnellstart
|
||||
|
||||
```bash
|
||||
cd frontend
|
||||
./deploy-production.sh
|
||||
```
|
||||
|
||||
### Manuelles Deployment
|
||||
|
||||
```bash
|
||||
cd frontend
|
||||
|
||||
# Container stoppen
|
||||
docker-compose -f docker-compose.production.yml down
|
||||
|
||||
# Neu bauen und starten
|
||||
docker-compose -f docker-compose.production.yml up --build -d
|
||||
|
||||
# Status prüfen
|
||||
docker-compose -f docker-compose.production.yml ps
|
||||
|
||||
# Logs anzeigen
|
||||
docker-compose -f docker-compose.production.yml logs -f
|
||||
```
|
||||
|
||||
## Konfiguration
|
||||
|
||||
### SSL-Zertifikate
|
||||
|
||||
- **Automatisch generiert**: Caddy generiert automatisch selbstsignierte Zertifikate
|
||||
- **Speicherort**: `./certs/` (wird automatisch erstellt)
|
||||
- **Konfiguration**: `tls internal` in der Caddyfile
|
||||
|
||||
### Ports
|
||||
|
||||
- **HTTP**: Port 80
|
||||
- **HTTPS**: Port 443
|
||||
- **Frontend intern**: Port 80 (nicht nach außen exponiert)
|
||||
|
||||
### Backend-Verbindung
|
||||
|
||||
- **Backend URL**: `https://raspberrypi:443`
|
||||
- **API Prefix**: `/api/*` wird an Backend weitergeleitet
|
||||
- **Health Check**: `/health` wird an Backend weitergeleitet
|
||||
|
||||
## Dateien
|
||||
|
||||
### Wichtige Konfigurationsdateien
|
||||
|
||||
- `docker-compose.production.yml` - Produktions-Docker-Konfiguration
|
||||
- `docker/caddy/Caddyfile` - Caddy Reverse Proxy Konfiguration
|
||||
- `Dockerfile` - Frontend Container (Port 80)
|
||||
- `next.config.js` - Next.js Konfiguration (SSL entfernt)
|
||||
|
||||
### Verzeichnisstruktur
|
||||
|
||||
```
|
||||
frontend/
|
||||
├── certs/ # SSL-Zertifikate (automatisch generiert)
|
||||
├── docker/
|
||||
│ └── caddy/
|
||||
│ └── Caddyfile # Caddy Konfiguration
|
||||
├── docker-compose.production.yml # Produktions-Deployment
|
||||
├── deploy-production.sh # Deployment-Script
|
||||
├── Dockerfile # Produktions-Container
|
||||
└── next.config.js # Next.js Konfiguration
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Container Status prüfen
|
||||
|
||||
```bash
|
||||
docker-compose -f docker-compose.production.yml ps
|
||||
```
|
||||
|
||||
### Logs anzeigen
|
||||
|
||||
```bash
|
||||
# Alle Logs
|
||||
docker-compose -f docker-compose.production.yml logs -f
|
||||
|
||||
# Nur Frontend
|
||||
docker-compose -f docker-compose.production.yml logs -f frontend
|
||||
|
||||
# Nur Caddy
|
||||
docker-compose -f docker-compose.production.yml logs -f caddy
|
||||
```
|
||||
|
||||
### SSL-Zertifikate neu generieren
|
||||
|
||||
```bash
|
||||
# Container stoppen
|
||||
docker-compose -f docker-compose.production.yml down
|
||||
|
||||
# Caddy Daten löschen
|
||||
docker volume rm frontend_caddy_data frontend_caddy_config
|
||||
|
||||
# Neu starten
|
||||
docker-compose -f docker-compose.production.yml up --build -d
|
||||
```
|
||||
|
||||
### Container neu bauen
|
||||
|
||||
```bash
|
||||
# Alles stoppen und entfernen
|
||||
docker-compose -f docker-compose.production.yml down --volumes --remove-orphans
|
||||
|
||||
# Images entfernen
|
||||
docker rmi frontend_frontend frontend_caddy
|
||||
|
||||
# Neu bauen
|
||||
docker-compose -f docker-compose.production.yml up --build -d
|
||||
```
|
||||
|
||||
## Sicherheit
|
||||
|
||||
### HTTPS-Header
|
||||
|
||||
Caddy setzt automatisch sichere HTTP-Header:
|
||||
|
||||
- `Strict-Transport-Security`
|
||||
- `X-Content-Type-Options`
|
||||
- `X-Frame-Options`
|
||||
- `Referrer-Policy`
|
||||
|
||||
### Netzwerk-Isolation
|
||||
|
||||
- Frontend und Caddy laufen in eigenem Docker-Netzwerk
|
||||
- Nur Ports 80 und 443 sind nach außen exponiert
|
||||
- Backend-Verbindung über gesichertes HTTPS
|
||||
|
||||
## Offline-Betrieb
|
||||
|
||||
Das Frontend ist für Offline-Betrieb konfiguriert:
|
||||
|
||||
- Keine externen Dependencies zur Laufzeit
|
||||
- Alle Assets sind im Container enthalten
|
||||
- Selbstsignierte Zertifikate benötigen keine externe CA
|
||||
216
docs/ROADMAP.md
216
docs/ROADMAP.md
@@ -1,216 +0,0 @@
|
||||
# Mercedes-Benz MYP Platform - Roadmap
|
||||
|
||||
## Projektübersicht
|
||||
|
||||
Das MYP-Druckerverwaltungssystem besteht aus **zwei eigenständigen Projektarbeiten**:
|
||||
|
||||
- **🏰 Backend-System** (Till Tomczak) - **HAUPT-PRODUKTIONSSYSTEM**
|
||||
- **📊 Frontend-Analytics** (Torben Haack) - **ANALYSE-PROJEKT**
|
||||
|
||||
Das **Backend ist führend** und stellt die vollständige Hardware-Integration sowie APIs bereit.
|
||||
|
||||
## Aktueller Stand (Dezember 2024)
|
||||
|
||||
### ✅ Backend-System (Till Tomczak) - VOLLSTÄNDIG ABGESCHLOSSEN
|
||||
|
||||
#### Produktions-bereite Infrastruktur
|
||||
- ✅ Flask-App mit vollständigem Web-Interface
|
||||
- ✅ SQLAlchemy-Modelle mit Business Logic
|
||||
- ✅ Smart-Plug Integration (TP-Link Tapo P110)
|
||||
- ✅ Raspberry Pi Kiosk-Modus mit Touch-Interface
|
||||
- ✅ HTTPS/SSL-Konfiguration mit selbstsignierten Zertifikaten
|
||||
- ✅ Systemd-Services für automatischen Start
|
||||
- ✅ Offline-Fähigkeit ohne Internet-Abhängigkeiten
|
||||
- ✅ Watchdog-Überwachung für Systemstabilität
|
||||
|
||||
#### User-Management & Sicherheit
|
||||
- ✅ Authentifizierung mit BCrypt-Passwort-Hashing
|
||||
- ✅ Rollenbasierte Zugangskontrolle (Admin/User)
|
||||
- ✅ Session-Management mit Flask-Login
|
||||
- ✅ CSRF-Schutz und Input-Validation
|
||||
- ✅ API-Sicherheit mit Rate-Limiting
|
||||
|
||||
#### Hardware-Integration
|
||||
- ✅ Automatische Drucker Ein-/Ausschaltung
|
||||
- ✅ Zeitgesteuerte Smart-Plug-Steuerung
|
||||
- ✅ Energieverbrauch-Monitoring
|
||||
- ✅ Scheduler für Hintergrundprozesse
|
||||
- ✅ Fehlerbehandlung und Recovery-Mechanismen
|
||||
|
||||
#### Web-Interface & APIs
|
||||
- ✅ Vollständiges responsives Web-Interface
|
||||
- ✅ REST-API-Endpunkte für alle Funktionen
|
||||
- ✅ Admin-Dashboard mit Live-Updates
|
||||
- ✅ Job-Management und Reservierungssystem
|
||||
- ✅ Gast-Zugang für temporäre Benutzer
|
||||
|
||||
### 🔄 Frontend-Analytics (Torben Haack) - IN ENTWICKLUNG
|
||||
|
||||
#### Datenanalyse-Infrastruktur
|
||||
- ✅ Next.js React-Anwendung mit TypeScript
|
||||
- ✅ Drizzle ORM mit SQLite-Datenbank
|
||||
- ✅ Tailwind CSS für responsives Design
|
||||
- ✅ Radix UI Komponenten-Bibliothek
|
||||
- 🔄 Datenvisualisierung mit Recharts
|
||||
- 🔄 Statistische Auswertungen und Reports
|
||||
|
||||
#### Analytics-Features
|
||||
- 🔄 Erweiterte Dashboard-Visualisierungen
|
||||
- 🔄 Datenexport und -import-Funktionen
|
||||
- 🔄 Prozessoptimierung-Tools
|
||||
- 🔄 Trend-Analysen und Forecasting
|
||||
- ⏳ Integration mit Backend-APIs
|
||||
|
||||
## 🎯 Nächste Prioritäten
|
||||
|
||||
### Backend-System (Till Tomczak) - WARTUNG & OPTIMIERUNG
|
||||
|
||||
#### Kurzfristig (1-2 Wochen)
|
||||
- [ ] **Performance-Monitoring** - Systemlast-Überwachung implementieren
|
||||
- [ ] **Backup-Automatisierung** - Tägliche Datenbank-Backups einrichten
|
||||
- [ ] **Logging-Optimierung** - Log-Rotation und erweiterte Fehlerberichterstattung
|
||||
- [ ] **API-Dokumentation** - Swagger/OpenAPI-Spezifikation erstellen
|
||||
|
||||
#### Mittelfristig (1-2 Monate)
|
||||
- [ ] **Erweiterte Hardware-Integration** - Zusätzliche Smart-Plug-Modelle unterstützen
|
||||
- [ ] **Mehrsprachigkeit** - Internationalisierung für weitere Sprachen
|
||||
- [ ] **Mobile-Optimierung** - PWA-Features für Smartphone-Nutzung
|
||||
- [ ] **Drucker-Status-Integration** - Direkte Kommunikation mit 3D-Druckern
|
||||
|
||||
### Frontend-Analytics (Torben Haack) - FERTIGSTELLUNG
|
||||
|
||||
#### Kurzfristig (1-2 Wochen)
|
||||
- [ ] **Dashboard-Vervollständigung** - Alle geplanten Visualisierungen implementieren
|
||||
- [ ] **Backend-API-Integration** - Datenabfrage vom Backend-System
|
||||
- [ ] **Datenexport-Funktionen** - CSV/Excel-Export für Reports
|
||||
- [ ] **User-Interface-Finalisierung** - UX-Optimierung und Testing
|
||||
|
||||
#### Mittelfristig (1-2 Monate)
|
||||
- [ ] **Erweiterte Analytics** - Machine Learning für Nutzungsvorhersagen
|
||||
- [ ] **Reporting-System** - Automatische Berichte und E-Mail-Versand
|
||||
- [ ] **Datenintegration** - Verbindung zu externen Datenquellen
|
||||
- [ ] **Performance-Optimierung** - Caching und Lazy Loading
|
||||
|
||||
## 🔧 System-Integration
|
||||
|
||||
### Backend als Datenquelle
|
||||
Das Backend-System stellt REST-APIs bereit, die von verschiedenen Clients genutzt werden können:
|
||||
|
||||
```
|
||||
Backend-APIs (/api/*)
|
||||
├── Direkter Zugriff → Backend Web-Interface (Produktiv-Einsatz)
|
||||
├── API-Integration → Frontend-Analytics (Datenanalyse)
|
||||
└── Externe Clients → Andere Anwendungen/Tools
|
||||
```
|
||||
|
||||
### Datenfluss-Architektur
|
||||
```
|
||||
[Smart-Plugs] ←→ [Backend-System] ←→ [Web-Interface]
|
||||
↓
|
||||
[REST-APIs]
|
||||
↓
|
||||
[Frontend-Analytics] → [Reports & Visualisierungen]
|
||||
```
|
||||
|
||||
## 📊 Metriken & Erfolgskriterien
|
||||
|
||||
### Backend-System (Produktions-KPIs)
|
||||
- **Uptime**: > 99.9% (24/7-Betrieb)
|
||||
- **Response-Zeit**: < 200ms für Web-Interface
|
||||
- **Hardware-Integration**: 100% zuverlässige Smart-Plug-Steuerung
|
||||
- **Sicherheit**: 0 kritische Sicherheitslücken
|
||||
- **Benutzer-Zufriedenheit**: > 4.5/5 bei Nutzerfeedback
|
||||
|
||||
### Frontend-Analytics (Analytics-KPIs)
|
||||
- **Datenverarbeitungszeit**: < 5 Sekunden für Standard-Reports
|
||||
- **Visualisierung-Performance**: < 1 Sekunde Ladezeit für Charts
|
||||
- **Datengenauigkeit**: 100% konsistente Daten mit Backend
|
||||
- **Benutzerfreundlichkeit**: Intuitive Bedienung ohne Schulung
|
||||
- **Feature-Vollständigkeit**: Alle geplanten Analytics-Funktionen
|
||||
|
||||
## 🛠️ Entwicklungsrichtlinien
|
||||
|
||||
### Backend-Entwicklung (Till Tomczak)
|
||||
- **Stabilität**: Produktions-System darf nicht beeinträchtigt werden
|
||||
- **Sicherheit**: Alle Änderungen müssen Security-Review durchlaufen
|
||||
- **Performance**: Optimierungen nur nach Lasttest-Validierung
|
||||
- **Dokumentation**: Vollständige API-Dokumentation für alle Endpunkte
|
||||
|
||||
### Frontend-Entwicklung (Torben Haack)
|
||||
- **Datenintegrität**: Konsistenz mit Backend-Datenmodell sicherstellen
|
||||
- **Performance**: Effiziente Datenverarbeitung für große Datensätze
|
||||
- **Benutzerfreundlichkeit**: Intuitive UI/UX für Analytics-Workflows
|
||||
- **Erweiterbarkeit**: Modularer Aufbau für zukünftige Analytics-Features
|
||||
|
||||
## 🔄 Deployment-Strategien
|
||||
|
||||
### Backend (Produktions-Deployment)
|
||||
```bash
|
||||
# Raspberry Pi Produktions-Update
|
||||
cd backend
|
||||
git pull origin main
|
||||
sudo systemctl restart myp-https.service
|
||||
sudo systemctl status myp-https.service
|
||||
```
|
||||
|
||||
### Frontend (Analytics-Deployment)
|
||||
```bash
|
||||
# Next.js Build und Deployment
|
||||
cd frontend
|
||||
pnpm build
|
||||
pnpm start
|
||||
# oder Docker-Container für Produktions-Umgebung
|
||||
```
|
||||
|
||||
## 🚨 Risikomanagement
|
||||
|
||||
### Backend-Risiken (Mitigation)
|
||||
- **Hardware-Ausfall**: Backup-Raspberry Pi bereithalten
|
||||
- **Smart-Plug-Verbindung**: Manuelle Fallback-Steuerung
|
||||
- **Datenbank-Korruption**: Tägliche automatische Backups
|
||||
- **Sicherheitslücke**: Regelmäßige Security-Audits
|
||||
|
||||
### Frontend-Risiken (Mitigation)
|
||||
- **Dateninkonsistenz**: Validierung gegen Backend-APIs
|
||||
- **Performance-Probleme**: Progressives Laden großer Datensätze
|
||||
- **Browser-Kompatibilität**: Cross-Browser-Testing
|
||||
- **Abhängigkeiten**: Regelmäßige Dependency-Updates
|
||||
|
||||
## 📅 Zeitplan & Meilensteine
|
||||
|
||||
### Q1 2025 - Backend Optimierung
|
||||
- **Januar**: Performance-Monitoring und Backup-Automatisierung
|
||||
- **Februar**: API-Dokumentation und zusätzliche Hardware-Tests
|
||||
- **März**: Langzeit-Stabilitätstests und Optimierungen
|
||||
|
||||
### Q1 2025 - Frontend Completion
|
||||
- **Januar**: Dashboard-Vervollständigung und Backend-Integration
|
||||
- **Februar**: Datenexport-Features und UX-Optimierung
|
||||
- **März**: Testing, Dokumentation und Deployment-Vorbereitung
|
||||
|
||||
### Q2 2025 - Integration & Expansion
|
||||
- **April**: Vollständige System-Integration testen
|
||||
- **Mai**: Erweiterte Features und Performance-Optimierung
|
||||
- **Juni**: Produktions-Rollout und User-Training
|
||||
|
||||
## 📚 Dokumentations-Roadmap
|
||||
|
||||
### Backend-Dokumentation (Till Tomczak)
|
||||
- [ ] **API-Spezifikation** - OpenAPI/Swagger-Dokumentation
|
||||
- [ ] **Hardware-Setup-Guide** - Raspberry Pi Konfiguration
|
||||
- [ ] **Troubleshooting-Guide** - Häufige Probleme und Lösungen
|
||||
- [ ] **Sicherheits-Handbuch** - Security Best Practices
|
||||
|
||||
### Frontend-Dokumentation (Torben Haack)
|
||||
- [ ] **Analytics-Benutzerhandbuch** - Dashboard-Funktionen erklärt
|
||||
- [ ] **Datenmodell-Dokumentation** - Datenstrukturen und -flüsse
|
||||
- [ ] **Entwickler-Guide** - Setup und Erweiterung der Analytics
|
||||
- [ ] **Report-Templates** - Vorgefertigte Analyse-Vorlagen
|
||||
|
||||
---
|
||||
|
||||
**Backend-Verantwortlich**: Till Tomczak (Produktions-System)
|
||||
**Frontend-Verantwortlich**: Torben Haack (Analytics-System)
|
||||
**Letzte Aktualisierung**: Dezember 2024
|
||||
**Nächste Review**: In 2 Wochen
|
||||
**System-Architektur**: Backend-zentriert mit optionaler Frontend-Analytics
|
||||
@@ -12,22 +12,20 @@ Diese Dokumentation beschreibt die Sicherheitsmaßnahmen der MYP Platform, insbe
|
||||
|
||||
### Systemhärtung
|
||||
- Kernel-Parameter für erhöhte Sicherheit
|
||||
- SSH-Härtung mit Fail2Ban
|
||||
- Firewall-Konfiguration (UFW)
|
||||
- Automatische Sicherheitsupdates
|
||||
- Firewall-Konfiguration
|
||||
|
||||
### Überwachung
|
||||
- Audit-Logs für Systemzugriffe
|
||||
- Monitoring verdächtiger Prozesse
|
||||
- Integritätsprüfung des Dateisystems
|
||||
- Automatische Benachrichtigungen bei Sicherheitsereignissen
|
||||
- Benachrichtigungen bei Sicherheitsereignissen
|
||||
|
||||
## Netzwerksicherheit
|
||||
|
||||
### Firewall-Regeln
|
||||
```bash
|
||||
# Eingehende Verbindungen
|
||||
Port 22 (SSH) - Nur von lokalen Netzwerken
|
||||
Port 22 (SSH)
|
||||
Port 80 (HTTP) - Für Web-Interface
|
||||
Port 443 (HTTPS) - Für sichere Verbindungen
|
||||
|
||||
@@ -42,11 +40,6 @@ Nur notwendige Dienste erlaubt
|
||||
|
||||
## Authentifizierung
|
||||
|
||||
### Benutzerrollen
|
||||
- **Admin**: Vollzugriff auf alle Funktionen
|
||||
- **User**: Eingeschränkter Zugriff auf eigene Daten
|
||||
- **Kiosk**: Nur Anzeige-Berechtigung
|
||||
|
||||
### Session-Management
|
||||
- Sichere Session-Cookies
|
||||
- Automatische Abmeldung nach Inaktivität
|
||||
@@ -64,27 +57,6 @@ Nur notwendige Dienste erlaubt
|
||||
- Strukturierte Logs für Audit-Zwecke
|
||||
- Automatische Log-Rotation
|
||||
|
||||
## Kiosk-Deaktivierung
|
||||
|
||||
### Notfall-Deaktivierung
|
||||
1. Zugriff auf Terminal (Strg+Alt+T)
|
||||
2. API-Aufruf: `POST /api/kiosk/deactivate`
|
||||
3. Passwort eingeben: `744563017196A`
|
||||
4. System wird automatisch neu gestartet
|
||||
|
||||
### Manuelle Deaktivierung
|
||||
```bash
|
||||
# Service stoppen
|
||||
sudo systemctl stop myp-kiosk
|
||||
sudo systemctl disable myp-kiosk
|
||||
|
||||
# Desktop wiederherstellen
|
||||
sudo systemctl set-default graphical.target
|
||||
|
||||
# Neustart
|
||||
sudo reboot
|
||||
```
|
||||
|
||||
## Wartung
|
||||
|
||||
### Regelmäßige Aufgaben
|
||||
@@ -102,10 +74,6 @@ systemctl status myp-backend
|
||||
# Logs überprüfen
|
||||
journalctl -u myp-kiosk -f
|
||||
tail -f /var/log/myp/security.log
|
||||
|
||||
# Netzwerk-Status
|
||||
ufw status
|
||||
fail2ban-client status
|
||||
```
|
||||
|
||||
## Incident Response
|
||||
@@ -117,11 +85,6 @@ fail2ban-client status
|
||||
4. System neu aufsetzen
|
||||
5. Sicherheitsmaßnahmen verstärken
|
||||
|
||||
### Kontakte
|
||||
- IT-Sicherheit: security@mercedes-benz.com
|
||||
- System-Administrator: admin@mercedes-benz.com
|
||||
- Notfall-Hotline: +49 711 17-0
|
||||
|
||||
## Compliance
|
||||
|
||||
### Standards
|
||||
@@ -165,13 +128,6 @@ net.ipv4.conf.default.accept_redirects = 0
|
||||
2. **Passwort funktioniert nicht**: Hash-Integrität überprüfen
|
||||
3. **Netzwerk blockiert**: Firewall-Regeln kontrollieren
|
||||
|
||||
### Debug-Modus
|
||||
```bash
|
||||
# Kiosk im Debug-Modus starten
|
||||
sudo systemctl stop myp-kiosk
|
||||
sudo -u kiosk /opt/myp/kiosk/start_kiosk.sh --debug
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**WICHTIG**: Diese Dokumentation enthält sicherheitskritische Informationen und darf nur autorisierten Personen zugänglich gemacht werden.
|
||||
@@ -15,84 +15,3 @@ Das System besteht aus zwei Hauptkomponenten:
|
||||
- Hostname: `m040tbaraspi001.de040.corpintra.net`
|
||||
- Port: 443 (HTTPS)
|
||||
- SSL: Selbstsigniertes Zertifikat durch Caddy
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- Docker und Docker Compose müssen installiert sein
|
||||
- OpenSSL für die Zertifikatgenerierung
|
||||
- Administratorrechte für das Einrichten der Hostnamen
|
||||
|
||||
## Einrichtung
|
||||
|
||||
### 1. Hostnamen konfigurieren
|
||||
|
||||
Für die korrekte Funktion des Systems müssen die folgenden Hostnamen in der `/etc/hosts` (Linux/macOS) oder `C:\Windows\System32\drivers\etc\hosts` (Windows) Datei eingerichtet werden:
|
||||
|
||||
```
|
||||
127.0.0.1 m040tbaraspi001.de040.corpintra.net m040tbaraspi001
|
||||
127.0.0.1 raspberrypi
|
||||
```
|
||||
|
||||
Verwenden Sie für die automatische Konfiguration die bereitgestellten Skripte:
|
||||
|
||||
- Windows: `setup_hosts.ps1` (als Administrator ausführen)
|
||||
- Linux/macOS: `setup_hosts.sh` (mit sudo ausführen)
|
||||
|
||||
### 2. SSL-Zertifikate generieren
|
||||
|
||||
Für die HTTPS-Kommunikation werden selbstsignierte Zertifikate verwendet:
|
||||
|
||||
- Windows: `generate_ssl_certs.ps1` (als Administrator ausführen)
|
||||
- Linux/macOS: `generate_ssl_certs.sh` (mit sudo ausführen)
|
||||
|
||||
Die Zertifikate werden im Verzeichnis `backend/instance/ssl/` gespeichert:
|
||||
|
||||
- Backend: `myp.crt` und `myp.key`
|
||||
- Frontend: `frontend.crt` und `frontend.key`
|
||||
|
||||
### 3. System starten
|
||||
|
||||
Nach der Konfiguration kann das System mit folgendem Befehl gestartet werden:
|
||||
|
||||
```
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
## Zugriff auf das System
|
||||
|
||||
- **Backend-API**: https://raspberrypi/
|
||||
- **Frontend-Anwendung**: https://m040tbaraspi001.de040.corpintra.net/
|
||||
|
||||
Beim ersten Zugriff wird der Browser eine Sicherheitswarnung anzeigen, da selbstsignierte Zertifikate verwendet werden. Diese Warnung kann akzeptiert werden, um fortzufahren.
|
||||
|
||||
## Konfigurationsdateien
|
||||
|
||||
Die SSL-Konfiguration ist in folgenden Dateien definiert:
|
||||
|
||||
- `backend/app/config/settings.py`: Backend-SSL-Konfiguration
|
||||
- `frontend/docker/caddy/Caddyfile`: Frontend-Proxy-Konfiguration mit SSL
|
||||
- `docker-compose.yml`: Docker-Container-Konfiguration mit Hostnamen und Ports
|
||||
|
||||
## Fehlerbehebung
|
||||
|
||||
### Zertifikatsprobleme
|
||||
|
||||
Falls die SSL-Zertifikate nicht richtig funktionieren, führen Sie folgende Schritte aus:
|
||||
|
||||
1. Überprüfen Sie, ob die Zertifikate im Verzeichnis `backend/instance/ssl/` existieren
|
||||
2. Führen Sie die Skripte zur Zertifikatgenerierung erneut aus
|
||||
3. Starten Sie die Container neu: `docker-compose restart`
|
||||
|
||||
### Hostnamenprobleme
|
||||
|
||||
Falls die Hostnamen nicht aufgelöst werden können:
|
||||
|
||||
1. Überprüfen Sie die Einträge in der Hosts-Datei mit `cat /etc/hosts` (Linux/macOS) oder `type C:\Windows\System32\drivers\etc\hosts` (Windows)
|
||||
2. Führen Sie die Hostnamen-Setup-Skripte erneut aus
|
||||
3. Überprüfen Sie die Netzwerkkonfiguration in `docker-compose.yml`
|
||||
|
||||
## Sicherheitshinweise
|
||||
|
||||
- Die selbstsignierten Zertifikate sind für Entwicklungs- und interne Zwecke geeignet
|
||||
- Für Produktionsumgebungen sollten offiziell signierte Zertifikate verwendet werden
|
||||
- Der HTTP-Port 80 beim Backend dient nur als Fallback und sollte in kritischen Umgebungen deaktiviert werden
|
||||
252
docs/SUMMARY.md
252
docs/SUMMARY.md
@@ -1,252 +0,0 @@
|
||||
# MYP-Plattform Projektübersicht
|
||||
|
||||
## 1. Projektüberblick
|
||||
|
||||
Die MYP-Plattform (My Young Printer) ist ein Verwaltungssystem für 3D-Drucker mit folgenden Kernfunktionen:
|
||||
|
||||
- Zentrale Verwaltung mehrerer 3D-Drucker über ein Netzwerk
|
||||
- Steuerung der Stromversorgung über SmartPlugs (Tapo P110)
|
||||
- Benutzer- und Auftragsmanagement mit Reservierungsfunktionalität
|
||||
- Offline-Fähigkeit durch Service Worker Integration
|
||||
- REST-API für Frontend und externe Dienste
|
||||
- Automatisierte Auftrags-Planung und -Ausführung via Scheduler
|
||||
- Verschlüsselte Kommunikation über HTTPS mit selbstsignierten Zertifikaten
|
||||
- Kiosk-Modus für Informationsdisplays und öffentliche Terminals
|
||||
|
||||
Das Backend basiert auf Flask (Python) und nutzt eine SQLite-Datenbank für die Datenspeicherung.
|
||||
|
||||
## 2. Netzwerk-Architektur & Digitale Vernetzung
|
||||
|
||||
Die MYP-Plattform setzt auf eine verteilte Netzwerk-Architektur:
|
||||
|
||||
### Hauptkomponenten
|
||||
|
||||
- **Flask-Backend-Server**: Stellt die zentrale API bereit (Port 5000)
|
||||
- **Smart-Plugs (Tapo P110)**: Steuerung der Drucker-Stromversorgung via IP-Netzwerk
|
||||
- **3D-Drucker**: Werden als Netzwerkgeräte mit festen IP-Adressen konfiguriert
|
||||
- **Frontend**: Als Web-App mit Offline-Funktionalität konzipiert
|
||||
- **PWA-Funktionalität**: Service Worker für Offline-Betrieb und Cache-Management
|
||||
- **Kiosk-Displays**: Raspberry Pi mit Chrome im Kiosk-Modus
|
||||
|
||||
### Netzwerk-Topologie
|
||||
|
||||
```
|
||||
┌──────────────────┐
|
||||
│ Command Center │
|
||||
│ (192.168.0.1) │
|
||||
└──────────┬───────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────┐ ┌─────────────────────┐ ┌──────────────┐
|
||||
│ Frontend/PWA │◄────►│ Flask-Backend │◄────►│ Smart-Plugs │
|
||||
│(192.168.0.105)│ │ (192.168.0.105) │ │(192.168.0.1xx)│
|
||||
└───────┬───────┘ └─────────┬───────────┘ └──────┬────────┘
|
||||
│ │ │
|
||||
│ │ ▼
|
||||
┌───────▼───────┐ │ ┌────────────────┐
|
||||
│ Kiosk-Mode │ │ │ 3D-Drucker │
|
||||
│ (10.0.0.1-10) │ │ │(192.168.0.1xx) │
|
||||
└───────────────┘ ▼ └────────────────┘
|
||||
┌─────────────────────┐
|
||||
│ Ad-hoc Pi-Netzwerk │
|
||||
│ (10.0.0.x/24) │
|
||||
└─────────────────────┘
|
||||
```
|
||||
|
||||
### Kommunikationsprotokolle
|
||||
|
||||
- **HTTPS/REST**: Zwischen Frontend und Backend (Port 5000)
|
||||
- **JSON**: Standardformat für Datenaustausch
|
||||
- **Tapo-Protokoll**: Für Smart-Plug-Steuerung via PyP110-Bibliothek
|
||||
- **SQLite**: Lokale Datenbankanbindung
|
||||
- **TLS 1.2/1.3**: Verschlüsselte Kommunikation mit selbstsignierten Zertifikaten
|
||||
|
||||
### Vernetzungs-Features
|
||||
|
||||
- IP-basierte Identifikation der Drucker im lokalen Netzwerk
|
||||
- SmartPlug-Integration für Fernsteuerung der Stromversorgung
|
||||
- Offline-Betriebsmodus mit synchronisierenden Service Workern
|
||||
- Automatische Erkennung der Drucker-Status via Netzwerk-Polling
|
||||
- Kiosk-Modus mit automatischem Start nach Systemneustart
|
||||
- Command Center für zentrale Verwaltung aller Komponenten
|
||||
|
||||
## 3. Hauptkomponenten des Backends
|
||||
|
||||
### Core-Komponenten
|
||||
|
||||
- **app.py**: Hauptanwendung mit API-Endpunkten und Route-Definitionen
|
||||
- **models.py**: Datenbankmodelle für User, Printer, Job und Stats
|
||||
- **job_scheduler.py**: Background-Task-Scheduler für automatisierte Prozesse
|
||||
- **Blueprints**: Modulare Komponenten für Auth, User, etc.
|
||||
|
||||
### API-Layer
|
||||
|
||||
Das Backend stellt eine umfassende REST-API bereit:
|
||||
- **User Management**: Authentifizierung, Profilmanagement
|
||||
- **Printer Management**: Druckerstatus, Steuerung
|
||||
- **Job Management**: Auftragsplanung, -verwaltung und -überwachung
|
||||
- **Stats API**: Statistiken und Auswertungen
|
||||
- **Kiosk API**: Steuerung der Kiosk-Displays
|
||||
|
||||
### SmartPlug-Integration
|
||||
|
||||
- Nutzung der PyP110-Bibliothek für die Kommunikation mit Tapo-SmartPlugs
|
||||
- Automatisierte Steuerung der Stromversorgung basierend auf Jobplanung
|
||||
- Status-Monitoring und Fehlerbehandlung
|
||||
|
||||
### SSL/HTTPS-Implementierung
|
||||
|
||||
- Selbstsignierte Zertifikate für verschlüsselte Kommunikation
|
||||
- Automatische Zertifikatsgenerierung während der Installation
|
||||
- Konfigurierbare Zertifikatslaufzeit (Standard: 10 Jahre)
|
||||
- Prüfwerkzeuge für Zertifikatsstatus und -gültigkeit
|
||||
|
||||
## 4. Datenbankmodell & Scheduler-Logik
|
||||
|
||||
### Datenbankmodelle
|
||||
|
||||
- **User**: Benutzer-Accounts mit Rollenmanagement
|
||||
- **Printer**: 3D-Drucker mit Netzwerkkonfiguration und Status
|
||||
- **Job**: Druckaufträge mit Zeitplanung und Statusinformationen
|
||||
- **Stats**: Globale Statistikdaten
|
||||
|
||||
### Scheduler-Architektur
|
||||
|
||||
Der BackgroundTaskScheduler bietet:
|
||||
- Registrierung von Task-Funktionen mit individuellen Intervallen
|
||||
- Zeitgesteuerte Ausführung im Hintergrund
|
||||
- Kommunikation mit Smart-Plugs zur zeitgesteuerten Stromversorgung
|
||||
- Automatisches Job-Management
|
||||
|
||||
### Datenbanksicherung
|
||||
|
||||
- SQLite-Datenbank mit Backup-Funktionalität
|
||||
- Einfache Administrierbarkeit durch übersichtliche Tabellenstruktur
|
||||
|
||||
## 5. API-Endpunkte
|
||||
|
||||
| Endpunkt | Methode | Funktion | Authentifizierung |
|
||||
|----------|---------|----------|-------------------|
|
||||
| /api/jobs | GET | Auftragsliste abrufen | Ja |
|
||||
| /api/jobs | POST | Neuen Auftrag erstellen | Ja |
|
||||
| /api/jobs/{id} | GET | Auftragsdetails abrufen | Ja, Besitzer |
|
||||
| /api/jobs/{id}/extend | POST | Auftrag verlängern | Ja, Besitzer |
|
||||
| /api/jobs/{id}/finish | POST | Auftrag abschließen | Ja |
|
||||
| /api/printers | GET | Druckerliste abrufen | Ja |
|
||||
| /api/printers | POST | Neuen Drucker anlegen | Ja, Admin |
|
||||
| /api/printers/status | GET | Status aller Drucker | Ja |
|
||||
| /api/stats | GET | Statistiken abrufen | Ja |
|
||||
| /api/users | GET | Benutzerliste | Ja, Admin |
|
||||
| /api/users | POST | Neuen Benutzer anlegen | Ja, Admin |
|
||||
| /api/scheduler/status | GET | Scheduler-Status | Ja |
|
||||
| /api/scheduler/start | POST | Scheduler starten | Ja, Admin |
|
||||
| /api/scheduler/stop | POST | Scheduler stoppen | Ja, Admin |
|
||||
| /api/kiosk/status | GET | Kiosk-Status | Ja |
|
||||
| /api/kiosk/activate | POST | Kiosk aktivieren | Ja, Admin |
|
||||
| /api/kiosk/deactivate | POST | Kiosk deaktivieren | Ja, Admin |
|
||||
| /auth/login | POST | Anmelden | Nein |
|
||||
| /auth/logout | GET/POST | Abmelden | Ja |
|
||||
|
||||
## 6. Sicherheits- & Zugriffskonzept
|
||||
|
||||
### Authentifizierung
|
||||
|
||||
- Flask-Login für Session-Management
|
||||
- BCrypt für sichere Passwort-Hashes
|
||||
- Role-Based Access Control (RBAC) mit Admin- und Benutzerrollen
|
||||
- Eigene Decorator für erweiterte Zugriffskontrollen (z.B. job_owner_required)
|
||||
|
||||
### Netzwerksicherheit
|
||||
|
||||
- HTTPS mit selbstsignierten TLS-Zertifikaten
|
||||
- CORS-Konfiguration für sichere Cross-Origin-Requests
|
||||
- Sicherheitsheader im Response (X-Content-Type-Options, X-Frame-Options)
|
||||
- Keine sensiblen Daten in URLs oder Query-Parametern
|
||||
|
||||
### Offline-Sicherheit
|
||||
|
||||
- Selektive Cache-Strategie für sensible Daten
|
||||
- Ausschluss von API-Endpunkten mit vertraulichen Informationen vom Caching
|
||||
- Eingeschränkte Funktionalität im Offline-Modus
|
||||
|
||||
## 7. Build- & Deployment-Ablauf
|
||||
|
||||
### Installationsprozess
|
||||
|
||||
Die Installation der MYP-Plattform erfolgt über verschiedene Shell-Skripte:
|
||||
|
||||
- **setup_myp.sh**: Hauptinstallationsskript (Command Center)
|
||||
- Standardinstallation mit HTTPS-Unterstützung
|
||||
- Kiosk-Modus-Installation (gehärtete Variante)
|
||||
- Netzwerk- und DNS-Konfiguration
|
||||
- Systemüberwachung und Logging
|
||||
|
||||
- **create_ssl_cert.sh**: Generiert selbstsignierte Zertifikate
|
||||
- Unterstützt Multiple-SAN-Entries (Hostname, IP-Adressen)
|
||||
- Konfigurierbare Zertifikatslaufzeit
|
||||
- Automatische Fehlerbehandlung
|
||||
|
||||
- **ssl_check.sh**: Prüft SSL-Zertifikatsstatus
|
||||
- Validiert Gültigkeitsdauer
|
||||
- Zeigt Fingerprint und Subject-Details
|
||||
- Warnt vor bald ablaufenden Zertifikaten
|
||||
|
||||
### Backend-Deployment
|
||||
|
||||
- Python 3.11 venv-Umgebung
|
||||
- Konfigurierbare Entwicklungs- und Produktionsumgebungen
|
||||
- Log-Rotation und strukturierte Logging-Hierarchie
|
||||
- SSL/TLS-Unterstützung mit automatischer Zertifikatsgenerierung
|
||||
|
||||
### Kiosk-Modus
|
||||
|
||||
- Basiert auf Raspberry Pi mit Chromium Browser
|
||||
- Automatischer Start im Vollbildmodus nach Boot
|
||||
- Deaktivierung von Fehlerdialogen und Warnungen
|
||||
- Integrierte Überwachung und Watchdog-Funktionalität
|
||||
- Spezielle Konfiguration für öffentliche Informationsdisplays
|
||||
- Ignoriert SSL-Zertifikatswarnungen für selbstsignierte Zertifikate
|
||||
|
||||
### Command Center
|
||||
|
||||
- Zentrales Verwaltungstool mit CLI-Interface
|
||||
- Integrierte Systemdiagnose und -überwachung
|
||||
- Einfache Verwaltung von SSL-Zertifikaten
|
||||
- Fernsteuerung von Kiosk-Displays
|
||||
- Netzwerk- und IP-Konfiguration
|
||||
- Dienst-Management (Start/Stop/Neustart)
|
||||
|
||||
### Frontend-Integration
|
||||
|
||||
- Tailwind CSS für responsive UI
|
||||
- CLI-Befehle für Tailwind-Kompilierung
|
||||
- Service Worker für PWA-Funktionalität
|
||||
- HTTPS-Unterstützung mit Proxy-Konfiguration
|
||||
|
||||
### Systemd-Integration
|
||||
|
||||
- Automatischer Start des Backend-Servers
|
||||
- Überwachung und Neustart bei Fehlern
|
||||
- Logging-Integration in systemd-journal
|
||||
|
||||
## 8. Offene Punkte / Verbesserungspotenzial
|
||||
|
||||
### Digitale Vernetzung
|
||||
|
||||
- OPC UA oder MQTT-Integration für direktere Druckerkommunikation
|
||||
- Echtzeit-Statusüberwachung statt Polling
|
||||
- Push-Benachrichtigungen für Fertigstellungs- und Fehlerereignisse
|
||||
- VPN-Unterstützung für Remote-Zugriff außerhalb des lokalen Netzwerks
|
||||
|
||||
### Sicherheit
|
||||
|
||||
- OAuth2-Integration für externe Authentifizierungsquellen
|
||||
- Zwei-Faktor-Authentifizierung
|
||||
- Zertifikatsbasierte Geräteauthentifizierung für SmartPlugs
|
||||
- Letsencrypt-Integration für vertrauenswürdige Zertifikate
|
||||
|
||||
### Skalierbarkeit
|
||||
|
||||
- Migration von SQLite zu einer skalierbaren Datenbank
|
||||
- Containerisierung mit Docker für einfacheres Deployment
|
||||
- Horizontale Skalierung der Backend-Komponenten
|
||||
@@ -1,298 +0,0 @@
|
||||
# Verbindungstest für Frontend-Backend Integration
|
||||
|
||||
## Übersicht
|
||||
|
||||
Anleitung zum Testen der Verbindung zwischen Frontend und Backend auf dem separaten Server `https://192.168.0.105:443`.
|
||||
|
||||
## 🔍 Schnelltest
|
||||
|
||||
### 1. Backend-Erreichbarkeit prüfen
|
||||
|
||||
```bash
|
||||
# Basis-Verbindung testen
|
||||
ping 192.168.0.105
|
||||
|
||||
# HTTPS-Port testen
|
||||
telnet 192.168.0.105 443
|
||||
|
||||
# SSL-Verbindung testen (ignoriert Zertifikatsfehler)
|
||||
curl -k https://192.168.0.105:443/health
|
||||
```
|
||||
|
||||
### 2. API-Endpunkte testen
|
||||
|
||||
```bash
|
||||
# Health Check
|
||||
curl -k https://192.168.0.105:443/health
|
||||
|
||||
# Drucker abrufen
|
||||
curl -k https://192.168.0.105:443/api/printers
|
||||
|
||||
# Jobs abrufen
|
||||
curl -k https://192.168.0.105:443/api/jobs
|
||||
|
||||
# Mit formatierter Ausgabe
|
||||
curl -k https://192.168.0.105:443/api/printers | jq .
|
||||
```
|
||||
|
||||
### 3. Frontend-Verbindung testen
|
||||
|
||||
```bash
|
||||
# Frontend starten
|
||||
cd frontend
|
||||
pnpm dev
|
||||
|
||||
# In Browser öffnen
|
||||
http://localhost:3000
|
||||
|
||||
# Browser-Konsole prüfen (F12)
|
||||
fetch('/api/health').then(r => r.json()).then(console.log)
|
||||
```
|
||||
|
||||
## 🔧 Fehlerbehebung
|
||||
|
||||
### SSL-Zertifikat-Probleme
|
||||
|
||||
**Problem**: `SSL_ERROR_SELF_SIGNED_CERT`
|
||||
|
||||
**Lösung**:
|
||||
1. Backend direkt im Browser öffnen: `https://192.168.0.105:443`
|
||||
2. Zertifikat manuell akzeptieren
|
||||
3. "Erweitert" → "Weiter zu 192.168.0.105"
|
||||
|
||||
**Alternative**:
|
||||
```bash
|
||||
# curl mit ignoriertem SSL
|
||||
curl -k https://192.168.0.105:443/health
|
||||
```
|
||||
|
||||
### Netzwerk-Verbindungsprobleme
|
||||
|
||||
**Problem**: `Connection refused` oder `Network unreachable`
|
||||
|
||||
**Diagnose**:
|
||||
```bash
|
||||
# 1. IP-Erreichbarkeit prüfen
|
||||
ping 192.168.0.105
|
||||
|
||||
# 2. Port-Verfügbarkeit prüfen
|
||||
nmap -p 443 192.168.0.105
|
||||
|
||||
# 3. Firewall-Status prüfen (auf Backend-Server)
|
||||
sudo ufw status
|
||||
```
|
||||
|
||||
**Lösung**:
|
||||
```bash
|
||||
# Auf Backend-Server (192.168.0.105):
|
||||
sudo ufw allow 443/tcp
|
||||
sudo ufw allow from 192.168.0.0/24 to any port 443
|
||||
```
|
||||
|
||||
### CORS-Probleme
|
||||
|
||||
**Problem**: `Access-Control-Allow-Origin` Fehler
|
||||
|
||||
**Diagnose**:
|
||||
```bash
|
||||
# CORS-Header prüfen
|
||||
curl -k -H "Origin: http://localhost:3000" \
|
||||
-H "Access-Control-Request-Method: GET" \
|
||||
-H "Access-Control-Request-Headers: Content-Type" \
|
||||
-X OPTIONS \
|
||||
https://192.168.0.105:443/api/printers
|
||||
```
|
||||
|
||||
**Lösung**: Backend-CORS-Konfiguration prüfen
|
||||
```python
|
||||
# Auf Backend-Server: app.py
|
||||
from flask_cors import CORS
|
||||
|
||||
app = Flask(__name__)
|
||||
CORS(app, origins=['http://localhost:3000', 'http://192.168.0.*'])
|
||||
```
|
||||
|
||||
### Backend-Service-Probleme
|
||||
|
||||
**Problem**: Backend antwortet nicht
|
||||
|
||||
**Diagnose**:
|
||||
```bash
|
||||
# Auf Backend-Server (192.168.0.105):
|
||||
sudo systemctl status myp-backend
|
||||
sudo journalctl -u myp-backend -f
|
||||
```
|
||||
|
||||
**Lösung**:
|
||||
```bash
|
||||
# Service neu starten
|
||||
sudo systemctl restart myp-backend
|
||||
|
||||
# Oder manuell starten
|
||||
cd /path/to/backend
|
||||
python app.py --host 0.0.0.0 --port 443
|
||||
```
|
||||
|
||||
## 📊 Monitoring
|
||||
|
||||
### Real-time Verbindungsüberwachung
|
||||
|
||||
```bash
|
||||
# Kontinuierlicher Health Check
|
||||
watch -n 5 'curl -k -s https://192.168.0.105:443/health | jq .'
|
||||
|
||||
# Netzwerk-Latenz überwachen
|
||||
ping -c 10 192.168.0.105
|
||||
|
||||
# Port-Monitoring
|
||||
nmap -p 443 192.168.0.105
|
||||
```
|
||||
|
||||
### Frontend-Logs überwachen
|
||||
|
||||
```bash
|
||||
# Frontend-Logs in Echtzeit
|
||||
cd frontend
|
||||
pnpm dev
|
||||
|
||||
# Browser-Konsole (F12) überwachen:
|
||||
console.log('Backend URL:', API_BASE_URL);
|
||||
```
|
||||
|
||||
### Backend-Logs überwachen
|
||||
|
||||
```bash
|
||||
# Auf Backend-Server:
|
||||
tail -f /var/log/myp-backend.log
|
||||
sudo journalctl -u myp-backend -f
|
||||
```
|
||||
|
||||
## 🧪 Automatisierte Tests
|
||||
|
||||
### Frontend-Test-Script erstellen
|
||||
|
||||
```javascript
|
||||
// test-backend-connection.js
|
||||
const API_BASE_URL = 'https://192.168.0.105:443';
|
||||
|
||||
async function testConnection() {
|
||||
try {
|
||||
// Health Check
|
||||
const health = await fetch(`${API_BASE_URL}/health`, {
|
||||
method: 'GET',
|
||||
});
|
||||
console.log('✅ Health Check:', await health.json());
|
||||
|
||||
// Printers API
|
||||
const printers = await fetch(`${API_BASE_URL}/api/printers`);
|
||||
console.log('✅ Printers API:', await printers.json());
|
||||
|
||||
// Jobs API
|
||||
const jobs = await fetch(`${API_BASE_URL}/api/jobs`);
|
||||
console.log('✅ Jobs API:', await jobs.json());
|
||||
|
||||
} catch (error) {
|
||||
console.error('❌ Verbindungsfehler:', error);
|
||||
}
|
||||
}
|
||||
|
||||
testConnection();
|
||||
```
|
||||
|
||||
```bash
|
||||
# Test ausführen
|
||||
node test-backend-connection.js
|
||||
```
|
||||
|
||||
### Backend-Test-Script
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# test-backend.sh
|
||||
|
||||
echo "🔍 Backend-Verbindungstest"
|
||||
echo "=========================="
|
||||
|
||||
# 1. Ping-Test
|
||||
echo "1. Ping-Test..."
|
||||
if ping -c 1 192.168.0.105 > /dev/null; then
|
||||
echo "✅ Server erreichbar"
|
||||
else
|
||||
echo "❌ Server nicht erreichbar"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 2. Port-Test
|
||||
echo "2. Port 443 Test..."
|
||||
if nc -z 192.168.0.105 443; then
|
||||
echo "✅ Port 443 offen"
|
||||
else
|
||||
echo "❌ Port 443 nicht erreichbar"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 3. SSL-Test
|
||||
echo "3. SSL-Verbindungstest..."
|
||||
if curl -k -s https://192.168.0.105:443/health > /dev/null; then
|
||||
echo "✅ SSL-Verbindung erfolgreich"
|
||||
else
|
||||
echo "❌ SSL-Verbindung fehlgeschlagen"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 4. API-Tests
|
||||
echo "4. API-Endpunkt-Tests..."
|
||||
if curl -k -s https://192.168.0.105:443/api/printers > /dev/null; then
|
||||
echo "✅ Drucker-API verfügbar"
|
||||
else
|
||||
echo "❌ Drucker-API nicht verfügbar"
|
||||
fi
|
||||
|
||||
if curl -k -s https://192.168.0.105:443/api/jobs > /dev/null; then
|
||||
echo "✅ Jobs-API verfügbar"
|
||||
else
|
||||
echo "❌ Jobs-API nicht verfügbar"
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "🎉 Verbindungstest abgeschlossen!"
|
||||
```
|
||||
|
||||
```bash
|
||||
# Test ausführen
|
||||
chmod +x test-backend.sh
|
||||
./test-backend.sh
|
||||
```
|
||||
|
||||
## 📋 Checkliste
|
||||
|
||||
### Vor dem ersten Start
|
||||
|
||||
- [ ] Backend-Server unter `192.168.0.105` läuft
|
||||
- [ ] Port 443 ist geöffnet und erreichbar
|
||||
- [ ] SSL-Zertifikat ist konfiguriert (selbstsigniert OK)
|
||||
- [ ] CORS ist für Frontend-Domain konfiguriert
|
||||
- [ ] API-Endpunkte sind verfügbar
|
||||
|
||||
### Bei Problemen prüfen
|
||||
|
||||
- [ ] Netzwerk-Konnektivität (`ping 192.168.0.105`)
|
||||
- [ ] Port-Verfügbarkeit (`telnet 192.168.0.105 443`)
|
||||
- [ ] SSL-Zertifikat manuell akzeptiert
|
||||
- [ ] Backend-Service läuft (`systemctl status myp-backend`)
|
||||
- [ ] Firewall-Regeln korrekt konfiguriert
|
||||
- [ ] Frontend-Konfiguration korrekt (`API_BASE_URL`)
|
||||
|
||||
### Bei erfolgreicher Verbindung
|
||||
|
||||
- [ ] Health Check gibt Status zurück
|
||||
- [ ] Drucker-API gibt Daten zurück
|
||||
- [ ] Jobs-API ist funktional
|
||||
- [ ] Frontend kann Backend-Daten anzeigen
|
||||
- [ ] Keine CORS-Fehler in Browser-Konsole
|
||||
|
||||
---
|
||||
|
||||
**Ziel**: Nahtlose Kommunikation zwischen Frontend (`localhost:3000`) und Backend (`https://192.168.0.105:443`)
|
||||
**Status**: Bereit für Integration
|
||||
**Support**: Siehe Browser-Konsole und Backend-Logs bei Problemen
|
||||
0
docs/Infrastruktur.png → docs/v1-LEGACY/Infrastruktur.png
Executable file → Normal file
0
docs/Infrastruktur.png → docs/v1-LEGACY/Infrastruktur.png
Executable file → Normal file
|
Before Width: | Height: | Size: 3.3 MiB After Width: | Height: | Size: 3.3 MiB |
0
docs/Infrastruktur.tldr → docs/v1-LEGACY/Infrastruktur.tldr
Executable file → Normal file
0
docs/Infrastruktur.tldr → docs/v1-LEGACY/Infrastruktur.tldr
Executable file → Normal file
0
docs/MYP.dbml → docs/v1-LEGACY/MYP.dbml
Executable file → Normal file
0
docs/MYP.dbml → docs/v1-LEGACY/MYP.dbml
Executable file → Normal file
0
docs/MYP.png → docs/v1-LEGACY/MYP.png
Executable file → Normal file
0
docs/MYP.png → docs/v1-LEGACY/MYP.png
Executable file → Normal file
|
Before Width: | Height: | Size: 64 KiB After Width: | Height: | Size: 64 KiB |
0
docs/MYP.sql → docs/v1-LEGACY/MYP.sql
Executable file → Normal file
0
docs/MYP.sql → docs/v1-LEGACY/MYP.sql
Executable file → Normal file
Reference in New Issue
Block a user