Webservices

Aus Store2 Wiki
Zur Navigation springen Zur Suche springen

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

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