Webservices

Emby Dokumentation

Datum: 3. September 2025

Status: Native Installation, produktiv und stabil

System-Übersicht

Installation-Typ: Native Debian-Installation (kein Docker)

Version: Emby Server 4.9.1.24

Server-Name: STORE2

Zugang: http://dergagi.changeip.org:8096

Prozess: EmbyServer (PID 1684585)

Technische Details

Ausführbare Datei: /opt/emby-server/system/EmbyServer

Programmdaten: /var/lib/emby

User: emby (dedicated service user)

FFmpeg-Integration: Vollständig konfiguriert mit eigenen Binaries

• FFmpeg: /opt/emby-server/bin/ffmpeg
• FFprobe: /opt/emby-server/bin/ffprobe
• FFdetect: /opt/emby-server/bin/ffdetect

Netzwerk-Konfiguration

HTTP-Port: 8096 (aktiv, funktional)

HTTPS-Port: 8920 (nicht konfiguriert)

API-Endpoint: http://127.0.0.1:8096/System/Info/Public (funktional)

Externe URL: http://dergagi.changeip.org:8096

Router-Portweiterleitung: Port 8096 → 192.168.1.102:8096

Datenbank-System

MariaDB-Instanzen: 2 aktive Prozesse

• PID 216805: mariadbd (emby user)
• PID 2005213: mariadbd (emby user) Datenbank-Pfad: Unter /var/lib/emby/ verwaltet

Service-Management

Service-Typ: SystemD-managed (automatischer Start)

Restart-Policy: Exit Code 3 für Updates

Update-Methode: APT-Package emby-server-deb_{version}_amd64.deb

Benutzer-Zugang

Aktive externe User: ~5 Freunde mit Remote-Zugang

Funktionalität: Streaming funktioniert stabil über Internet

Performance: Response Time <1ms lokal, stabile Verbindungen

Integration mit STORE2-Ecosystem

Monitoring: Überwacht von Uptime Kuma (Port 8096, Tag: Critical)

Backup: Enthalten in nvme-Backup-System

Netzwerk: Läuft parallel zu Apache (Port 443), keine Konflikte

Medien-Bibliothek

Content-Status: Etablierte Sammlung für 5+ aktive Remote-User

Request-System: Aktuell manuell über persönliche Nachrichten

Geplante Erweiterung: Ombi Request-System für strukturierte User-Requests

Wartung & Updates

Update-Methode: APT-basiert über offizielle Emby-Repository

Backup-Status: Vollständig in nvme-incrementelle Backups enthalten

Stabilität: Läuft seit Installation ohne größere Probleme

Calibre-Web Automated (CWA) auf STORE2

---

Docker-Konfiguration

docker-compose.yml

yaml

services:
  calibre-web-automated:
    image: crocodilestick/calibre-web-automated:latest
    container_name: calibre-web-automated
    restart: unless-stopped
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
    ports:
      - "127.0.0.1:8084:8083"
    volumes:
      - /data/ebooks:/calibre-library:rw
      - /data/ebooks-config:/config:rw
    healthcheck:
      test: ["CMD-SHELL","python3 -c \"import socket; s=socket.socket(); s.settimeout(2); s.connect(('127.0.0.1',8083)); s.close()\""]
      interval: 15s
      timeout: 5s
      retries: 10
      start_period: 120s
    stop_grace_period: 30s

---

Automatisierung

SystemD Timer

cwa-health.timer (jede Minute)

• Überwacht Container-Status
• Startet CWA bei Absturz neu
• Service: /etc/systemd/system/cwa-health.timer
• Script: /usr/local/bin/cwa-health.sh

bash

systemctl status cwa-health.timer

Cron-Jobs (root)

cwa-smart-import-v2.sh (alle 6 Stunden)

• Scannt /data/ebooks nach neuen EPUBs
• Importiert automatisch
• Log: /var/log/cwa-import.log

bash

crontab -l | grep cwa

Geplante Aufgaben (CWA Web-UI, täglich 06:00)

• ✓ Buchcover Miniaturansichten erzeugen
• ✓ Mit Calibre Bibliothek neu verbinden
• ✓ Metadaten Backup Datei erzeugen

---

Aktive Features

CWA-Services

• ✓ Auto-Convert (EPUB als Standard)
• ✓ Automatic Cover & Metadata Enforcement
• ✓ Kindle EPUB Fixer
• ✓ Import Auto-Backup

Web-UI Einstellungen

• ✓ Hochladen aktiviert
• ✓ Update-Benachrichtigungen
• ✓ GMX Mail-Server konfiguriert (Send-to-Kindle)

---

Neue eBooks einbinden

Methode 1: Automatischer Import (empfohlen)

Neue EPUBs nach /data/ebooks/ kopieren:

bash

