Webservices: Unterschied zwischen den Versionen

Aus Store2 Wiki
Zur Navigation springen Zur Suche springen
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
VisuellWikitext
Zeile 153: Zeile 153:
## Neue eBooks nach <code>/data/ebooks</code> kopieren
## Neue eBooks nach <code>/data/ebooks</code> kopieren
## <code>import-new-books</code> ausführen
## <code>import-new-books</code> ausführen
## Monitor für den Import  watch -n 5 'echo "=== CWA IMPORT STATUS ===" && \  echo "📚 DB: $(sqlite3 /data/ebooks/metadata.db "SELECT COUNT(*) FROM books;" 2>/dev/null) Bücher" && \  echo "📥 Queue: $(ls -1 /var/lib/docker/volumes/c1d2bc9a74a4f24cf485f02b7b9fd884ecc02a1f7e812069939d69d449dd51f5/_data 2>/dev/null | wc -l) Files" && \  echo "" && \  echo "Letzte Imports (Web-UI):" && \  docker logs calibre-web-automated --tail 3 2>&1 | grep "Added" || echo "Warte auf Imports..."'


== Wartung ==
== Wartung ==

Version vom 29. September 2025, 13:53 Uhr

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

Übersicht

Service: Calibre-Web Automated (CWA)

Container: crocodilestick/calibre-web-automated:latest

Version: V3.1.4 (Calibre 8.8.0)

Port: 8084 (extern) → 8083 (intern)

Zugriff: http://192.168.1.102:8084 (intern) / http://dergagi.changeip.org:8084 (extern)

Bücher: 10.379 (Stand: 15.09.2025)

Speicherort: /data/ebooks (Host) → /calibre-library (Container)

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:
      - "8084:8083"
    volumes:
      - /data/ebooks:/calibre-library:rw
      - /data/ebooks-config:/config:rw

Pfade

  • Bibliothek: /data/ebooks/ (enthält metadata.db und alle Bücher)
  • Konfiguration: /data/ebooks-config/ (app.db, Einstellungen)
  • Ingest-Ordner: /cwa-book-ingest/ (im Container)

Benutzer-Accounts

Aktive Features

Geplante Aufgaben (täglich 06:00 Uhr)

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

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

  1. Deine Import-Scripts:
    • /usr/local/bin/import-new-books - Hauptscript für neue Bücher
    • /usr/local/bin/cwa-master-import - Vollscan (für große Imports) Workflow für Zukunft:
    1. Neue eBooks nach /data/ebooks kopieren
    2. import-new-books ausführen
    3. Monitor für den Import watch -n 5 'echo "=== CWA IMPORT STATUS ===" && \ echo "📚 DB: $(sqlite3 /data/ebooks/metadata.db "SELECT COUNT(*) FROM books;" 2>/dev/null) Bücher" && \ echo "📥 Queue: $(ls -1 /var/lib/docker/volumes/c1d2bc9a74a4f24cf485f02b7b9fd884ecc02a1f7e812069939d69d449dd51f5/_data 2>/dev/null | wc -l) Files" && \ echo "" && \ echo "Letzte Imports (Web-UI):" && \ docker logs calibre-web-automated --tail 3 2>&1 | grep "Added" || echo "Warte auf Imports..."'

Wartung

Container-Neustart

bash 

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

Datenbank-Backup

bash 

# Automatisch täglich um 06:00 Uhr
# Manuell:
cp /data/ebooks/metadata.db /data/ebooks/metadata.db.backup-$(date +%Y%m%d)

Logs prüfen

bash 

docker logs calibre-web-automated --tail 50

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: ~10-15 Bücher pro Minute
  • Große Imports (>500 Bücher) können 30-60 Minuten dauern

Tiefe Ordnerstrukturen

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

Fehlerbehebung

Container startet nicht

bash 

docker-compose down
docker-compose up -d
docker logs calibre-web-automated

Unvollständige Einträge

Admin → "Mit Calibre Bibliothek neu verbinden" ausführen

Fehlende Metadaten/Cover

Admin → Geplante Aufgaben → "Metadaten Backup" manuell starten

MediaWiki - Aktuelle Konfiguration & Dokumentation

Stand: 03. September 2025, 15:30 Uhr

