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

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

• Admin-User: admin
• Admin-Passwort: CleanFinalMW2025!
• Admin-URL: http://dergagi.changeip.org:8088/index.php/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 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.

Status nach Container-Wiederherstellung: Alle ursprünglichen Inhalte aus dem 2010er System erfolgreich migriert, erweitert um aktuelle Dokumentation, mit professionellem Store2-Logo und ohne störende Deprecation-Warnings.

Kavita E-Book Server - Konfigurationsdokumentation

Service-Übersicht

• Dienst: Kavita E-Book/PDF Library Server
• Version: v0.8.7.0 (jvmilazz0/kavita:latest)
• Port: 5000 (HTTP)
• URL: http://dergagi.changeip.org:5000
• Installation: /srv/kavita/
• Daten: /data/ebooks/ (107,9 GB, 41.681 Objekte)

Docker-Konfiguration

yaml

# /srv/kavita/docker-compose.yml
services:
  kavita:
    image: jvmilazz0/kavita:latest
    container_name: kavita-ebooks
    restart: unless-stopped
    ports:
      - "5000:5000"
    volumes:
      - ./config:/kavita/config
      - /data/ebooks:/books
      - ./data:/kavita/data
    environment:
      - TZ=Europe/Berlin
    user: 1000:1000

Verzeichnisstruktur

/srv/kavita/
├── docker-compose.yml
├── config/          (Kavita Konfiguration)
└── data/           (Kavita Datenbank)

/data/ebooks/        (E-Book Sammlung)
├── E-Books Sebastian/     (47,6 GB)
├── 00 - Hörbücher/       (35,6 GB)
├── Programming/          (9,4 GB)
├── Original/             (3,1 GB)
└── [weitere Kategorien...]

Benutzer & Berechtigungen

• Container-User: 1000:1000 (gagi)
• Dateiberechtigungen: gagi:gagi auf alle E-Book-Verzeichnisse
• Multi-User fähig: Ja, über Web-UI administrierbar

Besonderheiten

• Repository-Migration: Von kizaing/kavita zu jvmilazz0/kavita
• Automatische Indizierung: Läuft bei Container-Start
• PDF-Warnings: Normal bei verschlüsselten/beschädigten PDFs
• Backup: /root/kavita-backup-* bei Migration erstellt

Navidrome Konfiguration

📋 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

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 traefik-nc
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

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

Store-Webseite ändern

Script unter

/usr/local/bin/update_http.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