cp ~/neue-buecher/*.epub /data/ebooks/

Import erfolgt automatisch alle 6h via Cron, oder manuell triggern:

bash

/usr/local/bin/cwa-smart-import-v2.sh

Methode 2: Web-Upload

1. https://dergagi.changeip.org/cwa öffnen
2. "Upload" Button → Dateien auswählen
3. CWA importiert automatisch

Methode 3: Calibre Desktop Import (für große Mengen)

⚠️ WICHTIG: Container MUSS gestoppt sein!

bash

# Container stoppen
cd /srv/calibre-web-automated
docker compose down

# Calibre Desktop öffnen (GUI)
# Bibliothek: /data/ebooks
# Bücher hinzufügen mit Duplikat-Merge

# Container wieder starten
docker compose up -d

---

Import-Scripts

Legacy Scripts (archiviert):

29 alte Import-Scripts wurden identifiziert. Bei Bedarf aufräumen:

bash

# Liste anzeigen
ls -lht /usr/local/bin/cwa-* /usr/local/bin/import-* /usr/local/bin/calibre-*

# Archivieren (falls gewünscht)
mkdir -p /root/old-cwa-scripts
mv /usr/local/bin/cwa-{scan,import,turbo,fast,simple}* /root/old-cwa-scripts/

---

Wartung

Container-Neustart

bash

cd /srv/calibre-web-automated
docker compose restart

Datenbank-Backup

Automatisch: Täglich um 06:00 Uhr via CWA Scheduled Task

Manuell:

bash

cp /data/ebooks/metadata.db /data/ebooks/metadata.db.backup-$(date +%Y%m%d-%H%M%S)

Backups finden:

bash

ls -lht /data/ebooks/metadata.db.* | head -5

Logs prüfen

bash

# Container-Logs
docker logs -f calibre-web-automated

# Import-Logs
tail -f /var/log/cwa-import.log

# Health-Check Logs
journalctl -u cwa-health.service -f

Buchanzahl prüfen

bash

sqlite3 /data/ebooks/metadata.db "SELECT COUNT(*) FROM books;"

---

Statistiken

Performance

• Auto-Ingest: ~10-15 Bücher/Minute
• Calibre Desktop Bulk-Import: ~200-300 Bücher/Minute
• Große Imports (>30k Bücher): 2-3 Stunden

---

Bekannte Einschränkungen

Format-Duplikate

• CWA zeigt jedes Format (epub/mobi/pdf) als separaten Eintrag
• Keine Gruppierungsfunktion verfügbar
• Workaround: Nur ein Format pro Buch hochladen (bevorzugt EPUB)

Import-Geschwindigkeit

• Auto-Ingest langsamer als Calibre Desktop
• Große Imports (>500 Bücher) besser via Calibre Desktop

Tiefe Ordnerstrukturen

• Werden erkannt, aber langsam verarbeitet
• Besser: Flache Struktur /Autor/Buchtitel/

---

Fehlerbehebung

Container startet nicht

bash

cd /srv/calibre-web-automated
docker compose down
docker compose up -d
docker logs calibre-web-automated

CWA zeigt falsche Buchanzahl

bash

# Im Browser: Admin → "Mit Calibre Bibliothek neu verbinden"
# Oder per API:
curl -X POST http://127.0.0.1:8084/admin/reconnect

Unvollständige Einträge / Fehlende Cover

Admin → Geplante Aufgaben → "Metadaten Backup" manuell starten

"Database is locked" Fehler

Ursache: Calibre Desktop läuft parallel zum Container

Lösung:

bash

# Container stoppen
docker compose down

# Calibre Desktop schließen
pkill -f calibre

# Container neu starten
docker compose up -d

---

Monitoring

Live-Monitor (während Import läuft)

bash

watch -n 2 'echo "=== CWA STATUS ==="; \
echo "Bücher in DB: $(sqlite3 /data/ebooks/metadata.db "SELECT COUNT(*) FROM books;")"; \
echo "Container: $(docker ps --filter name=calibre-web-automated --format "{{.Status}}")"; \
echo "Healthcheck: $(docker inspect calibre-web-automated --format="{{.State.Health.Status}}")"'

Timer-Status prüfen

bash

systemctl list-timers | grep cwa

---

Apache Reverse Proxy

CWA ist über Apache erreichbar:

VirtualHost: 000-catchall-443.conf + 000-website-dergagi-443.conf

ProxyPass-Regel:

apache

ProxyPass /cwa http://127.0.0.1:8084
ProxyPassReverse /cwa http://127.0.0.1:8084

Externe URL: https://dergagi.changeip.org/cwa

---

Wichtige Hinweise

1. NIE Container UND Calibre Desktop gleichzeitig laufen lassen! → SQLite-DB kann nur von EINEM Prozess beschrieben werden
2. Große Imports immer via Calibre Desktop: → Container stoppen, Import durchführen, Container starten
3. Backups vor großen Änderungen:

bash

   cp /data/ebooks/metadata.db /data/ebooks/metadata.db.backup-$(date +%Y%m%d)

1. System-Backups via nvme-backup.timer: → Täglich 03:07 Uhr, 21 Versionen in /mnt/nvme_backup/

---

Letzte Aktualisierung: 10. Oktober 2025

Version: 2.0 (Post-Torboox-Import)

MediaWiki - Aktuelle Konfiguration & Dokumentation

Stand: 11. Oktober 2025, 14:30 Uhr

Status: Produktiv, vollständig funktional nach Login-Fix und Cookie-Konfiguration

---

🎯 System-Übersicht

Grundkonfiguration

• MediaWiki Version: 1.44.0
• Haupt-URL (HTTPS): https://dergagi.changeip.org/w/
• Direkt-URL (HTTP): http://dergagi.changeip.org:8088/
• Betriebssystem: Debian 13 (STORE2)
• Container-System: Docker + Docker-Compose
• Installation-Pfad: /srv/mediawiki-clean-final/

Admin-Zugang

• Admin-User: admin
• Admin-Passwort: CleanFinalMW2025!
• Login-URL: https://dergagi.changeip.org/w/index.php?title=Spezial:Anmelden

---

🐳 Docker-Setup

Container-Konfiguration

bash

# Container-Namen
mw-clean-final        # MediaWiki-Anwendung
mw-clean-final-db     # MariaDB-Datenbank

# Management-Befehle
cd /srv/mediawiki-clean-final/
docker-compose up -d        # Start
docker-compose down         # Stop
docker-compose restart      # Neustart
docker ps | grep mw-clean   # Status
docker logs mw-clean-final  # Logs

Port-Mapping

• MediaWiki: Container:80 → Host:8088
• Datenbank: Container:3306 (intern, nicht exposed)

Netzwerk-Architektur

• HTTPS (Port 443): Apache Reverse Proxy → https://dergagi.changeip.org/w/
• HTTP (Port 8088): Direkter Container-Zugang → http://dergagi.changeip.org:8088/
• Apache ProxyPass: /w/ → http://127.0.0.1:8088/

---

💾 Datenbank-Konfiguration

MariaDB-Credentials

• DB-Host: database (Container-Name)
• DB-Name: mediawiki
• DB-User: mwuser
• DB-Passwort: CleanFinalMW2025!
• DB-Root-User: root
• DB-Root-Passwort: CleanFinalRoot2025!

Datenbank-Zugriff

bash

# Direkte Datenbank-Verbindung
docker exec -it mw-clean-final-db mysql -u mwuser -p'CleanFinalMW2025!' mediawiki

# Root-Zugriff
docker exec -it mw-clean-final-db mysql -u root -p'CleanFinalRoot2025!' mediawiki

---

⚙️ MediaWiki-Konfiguration

LocalSettings.php (Zentrale Einstellungen)

• Container-Pfad: /var/www/html/LocalSettings.php
• Host-Backup: /srv/mediawiki-clean-final/LocalSettings.php

Wichtige Konfigurationswerte

php

$wgSitename = "Store2 Wiki";
$wgServer = "https://dergagi.changeip.org";  # HTTPS via Reverse Proxy
$wgScriptPath = "/w";
$wgLanguageCode = "de";
$wgDefaultSkin = "vector";
$wgEnableUploads = true;
$wgLogos = [
    '1x' => "$wgResourceBasePath/images/logo.png",
    'icon' => "$wgResourceBasePath/images/logo.png",
];

# === KRITISCHE COOKIE-KONFIGURATION (11.10.2025) ===
$wgCookieSecure = false;        # MUSS false sein bei HTTPS-Proxy!
$wgForceHTTPS = false;
$wgCookieHttpOnly = true;
$wgCookiePath = "/w/";
$wgCookieDomain = "";           # Leer = Same-Domain
$wgCookieSameSite = false;

# === SESSION-KONFIGURATION ===
$wgSessionCacheType = CACHE_DB;
$wgSessionsInObjectCache = true;
$wgObjectCacheSessionExpiry = 86400;

# === CACHE-DEAKTIVIERUNG (für stabiles Editieren) ===
$wgEnableParserCache = false;   # Verhindert "Versions-ID"-Fehler
$wgCachePages = false;

# === USER PERMISSIONS ===
# Nur registrierte User können editieren
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['createpage'] = false;
$wgGroupPermissions['*']['createaccount'] = false;  # Nur Admin kann Accounts erstellen

# Suppress MediaWiki 1.44 core deprecation warnings
error_reporting( E_ALL & ~E_USER_DEPRECATED & ~E_DEPRECATED );

Logo-Integration

• Logo-Datei: /var/www/html/images/logo.png (im Container)
• Original-Logo: /data/Downloads/Fertig/Mediawiki_Store2_Logo.png
• Skalierung: 160x160px (optimiert für MediaWiki)
• Dateigröße: ~10KB (von ursprünglich 1.1MB)
• Status: Store2-Logo mit rotem Rahmen und Stern sichtbar

---

🔐 Sicherheit & Benutzerrechte

Berechtigungsmodell

• ✅ Jeder kann lesen (keine Authentifizierung erforderlich)
• ✅ Nur registrierte User können editieren
• ✅ Nur Admin kann neue Accounts erstellen
• ✅ Login funktioniert (Cookie-Problem gelöst am 11.10.2025)

Neue User anlegen

Option A: Über Web-UI (EMPFOHLEN)

1. Als Admin einloggen: https://dergagi.changeip.org/w/
2. Zu Spezial-Seite: https://dergagi.changeip.org/w/index.php?title=Spezial:CreateAccount
3. Benutzername, Passwort, E-Mail eingeben
4. "Benutzerkonto erstellen" klicken

Option B: Via Command-Line

bash

# Normaler User
docker exec mw-clean-final php /var/www/html/maintenance/createAndPromote.php \
  --force \
  username \
  'Password123!'

# Admin-User (mit Sysop + Bureaucrat Rechten)
docker exec mw-clean-final php /var/www/html/maintenance/createAndPromote.php \
  --force \
  --bureaucrat \
  --sysop \
  adminuser \
  'AdminPass123!'

---

🌐 Browser-Zugang & Troubleshooting

Zugang in neuen Browsern einrichten

Für JEDEN neuen Browser (Chrome, Opera, Firefox auf anderem PC):

1. Browser öffnen
2. Zu MediaWiki gehen: https://dergagi.changeip.org/w/
3. Cache-Bypass: Strg + F5 (Windows) oder Strg + Shift + R (Linux)
4. Login-Seite: https://dergagi.changeip.org/w/index.php?title=Spezial:Anmelden
5. Login: admin / CleanFinalMW2025!

Login funktioniert nicht?

Cookies löschen:

• Chrome/Opera: F12 → Tab "Application" → Links "Cookies" → https://dergagi.changeip.org → Alle löschen
• Firefox: F12 → Tab "Speicher" → "Cookies" → https://dergagi.changeip.org → Rechtsklick "Alle löschen"
• Inkognito-Fenster verwenden (sauberster Test)

"Versions-ID stimmen nicht überein" Fehler

Bereits behoben durch:

php

$wgEnableParserCache = false;
$wgCachePages = false;

Falls der Fehler dennoch auftritt:

bash

# Cache-Rebuild
docker exec mw-clean-final php /var/www/html/maintenance/rebuildrecentchanges.php

---

📊 Daten-Inhalt

Wiki-Seiten (12+ Hauptseiten)

• Hauptseite (mit Kachel-Layout)
• Store_2.0 (umfangreiche System-Dokumentation)
• RAID-Systeme (Raid, Raid-Layout)
• Linux-Verwendung (Linux-use)
• Change-Routen (System-Migration)
• Webservices & Subversion
• Wiki-Bearbeitung (Wiki-Edit)
• Container-Wiederherstellung-Dokumentation

Statistik

• Seiten: 12+ importiert
• Revisionen: 1059+ (aus 2010er Backup + neue Inhalte)
• Datenquelle: XML-Backup von Original-Store2-System + laufende Updates

---

💾 Backup-System

Aktuelle Backups

bash

# Perfektes Aktuell-Backup mit Logo (94MB) - 03.09.2025
/root/mediawiki-perfect-with-logo-20250903-152727/
├── mediawiki-perfect-152727.sql  (47MB - SQL mit aktuellen Daten)
├── mw-database-perfect.tar.gz    (33MB - Docker-Volume)
├── mw-images-with-logo.tar.gz    (14MB - Images + Store2-Logo)
├── LocalSettings-perfect.php     (4.7KB - Konfiguration)
└── mediawiki-setup/              (Docker-Compose)

# Cookie-Fix-Backups (11.10.2025)
/var/www/html/LocalSettings.php.BEFORE-FINAL-FIX  # Vor Cookie-Fix
/var/www/html/LocalSettings.php.backup-*          # Verschiedene Versionen

Backup-Kommando (Aktuell)

bash

# Manuelles Backup erstellen
TS=$(date +%Y%m%d-%H%M%S)
mkdir -p /root/mediawiki-backup-$TS

# SQL-Dump
docker exec mw-clean-final-db mysqldump -u mwuser -pCleanFinalMW2025! mediawiki > /root/mediawiki-backup-$TS/mediawiki-$TS.sql

# LocalSettings.php
docker cp mw-clean-final:/var/www/html/LocalSettings.php /root/mediawiki-backup-$TS/

# Docker-Volumes
docker run --rm -v mediawiki-clean-final_mw-database:/data alpine tar czf - -C /data . > /root/mediawiki-backup-$TS/mw-database.tar.gz
docker run --rm -v mediawiki-clean-final_mw-images:/data alpine tar czf - -C /data . > /root/mediawiki-backup-$TS/mw-images.tar.gz

echo "Backup erstellt in: /root/mediawiki-backup-$TS"

Restore-Prozedur

bash

# Restore aus Backup
cd /root/mediawiki-backup-TIMESTAMP/
docker-compose -f /srv/mediawiki-clean-final/docker-compose.yml down
docker volume rm mediawiki-clean-final_mw-database mediawiki-clean-final_mw-images
docker-compose -f /srv/mediawiki-clean-final/docker-compose.yml up -d

# Volumes wiederherstellen
gunzip < mw-database.tar.gz | docker run -i --rm -v mediawiki-clean-final_mw-database:/data alpine tar xzf - -C /data
gunzip < mw-images.tar.gz | docker run -i --rm -v mediawiki-clean-final_mw-images:/data alpine tar xzf - -C /data

# LocalSettings.php
docker cp LocalSettings.php mw-clean-final:/var/www/html/LocalSettings.php

# Container neustarten
docker-compose -f /srv/mediawiki-clean-final/docker-compose.yml restart

---

🔧 Wartung & Maintenance

MediaWiki-Maintenance-Scripts

bash

# Update-Script (nach MediaWiki-Upgrade)
docker exec mw-clean-final php /var/www/html/maintenance/update.php

# Cache-Rebuild
docker exec mw-clean-final php /var/www/html/maintenance/rebuildrecentchanges.php

# Site-Statistiken aktualisieren
docker exec mw-clean-final php /var/www/html/maintenance/initSiteStats.php

# Admin-Passwort ändern
docker exec mw-clean-final php /var/www/html/maintenance/changePassword.php \
  --user=admin \
  --password='NeuesPasswort123!'

Monitoring

bash

# Container-Status
docker ps | grep mw-clean

# Logs live verfolgen
docker logs -f mw-clean-final

# Apache-Logs (im Container)
docker exec mw-clean-final tail -f /var/log/apache2/error.log

# Port-Check
ss -tlnp | grep :8088

---

🔍 Integration in STORE2-System

Apache Reverse Proxy Konfiguration

VirtualHost-Dateien:

• /etc/apache2/sites-enabled/000-catchall-443.conf
• /etc/apache2/sites-enabled/000-website-dergagi-443.conf

ProxyPass-Regel (in beiden VirtualHosts):

apache

<Location /w/>
  ProxyPass http://127.0.0.1:8088/
  ProxyPassReverse http://127.0.0.1:8088/
  RequestHeader set X-Forwarded-Proto "https"
  RequestHeader set X-Forwarded-Host "dergagi.changeip.org"
  RequestHeader set X-Forwarded-Port "443"
</Location>

Netzwerk-Architektur

• Läuft parallel zu Apache (Port 443)
• Keine BasicAuth-Konflikte
• Direkter Port-Zugang (8088) UND Proxy-Zugang (443) verfügbar
• Unabhängig von /data2-Mount (läuft auf Haupt-Partition)

Docker-Volumes

bash

# Volume-Namen
mediawiki-clean-final_mw-database  # MariaDB-Daten
mediawiki-clean-final_mw-images    # MediaWiki-Uploads + Store2-Logo

# Volume-Pfade
/var/lib/docker/volumes/mediawiki-clean-final_mw-database/_data
/var/lib/docker/volumes/mediawiki-clean-final_mw-images/_data

---

📝 Änderungshistorie & Lessons Learned

Container-Wiederherstellung (03.09.2025)

• Problem: Versehentliches docker container prune -f löschte alle Container
• Lösung: Vollständige Wiederherstellung aus nvme-Backup
• Status: Erfolgreich mit allen Daten wiederhergestellt

Login-Problem gelöst (11.10.2025)

• Problem: Login funktionierte nicht (Cookie wurde nicht erkannt)
• Root Cause: $wgCookieSecure = true bei HTTPS-Proxy-Setup
• Lösung: $wgCookieSecure = false + $wgForceHTTPS = false
• Status: ✅ Login funktioniert jetzt in allen Browsern

Edit-Token-Problem gelöst (11.10.2025)

• Problem: "Versions-IDs stimmen nicht überein" bei wiederholtem Editieren
• Root Cause: Parser-Cache verursachte Token-Mismatch
• Lösung: $wgEnableParserCache = false + $wgCachePages = false
• Status: ✅ Mehrfaches Editieren ohne Fehler möglich

Wichtige Erkenntnisse

1. Cookie-Konfiguration bei HTTPS-Proxy: $wgCookieSecure = false ist KRITISCH
2. Cache-Probleme: Bei Edit-Token-Problemen Cache deaktivieren
3. Browser-Cache: Neue Browser benötigen Cache-Bypass (Strg+F5)
4. Backup-Kritikalität: nvme-Backup war entscheidend für Wiederherstellung
5. Systematische Reparatur: Immer Backup vor Systemänderungen

---

🎯 Quick Reference

Häufige Aufgaben

bash

# Container neu starten
cd /srv/mediawiki-clean-final/ && docker-compose restart

# LocalSettings.php bearbeiten
docker exec -it mw-clean-final nano /var/www/html/LocalSettings.php

# Logs live anzeigen
docker logs -f mw-clean-final

# Backup erstellen (siehe Backup-Kommando oben)

# User anlegen
docker exec mw-clean-final php /var/www/html/maintenance/createAndPromote.php --force username 'password'

Wichtige URLs

• Haupt-URL: https://dergagi.changeip.org/w/
• Login: https://dergagi.changeip.org/w/index.php?title=Spezial:Anmelden
• User anlegen: https://dergagi.changeip.org/w/index.php?title=Spezial:CreateAccount
• Spezialseiten: https://dergagi.changeip.org/w/index.php?title=Spezial:Spezialseiten
• Direkt-Zugang: http://dergagi.changeip.org:8088/

---

MediaWiki Store2 ist vollständig eingerichtet, produktiv, backup-gesichert und mit funktionierendem Login.

Koel Musikstreaming-Server

📍 Installation erfolgreich abgeschlossen

Server: STORE2

URL: http://dergagi.changeip.org:6680

Status: ✅ Voll funktionsfähig

---

🔑 Zugangsdaten

Admin-Account:

• Email: daniel.gareis@gmail.com
• Passwort: #s46@jCuFEq5S^

Datenbank:

• DB-Root: KoelRootStore2!
• DB-User: koel / KoelStore2Music2025!

---

🎵 Musik-Archiv

Verzeichnisse:

• Hauptordner: /data2/mp3/mp3 (92.980 MP3-Dateien)
• Symlinks: 38.046 Links in /data2/mp3/mp3/00_Unique_From_Other_Folders
• Weitere: 7.778 MP3s in /data2/mp3/mp3s von MB/
• Cover: 7.015 Cover-Dateien im Archiv, werden bei Koel aber nicht genutzt, sondern on-the-fly online hergeholt und auch nicht lokal gespeichert

Scan-Status:

• Läuft gerade im Hintergrund (2-3 Stunden für alle Dateien)
• Songs erscheinen live im Web-Interface während des Scans
• Log: /var/log/koel-scan.log

---

🔧 Technische Details

Docker-Setup:

• Installation in /srv/koel
• Container: koel (App) + koel-db (MariaDB 10.11)
• Port: 6680 (extern) → 80 (intern)
• Images: phanan/koel:latest + mariadb:10.11
• Memory Limit: 2GB für Koel, 512MB für DB

Konfigurationsdateien:

• Docker Compose: /srv/koel/docker-compose.yml
• Environment: /srv/koel/koel.env
• APP_KEY: Automatisch generiert und in koel.env gespeichert

Features:

• ✅ Web-basiertes Streaming
• ✅ Playlist-Verwaltung
• ✅ Last.fm/Spotify/iTunes Metadaten
• ✅ Cover-Art (dynamisch geladen)
• ✅ Suche und Filter
• ⚠️ 100.686/137.074 Songs verfügbar

Bekannte Probleme:

• Unterordner in /00_Unique_From_Other_Folders/ werden nicht gescannt
• UTF-8 Encoding-Fehler bei Sonderzeichen
• Keine lokale Cover-Speicherung

---

📝 Wichtige Wartungsbefehle

bash

<# Musik-Scan manuell starten
docker exec --user www-data koel php artisan koel:scan

# Scan-Progress verfolgen
tail -f /var/log/koel-scan.log

# Container-Status prüfen
docker ps | grep koel

# Container neu starten
cd /srv/koel && docker-compose restart

# Laravel-Logs bei Problemen
docker exec koel tail -50 /var/www/html/storage/logs/laravel.log

# Cache leeren
docker exec koel php artisan cache:clear
docker exec koel php artisan config:clear

---

💾 Backup-Information

• Navidrome-Backup vorhanden: /root/backup-navidrome-*.tar.gz
• Koel-Daten: /srv/koel/ (Docker Volumes)
• Musik unverändert in: /data2/mp3/

---

⚠️ Bekannte Einschränkungen

• Läuft nur über HTTP (kein HTTPS aktiv)
• Mobile Apps sind kostenpflichtig
• Keine automatischen Metadaten-Downloads konfiguriert

System läuft stabil! Container sind healthy, Web-Interface funktioniert

Navidrome (läuft nicht mehr, nur historisch, wurde durch Koel ersetzt)

📋 Service-Übersicht

Service: Navidrome Music Streaming Server

Status: Produktiv

Installation: 2025-09-03

Container-ID: navidrome

🔧 Technische Konfiguration

Netzwerk & Ports

• Port: 4533 (HTTP)
• Lokal: http://localhost:4533
• Extern: http://dergagi.changeip.org:4533
• Protocol: HTTP (kein HTTPS - läuft hinter Apache wenn gewünscht)

Docker-Container

bash

Container Name: navidrome
Image: deluan/navidrome:latest
Restart Policy: unless-stopped
Port Mapping: 4533:4533
Network: Bridge (Standard)

Volume-Mounts

bash

/data2/mp3 → /music (read-only)           # Musik-Archiv (138.192 MP3s)
/opt/navidrome/data → /data               # SQLite-DB & Metadaten
/opt/navidrome/cache → /cache             # Thumbnails & Cache
/opt/navidrome/navidrome.toml → /opt/navidrome/navidrome.toml (ro)

Konfigurationsdatei

Pfad: /opt/navidrome/navidrome.toml

toml

MusicFolder = "/music"
DataFolder = "/data"
CacheFolder = "/cache"
Address = "0.0.0.0"
Port = 4533
LogLevel = "info"
ScanSchedule = "@every 1h"
SessionTimeout = "24h"
UIWelcomeMessage = "Willkommen zu STORE2 Music Center"
EnableTranscodingConfig = true
TranscodingCacheSize = "1GB"
EnableSharing = true
EnableStarRating = true
EnableUserEditing = true
MaxSidebarPlaylists = 100

Verwaltungsbefehle

bash

# Status prüfen
docker ps | grep navidrome

# Logs ansehen
docker logs navidrome

# Container stoppen/starten
docker stop navidrome
docker start navidrome

# Container neu starten
docker restart navidrome

# Container entfernen (Notfall)
docker stop navidrome && docker rm navidrome

iTunes/Last.fm Cover Downloader Service

System: STORE2 (Debian 13)

Stand: 2025-09-14

Status: ✅ AKTIV UND FUNKTIONSFÄHIG

---

1. SYSTEM-ÜBERSICHT

Zweck

Automatisches Herunterladen fehlender Album-Cover für die MP3-Sammlung unter /data2/mp3/mp3/ mittels iTunes und Last.fm APIs.

Aktuelle Statistik

• Service läuft seit: 14.09.2025 08:15 Uhr
• Erfolgsrate: ~11-15% (normal für diese Sammlung mit vielen Bootlegs)
• Bisher heruntergeladen: 380+ Cover erfolgreich, 2187 neue Cover in 24h
• Verbleibende Queue: 2901 Alben ohne Cover
• Geschätzte Restzeit: ~2-3 Stunden bei 3 Sek/Album

---

2. TECHNISCHE ARCHITEKTUR

Verzeichnisstruktur

/opt/itunes-persistent/
├── downloader_robust_v3.sh      # Hauptscript (Bash)
├── download_queue.txt           # Queue (TAB-getrennt: Pfad<TAB>Artist<TAB>Album)
├── skip_artwork.txt             # Skip-Cache für bereits versuchte Alben
├── make_queue.py                # Python-Script zur Queue-Generierung
├── logs/
│   ├── downloader-YYYY-MM-DD.log  # Tägliche Log-Dateien
│   └── session_stats.log          # Statistik-Übersicht
└── backup-*/                    # Backup-Verzeichnisse