Status: Produktiv, vollständig funktional nach Container-Wiederherstellung

System-Übersicht

Grundkonfiguration

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

Admin-Zugang

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 ps | grep mw-clean  # Status
docker logs mw-clean-final # Logs

Port-Mapping

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

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 = "http://dergagi.changeip.org:8088";
$wgLanguageCode = "de";
$wgDefaultSkin = "vector";
$wgEnableUploads = true;
$wgLogos = [
    '1x' => "$wgResourceBasePath/images/logo.png",
    'icon' => "$wgResourceBasePath/images/logo.png",
];

# 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

Daten-Inhalt

Wiki-Seiten (12 Hauptseiten + aktuelle Ergänzungen)

  • 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)
  • Aktuelle Ergänzungen: Container-Wiederherstellung-Dokumentation (03.09.2025)

Statistik

  • Seiten: 12+ importiert (erweitert um aktuelle Dokumentation)
  • 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)

# Notfall-Backups (während Wiederherstellung erstellt)
/root/mediawiki-emergency-backup-20250903-151021/  # Sichere aktuelle Daten
/root/mediawiki-before-logo-fix-*/                # Pre-Logo-Fix Backups

# Original-Backups (Fallback)
/root/mediawiki-working-backup.20250831-123906/   # Funktionierendes Backup
/root/STORE2-XML-BACKUP-SAFE-20250831-112526.xml.gz  # XML-Original

Restore-Prozedur (Aktualisiert)

bash 

# Restore aus perfektem Backup (mit Store2-Logo)
cd /root/mediawiki-perfect-with-logo-20250903-152727/
docker-compose -f mediawiki-setup/docker-compose.yml down
docker volume rm mediawiki-clean-final_mw-database mediawiki-clean-final_mw-images
docker-compose -f mediawiki-setup/docker-compose.yml up -d
gunzip < mw-database-perfect.tar.gz | docker run -i --rm -v mediawiki-clean-final_mw-database:/data alpine tar xzf - -C /data
gunzip < mw-images-with-logo.tar.gz | docker run -i --rm -v mediawiki-clean-final_mw-images:/data alpine tar xzf - -C /data
docker cp LocalSettings-perfect.php mw-clean-final:/var/www/html/LocalSettings.php

Docker-Volumes

Volume-Management

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

Container-Wiederherstellung (03.09.2025)

Durchgeführte Reparaturen

  • Problem: Versehentliches docker container prune -f löschte alle Container
  • Lösung: Vollständige Wiederherstellung aus nvme-Backup
  • Status: Erfolgreich wiederhergestellt mit allen Daten
  • Logo-Fix: Store2-Logo neu installiert und auf MediaWiki-Standard skaliert
  • Deprecation-Warning: Über PHP error_reporting unterdrückt

Lessons Learned

  • Backup-Kritikalität: nvme-Backup war entscheidend für Wiederherstellung
  • Vorsichtige Vorgehensweise: Immer Backup vor Systemänderungen
  • Systematische Reparatur: Erst Daten sichern, dann reparieren

Wartung & Maintenance

MediaWiki-Maintenance-Scripts

bash 

# Update-Script
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
docker exec mw-clean-final php /var/www/html/maintenance/initSiteStats.php

Monitoring

  • Port-Check: netstat -tlnp | grep :8088
  • Container-Status: docker ps | grep mw-clean
  • Logs: docker logs mw-clean-final

Integration in STORE2-System

Netzwerk-Konfiguration

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

Dienste-Integration

  • Läuft eigenständig ohne Abhängigkeiten zu anderen Store2-Services
  • Keine Apache-Proxy-Konfiguration erforderlich
  • Automatischer Docker-Start mit System

Sicherheit & Zugänge

Authentifizierung

  • Keine Apache-BasicAuth (direkter Port-Zugang)
  • MediaWiki-eigene Benutzerkonten
  • Admin-Account für Vollzugriff

Netzwerk-Sicherheit

  • Port 8088 HTTP-only (kein HTTPS konfiguriert)
  • Datenbank nicht extern exposed
  • Container-zu-Container Kommunikation über Docker-Netzwerk

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

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:sync

# 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)

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
Abgerufen von „https://dergagi.changeip.org/w/index.php?title=Webservices&oldid=1118“