SystemD Service Configuration

Datei: /etc/systemd/system/itunes-downloader.service

ini

[Unit]
Description=Hybrid iTunes + Last.fm Cover Downloader
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/itunes-persistent
ExecStart=/opt/itunes-persistent/downloader_robust_v3.sh
Restart=always
RestartSec=60
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

---

3. API KONFIGURATION

Last.fm API

• API Key: 7c327a65fcfcec095b42e9df6b3b46b4
• Secret: 4765b081824d0dfc5a6174fd457b6a9b
• User: dergagi33
• App Name: Store2
• Rate Limit: 300 requests/minute
• Erfolgsrate: ~60% für offizielle Releases

iTunes API

• Endpoint: https://itunes.apple.com/search
• Rate Limit: 20 requests/minute
• Auth: Keine erforderlich
• Erfolgsrate: ~30% für offizielle Releases

---

4. WORKFLOW & LOGIK

Download-Prozess

1. Queue laden aus download_queue.txt
2. Skip-Check: Prüfung gegen skip_artwork.txt
3. API-Versuch 1: iTunes API Query
4. API-Versuch 2: Last.fm API als Fallback
5. Alternative Schreibweisen bei Fehlschlag (& → and, Umlaute, etc.)
6. Download: Cover als cover.jpg speichern
7. Cache-Update: Erfolg/Misserfolg in Skip-Cache

Queue-Generierung (make_queue.py)

python

#!/usr/bin/env python3
import os

base_dir = '/data2/mp3/mp3'
output_file = '/opt/itunes-persistent/download_queue.txt'

with open(output_file, 'w') as f:
    for root, dirs, files in os.walk(base_dir):
        # Skip Sampler/Collections
        if any(part.startswith('00') for part in root.split('/')):
            continue
        # Check for missing cover
        if 'cover.jpg' not in files:
            # Extract artist and album from path
            # Write TAB-separated: path<TAB>artist<TAB>album

---

5. WICHTIGE BEFEHLE

Service Management

bash

# Status prüfen
systemctl status itunes-downloader

# Service stoppen
systemctl stop itunes-downloader

# Service starten
systemctl start itunes-downloader

# Service neustarten
systemctl restart itunes-downloader

# Logs anzeigen (live)
journalctl -u itunes-downloader -f

# Auto-Start aktivieren/deaktivieren
systemctl enable itunes-downloader
systemctl disable itunes-downloader

Monitoring & Statistik

bash

# Live-Log verfolgen
tail -f /opt/itunes-persistent/logs/downloader-$(date +%F).log

# Erfolgsstatistik
grep -c "SUCCESS:" /opt/itunes-persistent/logs/downloader-$(date +%F).log

# Queue-Status
wc -l < /opt/itunes-persistent/download_queue.txt

# Neue Cover der letzten Stunde
find /data2/mp3/mp3 -name "cover.jpg" -mmin -60 | wc -l

# Erfolgsrate berechnen
awk '/Processing:/ {total++} /SUCCESS:/ {success++} END {
    print "Erfolge: " success "/" total " = " int(success*100/total) "%"
}' /opt/itunes-persistent/logs/downloader-$(date +%F).log

Queue Management

bash

# Queue neu generieren
systemctl stop itunes-downloader
cd /opt/itunes-persistent
python3 make_queue.py
systemctl start itunes-downloader

# Skip-Cache leeren (für neue Versuche)
> /opt/itunes-persistent/skip_artwork.txt

# Backup erstellen
cp download_queue.txt download_queue.backup
cp skip_artwork.txt skip_artwork.backup

---

6. TROUBLESHOOTING

Problem: Service läuft in Endlos-Schleife

Symptom: Service startet alle 60 Sekunden neu

Ursache: Alle Queue-Einträge im Skip-Cache

Lösung:

bash

systemctl stop itunes-downloader
> /opt/itunes-persistent/skip_artwork.txt  # Skip-Cache leeren
python3 /opt/itunes-persistent/make_queue.py  # Neue Queue
systemctl start itunes-downloader

Problem: Keine neuen Downloads

Mögliche Ursachen:

• API-Rate-Limits erreicht
• Alle verbleibenden Alben nicht in APIs verfügbar
• Queue leer

Diagnose:

bash

# Prüfe ob Queue leer
wc -l < /opt/itunes-persistent/download_queue.txt

# Prüfe letzte Aktivität
tail -20 /opt/itunes-persistent/logs/downloader-$(date +%F).log

# Prüfe ob Prozess läuft
pgrep -f downloader_robust_v3.sh

Problem: Zu viele API-Fehler

Lösung: Rate-Limit in Script anpassen

bash

# In downloader_robust_v3.sh:
# RATE_LIMIT variable von 2 auf 3-4 Sekunden erhöhen

---

7. MUSIK-SAMMLUNG STRUKTUR

Gesamt-Statistik

• Basis-Verzeichnis: /data2/mp3/mp3/
• Künstler-Verzeichnisse: 1372
• Gesamt-Alben: 6642
• Mit Cover: 3741 (nach Downloads)
• Ohne Cover: 2901 (hauptsächlich Bootlegs/VA)

Kategorien ohne Cover

1. VA-Compilations: ~540 Einträge
   • Schwer zu finden, oft lokale Zusammenstellungen
2. Bootlegs/Underground: ~800 Einträge
   • Release-Groups (-uC, -RpM, -WHOA, -XXL)
   • Niemals in offiziellen APIs
3. Fehlende Metadaten: ~550 Einträge
   • Verzeichnisname = Artist = Album
   • Parser konnte nicht trennen
4. Reggae-Sammlung: ~200 Einträge
   • Spezielle Struktur unter REGGAE/REGGEA
5. Normale Alben: ~800 Einträge
   • Ältere/unbekannte Releases
   • Falsche Schreibweise

---

8. PERFORMANCE & OPTIMIERUNG

Aktuelle Performance

• Durchsatz: ~20-30 Alben/Minute
• Pause zwischen Downloads: 2 Sekunden
• Erfolgsrate: 11-15% (systembedingt niedrig)

Optimierungsmöglichkeiten

1. Parallel-Processing: Mehrere Worker-Threads
2. Bessere APIs: MusicBrainz, Discogs
3. Lokale Datenbank: Cache erfolgreicher Matches
4. Fuzzy-Matching: Bessere Schreibweisen-Toleranz

---

9. BACKUP & RECOVERY

Wichtige Dateien sichern

bash

# Vollbackup
tar -czf itunes-backup-$(date +%F).tar.gz \
    /opt/itunes-persistent/ \
    /etc/systemd/system/itunes-downloader.service

# Queue & Skip-Cache Backup
cp /opt/itunes-persistent/download_queue.txt ~/backup/
cp /opt/itunes-persistent/skip_artwork.txt ~/backup/

Wiederherstellung

bash

# Service stoppen
systemctl stop itunes-downloader

# Backup einspielen
tar -xzf itunes-backup-DATUM.tar.gz -C /

# Service neu laden und starten
systemctl daemon-reload
systemctl start itunes-downloader

---

10. ZUSAMMENFASSUNG

Der iTunes/Last.fm Cover Downloader läuft stabil und zuverlässig. Die niedrige Erfolgsrate von 11-15% ist normal und erwartbar für diese Musik-Sammlung, da:

• Viele Bootlegs und Underground-Releases vorhanden sind
• VA-Compilations selten in APIs verfügbar sind
• Verzeichnisstrukturen teilweise problematisch sind

Der Service hat bereits 2187 Cover in 24 Stunden erfolgreich heruntergeladen und wird die verbleibenden 2901 Einträge durcharbeiten. Danach kann er gestoppt oder für neue Alben reaktiviert werden.

Nächste Schritte nach Abschluss:

1. Service stoppen wenn Queue leer
2. Periodisch neue Queue generieren für neue Alben
3. Ggf. manuelle Cover für wichtige Alben ergänzen

Ombi Media Request System - Konfigurationsdokumentation

Datum: 3. September 2025

Status: Vollständig konfiguriert und produktiv

System-Übersicht

Installation:

• Version: LinuxServer Ombi (latest)
• Container: ombi (/srv/ombi/)
• Port: 3579 (HTTP)
• Zugang: http://192.168.1.102:3579 | http://dergagi.changeip.org:3579
• Database: SQLite (Standard)
• Admin-User: dergagi

Emby-Server-Integration

Server-Konfiguration:

• Server Name: STORE2 Emby
• Hostname: dergagi.changeip.org
• Port: 8920 (HTTPS)
• SSL: Aktiviert
• API Key: d740243a61584180af06df568d56dd23
• Server ID: 5a6aa876ff544473bd36e7ccd9742a8b

Überwachte Bibliotheken:

• Movies ✓
• Serien ✓
• FPV Videos ✓
• Andere deaktiviert

Benutzer-Verwaltung

Importierte Emby-User (9 Personen):

• Benny, Bianka, Chris, Ogi, Hollis, Michi, Flippo, Pitri, Instalazer

Standard-Benutzerrollen:

• Request Movie: Aktiviert
• Request TV: Aktiviert
• Request Music: Aktiviert
• Auto-Approve: Deaktiviert (manuelle Genehmigung)
• Admin: Nur dergagi

Request-Limits:

• Movie Requests: 10/Woche
• Episode Requests: 20/Woche
• Music Requests: Unbegrenzt

Email-Benachrichtigungen

SMTP-Konfiguration:

• Server: mail.gmx.net:587 (STARTTLS)
• Absender: dergagi@gmx.de
• Username: dergagi@gmx.de
• Sender Name: Emby Request
• Admin Email: daniel.gareis@gmail.com

Aktive Benachrichtigungen:

• New Request, Request Approved, Request Available, Request Declined, Welcome Email

User-Login-Verfahren

Authentifizierung: Emby-User-Integration (keine OAuth) Login-Prozess: Username/Password wie bei Emby URL für Freunde: http://dergagi.changeip.org:3579

YT4K System - Zusammenfassung

Server: STORE2 (Debian 13)

URL: http://dergagi.changeip.org:8443/

Status: Voll funktionsfähig

Aktuelle Konfiguration

Service: SystemD-managed yt4k.service

User: www-data:www-data

Port: 8443 (HTTP, Router-forwarded)

Processing: FFmpeg-basiert (3-8 Min pro Video)

Verzeichnisse:

• Anwendung: /srv/yt4k/
• Output: /data/Downloads/YT4K/ (gagi:www-data 775)
• Temp: /tmp/yt4k/

Python-Umgebung

Virtual Env: /srv/yt4k/.venv

Python: 3.13.5

Packages: fastapi, uvicorn, yt-dlp, opencv, numpy

Processing-Pipeline

Aktiv: FFmpeg-basierte AI-Simulation

• Lanczos-Interpolation
• Noise Reduction
• Color Enhancement
• Unsharp Masking
• H.264 Encoding (CRF 16-18)

Deaktiviert: Real-ESRGAN (zu langsam - Stunden pro Video)

API-Endpunkte

• / - Web-Interface
• /upload - Video-Processing
• /status/{job_id} - Progress
• /download/{filename} - Download
• /health - System-Status

Service-Management

bash

systemctl start/stop/restart yt4k.service
journalctl -u yt4k.service -f
curl http://127.0.0.1:8443/health

Performance

Processing-Zeiten:

• 480p→4K: 3-5 Min
• 720p→4K: 5-8 Min
• 1080p→4K: 8-12 Min

Output-Qualität: Hochwertige 4K-Videos (20-50MB typisch)

Troubleshooting

Emergency-Restart:

bash

systemctl restart yt4k.service
rm -rf /tmp/yt4k*

Häufige Probleme:

• Job-Status hängt → Service restart
• Permissions → chown www-data:www-data
• Port nicht erreichbar → Router-Check

Das System ist stabil, produktionsbereit und nutzt bewährte FFmpeg-Technologie für schnelle, zuverlässige Video-Upscaling.

Nextcloud Konfiguration - STORE2

Datum: 01. September 2025

Status: Produktiv, vollständig funktionsfähig

System-Übersicht

Server: STORE2 (192.168.1.102)

OS: Debian 13

Container-System: Docker Compose

Reverse-Proxy: Traefik v3.5

Öffentliche URLs

• Nextcloud (HTTPS): https://nc.dergagi9.duckdns.org:8444
• Nextcloud (HTTP intern): http://192.168.1.102:8086
• Traefik Dashboard: http://192.168.1.102:8082

Authentifizierung

Nextcloud Admin:

• Benutzer: dergagi
• Passwort: Store2@NC#2025

Datenbank (MariaDB):

• Host: db (Docker-intern)
• Datenbank: nextcloud
• Benutzer: nextcloud
• Passwort: Store2@NC#2025

SSL/TLS-Zertifikat

Typ: Let's Encrypt Wildcard-Zertifikat

Domain: *.dergagi9.duckdns.org

Gültigkeitsdauer: Bis 10. Oktober 2025

Issuer: Let's Encrypt (R11)

Speicherort: /srv/traefik/certificates/

Docker-Konfiguration

Traefik (Reverse Proxy)

• Container: traefik-nc
• Image: traefik:v3.5
• Ports: 81→80, 8444→443, 8082→8080
• Config: /srv/traefik/docker-compose.yml
• Zertifikate: /srv/traefik/certificates/dynamic.yml

Nextcloud

• Container: nextcloud-app
• Image: nextcloud:31
• Port: 8086→80 (HTTP intern)
• Config: /srv/nextcloud/docker-compose.yml
• Trusted Domains: nc.dergagi9.duckdns.org:8444

Datenbank

• Container: nextcloud-db
• Image: mariadb:10.11
• Port: 3306 (nur intern)
• Volume: nextcloud_db-data

Netzwerk-Konfiguration

Router-Portweiterleitung:

• Port 81 → 192.168.1.102:81 (HTTP Challenge)
• Port 8444 → 192.168.1.102:8444 (HTTPS Nextcloud)

DNS:

• Provider: DuckDNS
• Domain: nc.dergagi9.duckdns.org
• IP: 91.65.237.120 (automatisches Update aktiv)

Sicherheit

• HTTPS-Only (Port 8444)
• Let's Encrypt-Zertifikat (vertrauenswürdig)
• Apache Store2-Website unberührt (Port 443)
• Alle anderen Dienste isoliert

Wartung

Container neustarten:

bash

<cd /srv/traefik && docker compose restart
cd /srv/nextcloud && docker compose restart

Zertifikat erneuern (vor Oktober 2025):

• Neues Zertifikat von Let's Encrypt holen
• In /srv/traefik/certificates/ ersetzen
• Traefik neustarten

Datensicherung:

• Volume: nextcloud_db-data (Datenbank)
• Volume: nextcloud_nextcloud-data (Dateien)

Integration

Unberührte Dienste:

• Store2-Website (Apache Port 443)
• MediaWiki (Port 8088)
• YT4K (Port 8443)
• HomeBox (Port 3100)
• Alle anderen bestehenden Dienste

Besonderheiten:

• Kein Konflikt mit Apache
• Rate Limit-Problem durch Wildcard-Zertifikat umgangen
• Automatische DNS-Updates durch DuckDNS

Nextcloud Docker Update

Voraussetzungen

• Nextcloud läuft via Docker Compose unter /srv/nextcloud
• Traefik als Reverse Proxy unter /srv/traefik
• Zugriff: https://nc.dergagi9.duckdns.org:8444

Update-Prozedur (Beispiel: 31.0.8 → 31.0.9)

1. Version in docker-compose.yml ändern

cd /srv/nextcloud
nano docker-compose.yml

Ändere die Image-Zeile von:

services:
  app:
    image: nextcloud:31

auf die gewünschte Version:

services:
  app:
    image: nextcloud:31.0.9

Wichtig:

• Bei Minor-Updates (31.0.8 → 31.0.9): Direkt möglich
• Bei Major-Updates (30.x → 31.x): Nur ein Major-Schritt gleichzeitig!
• Nie überspringen (29.x → 31.x geht NICHT)

2. Optional: Datenbank-Backup

docker exec nextcloud-db mariadb-dump -u nextcloud -p'Store2@NC#2025' nextcloud > /root/nextcloud-backup-$(date +%F).sql

3. Update durchführen

# Neues Docker Image herunterladen
docker compose pull

# Container mit neuem Image neu starten
docker compose up -d

4. Automatisches Upgrade abwarten Der Container erkennt die Versionsdifferenz automatisch und führt das Upgrade durch. Dies dauert 30-60 Sekunden. Logs beobachten mit:

docker compose logs -f

Warten auf die Meldung:

Initializing nextcloud 31.0.9...
Upgrading nextcloud from 31.0.8...
Upgrade successful

5. Verifikation

# Version prüfen
docker exec nextcloud-app php occ -V

# Container-Status
docker compose ps

# Web-Interface testen
curl -I https://nc.dergagi9.duckdns.org:8444

Besonderheiten der Installation

Docker-Struktur:

• Nextcloud App: Container nextcloud-app, Port 8086 intern
• Datenbank: Container nextcloud-db (MariaDB 10.11)
• Reverse Proxy: Traefik v3.5 auf Port 8444 (HTTPS)
• Volumes: Daten bleiben in Docker Volumes erhalten

Keine manuellen Schritte nötig:

• ❌ Kein occ upgrade erforderlich
• ❌ Kein Maintenance Mode nötig
• ❌ Kein Web-Updater (bei Docker deaktiviert)
• ✅ Alles läuft automatisch beim Container-Start

Rollback bei Problemen

# Alte Version wiederherstellen
cd /srv/nextcloud
docker compose down

# docker-compose.yml auf alte Version zurücksetzen
nano docker-compose.yml  # Version wieder auf z.B. nextcloud:31.0.8 ändern

# Container neu starten
docker compose up -d

# Optional: Datenbank aus Backup wiederherstellen
docker exec -i nextcloud-db mariadb -u nextcloud -p'Store2@NC#2025' nextcloud < /root/nextcloud-backup-DATUM.sql

Update-Pfad für größere Sprünge Beispiel von Version 29 auf 31:

Speedtest Tracker

Setup-Datum: 04.09.2025

Version: LinuxServer.io Image

Status: Vollautomatisch, produktiv

Installation & Zugriff

Container-Details:

• Container-Name: speedtest-tracker-new
• Image: lscr.io/linuxserver/speedtest-tracker:latest
• Port: 8092 (HTTP)
• URL: http://dergagi.changeip.org:8092
• Login: daniel.gareis@gmail.com / 9@8Cq%UhhWYFs%

Konfiguration

Docker-Compose-Pfad: /opt/speedtest-tracker-new/docker-compose.yml

Finale Environment-Variablen:

SPEEDTEST_SCHEDULE="*/10 * * * *"  # Alle 10 Minuten (Cron-Format)
SPEEDTEST_SERVERS=52770           # Verizon.com Server (944+ Mbps)
TZ=Europe/Berlin
APP_URL=http://dergagi.changeip.org:8092
DB_CONNECTION=sqlite
DISPLAY_TIMEZONE=Europe/Berlin

Abhängige Services:

• InfluxDB: speedtest-influxdb-v2 (Port 8087)
• Datenbank: SQLite (primär) + InfluxDB (optional)

Datenbank & Speicherung

SQLite-Datenbank:

• Container-Pfad: /config/database.sqlite
• Docker-Volume: speedtest-app-data
• Backup-relevant: Ja

InfluxDB (optional):

• Container: speedtest-influxdb-v2
• Port: 8087
• Login: admin / SpeedTest2025!

Automatisierung

Test-Schedule:

• Intervall: Alle 10 Minuten
• Server: Verizon.com (ID: 52770)
• Geschwindigkeit: 944+ Mbps (typisch)
• Wartung: Keine manuelle Wartung erforderlich

Cron-Format Erklärung:

*/10 * * * *
│    │ │ │ │
│    │ │ │ └── Wochentag (0-7, Sonntag = 0 oder 7)
│    │ │ └──── Monat (1-12)
│    │ └────── Tag (1-31)
│    └──────── Stunde (0-23)
└────────────── Minute (0-59, */10 = alle 10 Minuten)

Container-Management

Neustart:

bash

cd /opt/speedtest-tracker-new
docker-compose restart speedtest-tracker

Komplett-Neustart:

bash

cd /opt/speedtest-tracker-new
docker-compose down
docker-compose up -d

Status prüfen:

bash

docker ps | grep speedtest-tracker-new

Logs anzeigen:

bash

docker logs speedtest-tracker-new
docker logs speedtest-tracker-new --tail 50

Konfigurationsprüfung

Environment-Variablen checken:

bash

docker exec speedtest-tracker-new env | grep SPEEDTEST

Container-Config anzeigen:

bash

docker inspect speedtest-tracker-new | grep -A10 -B10 SPEEDTEST

Service-Erreichbarkeit:

bash

curl -s -o /dev/null -w "Status: %{http_code}" http://localhost:8092

Web-Interface Funktionen

Hauptfunktionen:

• Automatische Tests alle 10 Minuten
• Historische Datenansicht
• Server-Auswahl und -Konfiguration
• Statistiken und Trends
• Export-Funktionen

Wichtige Settings:

• Default Server: Verizon.com (52770)
• Schedule: */10 * * * * (alle 10 Minuten)
• Timezone: Europe/Berlin

Troubleshooting

Häufige Probleme:

1. Container startet nicht:

bash

docker logs speedtest-tracker-new
# Prüfe Environment-Variablen und Dependencies

2. Tests laufen nicht automatisch:

bash

docker exec speedtest-tracker-new env | grep SPEEDTEST_SCHEDULE
# Sollte zeigen: SPEEDTEST_SCHEDULE="*/10 * * * *"

3. Falscher Server wird verwendet:

bash

docker exec speedtest-tracker-new env | grep SPEEDTEST_SERVERS
# Sollte zeigen: SPEEDTEST_SERVERS=52770

4. Web-Interface nicht erreichbar:

bash

curl -v http://localhost:8092
# Prüfe Port-Mapping und Container-Status

Backup & Wiederherstellung

Wichtige Backup-Pfade:

• Docker-Compose: /opt/speedtest-tracker-new/docker-compose.yml
• Daten-Volume: speedtest-app-data
• InfluxDB-Volume: influxdb-data (falls verwendet)

Backup erstellen:

bash

cd /opt/speedtest-tracker-new
cp docker-compose.yml docker-compose.yml.backup-$(date +%Y%m%d-%H%M%S)
docker run --rm -v speedtest-app-data:/data -v $(pwd):/backup alpine tar czf /backup/speedtest-data-backup-$(date +%Y%m%d).tar.gz -C /data .

Server-Informationen

Verizon.com Server (52770):

• Standort: USA
• Typische Geschwindigkeit: 944+ Mbps Download
• Latenz: ~26ms
• Zuverlässigkeit: Hoch
• Grund der Auswahl: Beste Geschwindigkeit in Tests

Wartung

Regelmäßige Checks: Keine erforderlich

Log-Rotation: Automatisch durch Docker

Updates: Bei Bedarf über docker-compose pull

Überwachung: Über Uptime Kuma integriert

Grafana Konfiguration

Setup-Datum: 04.09.2025

System: Grafana + Prometheus + Node Exporter

Status: Real-time Monitoring aktiv

Installation & Zugriff

Container-Details:

• Container-Name: grafana-system
• Netzwerk: Host-Netzwerk
• URL: http://dergagi.changeip.org:3000
• Login: admin / QgdQh9ksJraVHL

Prometheus-Stack

Prometheus-Container:

• Name: prometheus-system
• Netzwerk: Host-Netzwerk
• Port: 9090 (intern)
• URL: http://localhost:9090

Node Exporter:

• Name: node-exporter-system
• Port: 9100
• Sammelt: CPU, RAM, Disk, Network-Metriken

Datasource-Konfiguration

Prometheus-Datasource:

• Name: Prometheus-System
• Type: Prometheus
• URL: http://localhost:9090
• Access: Proxy
• Default: Yes
• UID: eex39fbvthon4f

Dashboard

Node Exporter Full Dashboard:

• Metriken: CPU-Auslastung, RAM-Verbrauch, System-Load, Disk-Space, Network-Traffic
• Refresh: 30 Sekunden
• Zeitbereich: Konfigurierbar (Standard: letzte Stunde)

Container-Management

Grafana-Neustart:

bash

docker stop grafana-system
docker rm grafana-system
docker run -d --name grafana-system --network host --restart=unless-stopped \
  -e GF_SECURITY_ADMIN_USER=admin \
  -e GF_SECURITY_ADMIN_PASSWORD=QgdQh9ksJraVHL \
  grafana/grafana:latest

Status-Check:

bash

docker ps --format "table {{.Names}}\t{{.Status}}" | grep -E "(grafana|prometheus|node-exporter)"

Überwachte Metriken

CPU:

• Auslastung in Prozent
• System vs. User vs. Idle
• Load Average (1m, 5m, 15m)

Memory:

• RAM-Verbrauch absolut und prozentual
• SWAP-Nutzung
• Cache + Buffer

Disk:

• Speicherplatz aller Partitionen
• I/O-Statistiken
• Disk-Usage-Trends

Network:

• Ein-/Ausgehender Traffic
• Bytes pro Sekunde
• Interface-Status

Troubleshooting

Grafana-Erreichbarkeit:

bash

curl -s -o /dev/null -w "Status: %{http_code}" http://localhost:3000

Prometheus-Verbindung:

bash

curl -s -o /dev/null -w "Status: %{http_code}" http://localhost:9090/api/v1/query?query=up

Container-Logs:

bash

docker logs grafana-system
docker logs prometheus-system
docker logs node-exporter-system

Wartung

Automatisierung: Vollautomatisch, keine manuelle Wartung

Datensammlung: Alle 30 Sekunden

Retention: Standard Prometheus-Einstellungen

Backup: Container-Volumes bei System-Backup eingeschlossen

Portainer Konfiguration

Zugang:

• URL: http://100.108.194.126:9000 (über Tailscale)
• Lokaler Zugang: http://localhost:9000
• Status: Vollständig funktional

Container-Setup:

• Container: portainer
• Image: portainer/portainer-ce:latest
• Port-Binding: 100.108.194.126:9000→9000/tcp, 127.0.0.1:9000→9000/tcp
• Docker-Compose: /srv/portainer/docker-compose.yml

Daten-Persistierung:

• Datenbank: /srv/portainer/data/portainer.db (524KB)
• Zertifikate: /srv/portainer/data/certs/ (SSL-Certs)
• Konfiguration: /srv/portainer/data/docker_config/

Tailscale-Integration:

• Tailscale-IP: 100.108.194.126
• Interface: tailscale0 (aktiv)
• Netzwerk: hassio Docker-Netzwerk verfügbar

Funktionsumfang:

• Vollständige Docker-Container-Verwaltung
• Monitoring aller STORE2-Services
• Image-Management und Container-Logs
• Network- und Volume-Verwaltung

Letzte Wiederherstellung: 03.09.2025, aus /mnt/nvme_backup/daily.0/srv/portainer

Uptime Kuma Monitoring - Setup-Dokumentation

Datum: 3. September 2025

Status: Vollständig konfiguriert und produktiv

System-Übersicht

Uptime Kuma Installation:

• Version: 1.23.13-alpine (stabile Produktionsversion)
• Zugang: http://192.168.1.102:3001
• Admin-User: dergagi
• Container: uptime-kuma (Docker)
• Daten: /opt/uptime-kuma/data (Bind-Mount)

Überwachte Services (11 aktive Monitore)

Critical Services (5) - Email-Alerts aktiv

1. Home Assistant - http://dergagi.changeip.org:8123
2. MediaWiki Store2 - http://dergagi.changeip.org:8088/
3. Grafana Dashboard - http://dergagi.changeip.org:3030
4. Nextcloud - https://nc.dergagi9.duckdns.org:8444
5. Emby - http://dergagi.changeip.org:8096

Media Services (3) - Email-Alerts aktiv

1. HomeBox - http://dergagi.changeip.org:3100
2. YT4K Upscaler - http://dergagi.changeip.org:8443/
3. Store2 Website - https://dergagi.changeip.org/

Development Services (3) - Email-Alerts aktiv

1. n8n - http://dergagi.changeip.org:5678
2. Portainer - http://100.108.194.126:9000 (via Tailscale)
3. Tailscale - 100.108.194.126 (Ping-Monitor)

Email-Benachrichtigungen

• SMTP: mail.gmx.net:587 (dergagi@gmx.de → daniel.gareis@gmail.com)
• Status: Aktiv für alle 11 Services
• Test: Erfolgreich

Systemstatus

• 11 aktive Monitore: Alle Services grün und stabil
• Response Times: 200-300ms (optimal)
• Nextcloud: Stabilisiert nach Timeout-Optimierung
• Email-System: Vollständig funktional

Das Monitoring-System überwacht erfolgreich die gesamte STORE2-Infrastruktur.

HomeBox Konfiguration

Datum: 03. September 2025

Status: Produktiv, vollständig funktionsfähig

System-Übersicht

• Server: STORE2 (192.168.1.102)
• OS: Debian 13
• Container-System: Docker (Standalone)
• Öffentliche URL: http://dergagi.changeip.org:3100

Authentifizierung

• Benutzer: daniel.gareis@gmail.com
• Passwort: Q6Zv&*YsmDBN3e
• Login-URL: http://dergagi.changeip.org:3100/login

Docker-Konfiguration

• Container-Name: homebox
• Image: ghcr.io/hay-kot/homebox:latest
• Port-Mapping: 3100:7745
• Volume: /srv/homebox:/data
• Restart-Policy: unless-stopped

Container-Management

bash

docker ps | grep homebox
docker stop/start homebox
docker logs homebox --tail 20

Datenbank

• Hauptdatenbank: /srv/homebox/homebox.db (192KB)
• WAL-File: /srv/homebox/homebox.db-wal (424KB)
• Letztes Update: 31. August 2025

Backup & Restore

bash

# Backup
cp -r /srv/homebox /root/homebox-backup-$(date +%Y%m%d-%H%M%S)

# Restore (bei Problemen)
docker stop homebox
rsync -av /mnt/nvme_backup/daily.0/opt/homebox/data/ /srv/homebox/
docker start homebox

Runterfahren über Konsole

umount /data
umount /data2

Falls blockiert, nachschauen wer darauf zugreift mittels

lsof /data 
kill "processid"

shutdown -h now

Webzugang von Außen

in /srv/www/htdocs .htaccess

darin nur den genutzten IPs Zugang erlauben.

Neuer Webuser

htdigest2 /srv/www/.htdigest Store gagihawaii

Webseite verändern

in /srv/www/htdocs/index.template verändern/anpassen

bzw. in /usr/local/bin/update_http.sh Parameter optimieren

dann

/usr/local/bin/update_http.sh

Store2-Website Dokumentation

Übersicht

Die STORE2 Website zeigt System-Monitoring-Daten auf https://dergagi.changeip.org/

• Automatisches Update: Alle 5 Stunden via Cronjob
• Manuelle Updates: /usr/local/bin/update_store2_website.sh

Architektur

Hauptkomponenten

1. Website-Template: /var/www/html/index.template
   • HTML mit Platzhaltern (z.B. )
   • Responsive Design mit blauem Theme
2. Update-Script: /usr/local/bin/update_http.sh
   • Sammelt CPU-Temps, System-Info, RAID-Status
   • Ersetzt Platzhalter im Template
   • Generiert /var/www/html/index.html
   • WICHTIG: Keine HDD-Temperatur-Abfragen mehr (entfernt für Performance)
3. Heatmap-Service: Port 8020
   • Service: heatmap8020.service (systemd)
   • Pfad: /opt/heatmap8020/
   • Hauptdateien:
     • app.py - FastAPI Web-Interface
     • store2_heatmap.py - Rendering-Engine
   • Static Files: /opt/heatmap8020/static/
4. HDD-Temperatur-Sammler: /usr/local/bin/dt.sh
   • Liest Temperaturen von 44 HDDs
   • Output-Format: /dev/sdX -> raid slot serial info temp°C
5. Heatmap-Update: /usr/local/bin/update_heatmap.sh
   • Führt dt.sh aus und piped zu store2_heatmap.py
   • Generiert PNG in /opt/heatmap8020/static/
   • Kopiert zu /var/www/html/heatmap.png
6. Master-Update-Script: /usr/local/bin/update_store2_website.sh
   • Kombiniert Heatmap- und Website-Updates
   • Wird vom Cronjob aufgerufen

Datenquellen

CPU-Temperaturen

• Tool: sensors (lm-sensors)
• 6 Kerne (Core 0-5)
• Anzeige in °C

System-Speicher

• Quelle: /dev/nvme0n1p1
• Anzeige: Frei/Total in GB

Swap

• Quelle: free -h
• Anzeige: Frei/Total in GB

RAID-Arrays

• Data (kleineres RAID): /data (~50TB)
• Data2 (größeres RAID): /data2 (~58TB)
• Status: clean/degraded
• Mountpoint-basierte Erkennung (reboot-sicher)

HDD-Temperaturen

• 44 Festplatten total
• Heatmap zeigt:
  • Slot-Position (#01-#45)
  • Temperatur mit Farbcodierung (35°C grün bis 55°C rot)
  • Seriennummer, Kapazität, Hersteller
  • RAID-Zugehörigkeit (data/data2)

Service-Links

Die Website verlinkt auf folgende Dienste:

• Emby 🎬: Port 8096
• Ombi 📋: Port 3579
• Navidrome 🎵: Port 4533
• HomeBox 📦: Port 3100
• CWA 📚: Port 8084 (Calibre)
• TV 📺: Port 8089
• Wiki 📖: Port 8088 (MediaWiki)

Cronjob-Konfiguration

bash

# Aktiver Cronjob (alle 5 Stunden zur vollen Stunde)
0 */5 * * * /usr/local/bin/update_store2_website.sh >/dev/null 2>&1

Backup-Locations

• Vollbackup vom 17.09.2025: /root/STORE2-VOLLBACKUP-FUNKTIONIERT-20250917-195253/
• Script-Backups:
  • /usr/local/bin/update_http.sh.bak*
  • /usr/local/bin/update_http.sh.before-hdd-removal
  • /usr/local/bin/update_http.sh.with-all-hdds

Wichtige Pfade

/var/www/html/index.template     # HTML-Template mit Platzhaltern
/var/www/html/index.html         # Generierte Website
/var/www/html/heatmap.png        # Aktuelle HDD-Heatmap
/usr/local/bin/update_http.sh    # Website-Update-Script
/usr/local/bin/update_heatmap.sh # Heatmap-Generator
/usr/local/bin/update_store2_website.sh # Master-Update-Script
/usr/local/bin/dt.sh             # HDD-Temperatur-Sammler
/opt/heatmap8020/                # Heatmap-Service-Verzeichnis

Manuelle Operationen

Website sofort aktualisieren

bash

/usr/local/bin/update_store2_website.sh

Nur Heatmap generieren

bash

/usr/local/bin/update_heatmap.sh

Nur Website-Daten aktualisieren (ohne Heatmap)

bash

/usr/local/bin/update_http.sh

Heatmap-Service neustarten

bash

systemctl restart heatmap8020
systemctl status heatmap8020

HDD-Temperaturen manuell prüfen

bash

/usr/local/bin/dt.sh

Performance-Optimierungen

• Entfernte HDD-Abfragen: Ursprünglich waren 40+ einzelne HDD-Temp-Abfragen im update_http.sh Script. Diese wurden komplett entfernt.
• Einmalige HDD-Abfrage: HDDs werden nur noch 1x für die Heatmap abgefragt (via dt.sh)
• Update-Zeit: Von mehreren Minuten auf ~10 Sekunden reduziert

Fehlerbehebung

Heatmap zeigt keine Daten

• Prüfe ob dt.sh korrekte Ausgabe liefert
• Prüfe ob heatmap8020.service läuft
• Schaue in /opt/heatmap8020/static/ nach generierten PNGs

Website zeigt alte Daten

• Manuell updaten: /usr/local/bin/update_store2_website.sh
• Browser-Cache leeren (Strg+F5)

Service nicht erreichbar

• Apache-Status prüfen: systemctl status apache2
• SSL-Zertifikat prüfen
• Port 443 muss offen sein

Änderungshistorie

• 17.09.2025: Große Überarbeitung
  • HDD-Temp-Abfragen aus update_http.sh entfernt
  • Heatmap-Integration implementiert
  • Performance drastisch verbessert
  • Cronjob auf neues Master-Script umgestellt

Store-Webseite ändern

Script unter

/usr/local/bin/update_store2_website.sh

Definierte Inhalte unter

/var/www/html/index.template

Generierte Website selbst unter

/var/www/html/index.html

Router

Fritzbox (als Modem)

192.168.178.1

Hitron Kabelmodem (als Modem im Bridge-Mode)

192.168.100.1

TP-Link TL-WR1043ND (als Router und WLAN-AP) und alle späteren Router

192.168.1.1