docs: add all untracked content

2026-06-28 14:43:36 +00:00
parent c1b9f197fe
commit f1adaf1941
59 changed files with 1289 additions and 0 deletions
@@ -1,3 +1,13 @@
 ---
 title: hardware
 description: 
 published: true
 date: 2026-06-28T14:29:27.393Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:25.659Z
 ---
 # Hardware – Raspberry PI2
 **Zusammenfassung**: Der `hoobs` ist ein Raspberry Pi 2 Model B Rev 1.1 mit 921 MB RAM, passiver Kühlung und drei USB-Geräten. Läuft bei ~58 °C CPU-Temperatur.
@@ -1,3 +1,13 @@
 ---
 title: netzwerk
 description: 
 published: true
 date: 2026-06-28T14:29:29.932Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:28.139Z
 ---
 # Netzwerk – Raspberry PI2
 **Zusammenfassung**: Der PI2 `hoobs` ist per Kabel (eth0) an die FritzBox angebunden. DNS läuft lokal über Pi-hole, Netzwerkkonfiguration via NetworkManager.
@@ -1,3 +1,13 @@
 ---
 title: sicherheit
 description: 
 published: true
 date: 2026-06-28T14:29:32.536Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:30.697Z
 ---
 # Sicherheit – Raspberry PI2
 **Zusammenfassung**: SSH-Zugriff ist auf Public-Key-Authentifizierung beschränkt. UFW-Firewall ist aktiv. Einige Sicherheitslücken bestehen (Klartext-Passwörter, kein automatischer OS-Update-Zwang).
@@ -1,3 +1,13 @@
 ---
 title: apache
 description: 
 published: true
 date: 2026-06-28T14:30:30.779Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:29.072Z
 ---
 # Apache HTTP Server
 **Zusammenfassung**: Apache2 läuft mit drei VirtualHosts: Standard-Port 80, Standard-SSL auf 443 und eine SAP-UI5-App auf Port 65443 (HTTPS mit selbstsigniertem Zertifikat).
@@ -1,3 +1,13 @@
 ---
 title: helm
 description: 
 published: true
 date: 2026-06-28T14:30:33.210Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:31.514Z
 ---
 # Helm – HOOBS Helm-UI
 **Zusammenfassung**: Helm ist ein Node.js-basiertes Interface/Shell für HOOBS, das auf Port 9090 läuft. Teil der HOOBS-Plattform.
@@ -1,3 +1,13 @@
 ---
 title: hoobs
 description: 
 published: true
 date: 2026-06-28T14:30:35.733Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:34.041Z
 ---
 # HOOBS – Smart-Home-Hub
 **Zusammenfassung**: HOOBS (Homebridge-basiert) ist die Smart-Home-Zentrale auf dem PI2. Läuft als `hoobsd.service` und verbindet HomeKit mit Nicht-HomeKit-Geräten.
@@ -1,3 +1,13 @@
 ---
 title: music-social-api
 description: 
 published: true
 date: 2026-06-28T14:30:38.823Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:36.580Z
 ---
 # Music Social API – Spotify/Music Proxy
 **Zusammenfassung**: Node.js-Express-API, die als Proxy für die Spotify-API dient. Ermöglicht OAuth2-Flow mit Spotify, Playlist-Verwaltung und Music-Social-Features.
@@ -1,3 +1,13 @@
 ---
 title: pihole
 description: 
 published: true
 date: 2026-06-28T14:30:41.325Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:39.562Z
 ---
 # Pi-hole – DNS-Adblocker
 **Zusammenfassung**: Pi-hole blockt netzwerkweit Werbung und Tracker auf DNS-Ebene. Läuft als `pihole-FTL.service` auf dem PI2.
@@ -1,3 +1,13 @@
 ---
 title: samba
 description: 
 published: true
 date: 2026-06-28T14:30:43.795Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:42.067Z
 ---
 # Samba – Dateifreigaben
 **Zusammenfassung**: Samba stellt Dateifreigaben im Heimnetz (Workgroup DA-HOME) bereit, insbesondere die 1,8-TB-Seagate-Externe.
@@ -1,3 +1,13 @@
 ---
 title: wiim-proxy
 description: 
 published: true
 date: 2026-06-28T14:30:46.257Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:44.555Z
 ---
 # WiiM Proxy – API-Proxy für WiiM-Lautsprecher
 **Zusammenfassung**: Node.js-Express-Proxy für den lokalen Netzwerkzugriff auf die WiiM-API. Ermöglicht Steuerung von WiiM-Lautsprechern (Multiroom-Audio) aus dem LAN.
@@ -1,3 +1,13 @@
 ---
 title: laufwerke-und-speicher
 description: 
 published: true
 date: 2026-06-28T14:29:35.030Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:33.307Z
 ---
 # Laufwerke und Speicher – Raspberry PI2
 **Zusammenfassung**: Der Raspberry PI2 hat eine SD-Karte als Systemlaufwerk, einen USB-Stick für Pi-hole und Konfiguration sowie eine 1,8-TB-USB-Festplatte als Datengrab.
@@ -1,3 +1,13 @@
 ---
 title: systemuebersicht
 description: 
 published: true
 date: 2026-06-28T14:29:37.585Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:35.833Z
 ---
 # Systemübersicht – Raspberry PI2
 **Zusammenfassung**: Der Raspberry PI2 `hoobs` läuft mit Raspbian GNU/Linux 11 "bullseye" (armv7l) und 921 MB RAM. Smart-Home-Hub mit HOOBS (Homebridge), Pi-hole DNS-Adblocker, Samba-Freigaben und Apache-Webserver.
@@ -1,3 +1,13 @@
 ---
 title: index
 description: 
 published: true
 date: 2026-06-28T14:29:17.191Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:15.465Z
 ---
 # Konfigurationsindex – Raspberry PI2
 **Zusammenfassung**: Inhaltsverzeichnis aller Konfigurationsseiten des Raspberry PI2 `hoobs`.
@@ -1,3 +1,13 @@
 ---
 title: log
 description: 
 published: true
 date: 2026-06-28T14:29:19.623Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:17.942Z
 ---
 # Änderungslog – Raspberry PI2
 **Zusammenfassung**: Alle dokumentierten Änderungen am PI2-System.
@@ -1,3 +1,13 @@
 ---
 title: hardware
 description: 
 published: true
 date: 2026-06-28T14:29:40.200Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:38.452Z
 ---
 # Hardware – Raspberry PI5
 **Zusammenfassung**: Der `da-server-pi5` ist ein Raspberry PI5 mit 15 GB RAM, aktivem Kühler und drei USB-Massenspeichern. Läuft stabil bei ~46 °C CPU-Temperatur.
@@ -1,3 +1,13 @@
 ---
 title: netzwerk
 description: 
 published: true
 date: 2026-06-28T14:29:42.678Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:40.941Z
 ---
 # Netzwerk – Raspberry PI5
 **Zusammenfassung**: Der PI5 hat eine kabelgebundene (eth0) und eine WLAN-Schnittstelle (wlan0). DNS läuft über die FritzBox, Netzwerkkonfiguration via NetworkManager.
@@ -1,3 +1,13 @@
 ---
 title: sicherheit
 description: 
 published: true
 date: 2026-06-28T14:29:45.244Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:43.449Z
 ---
 # Sicherheit – Raspberry PI5
 **Zusammenfassung**: SSH-Zugriff ist auf Public-Key-Authentifizierung beschränkt. Einige Sicherheitslücken bestehen (Grafana-Passwort, Gitea-Container-Konfiguration).
@@ -1,3 +1,13 @@
 ---
 title: docker-grundlagen
 description: 
 published: true
 date: 2026-06-28T14:29:47.808Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:45.990Z
 ---
 # Docker-Grundlagen
 **Zusammenfassung**: Der Raspberry PI5 betreibt Docker Engine v29.5.3 mit Compose v5.1.4. 31 Container (30 laufend) aus 13 Compose-Stacks inkl. [authelia](./docker/authelia.md) (aktiv seit 18.06.). Alle Compose-Dateien heißen `docker-compose.yml`.
@@ -1,3 +1,13 @@
 ---
 title: docker-services
 description: 
 published: true
 date: 2026-06-28T14:29:50.405Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:48.566Z
 ---
 # Docker-Dienste – Übersicht
 **Zusammenfassung**: 30 laufende + 1 gestoppter Container auf dem Raspberry PI5, aufgeteilt in 13 Stacks mit [authelia](./docker/authelia.md) aktiv. Die meisten Dienste sind über Traefik mit Let's Encrypt TLS erreichbar.
@@ -1,3 +1,13 @@
 ---
 title: authelia
 description: 
 published: true
 date: 2026-06-28T14:30:48.985Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:47.007Z
 ---
 # Authelia – SSO mit Passkey-Unterstützung
 **Zusammenfassung**: Authelia als ForwardAuth-Provider für Traefik. Ermöglicht Single Sign-On (SSO) für alle Dienste hinter Traefik – mit Passwort, Passkey (WebAuthn/FIDO2) oder beidem.
@@ -1,3 +1,13 @@
 ---
 title: collabora
 description: 
 published: true
 date: 2026-06-28T14:30:51.572Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:49.783Z
 ---
 # Collabora Online – Office-Dokumente
 **Zusammenfassung**: Collabora Online ermöglicht die Bearbeitung von Office-Dokumenten (Writer, Calc, Impress) im Browser. Eingebunden in Nextcloud via WOPI-Protokoll.
@@ -1,3 +1,13 @@
 ---
 title: gitea
 description: 
 published: true
 date: 2026-06-28T14:30:54.203Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:52.337Z
 ---
 # Gitea – Git-Service
 **Zusammenfassung**: Gitea ist ein selbstgehosteter Git-Service (ähnlich GitHub/GitLab) mit MariaDB-Datenbank. Erreichbar über Traefik und SSH auf Port 2222.
@@ -1,3 +1,13 @@
 ---
 title: immich
 description: 
 published: true
 date: 2026-06-28T14:30:56.638Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:54.956Z
 ---
 # Immich – Foto-Management
 **Zusammenfassung**: Immich dient als Google-Photos-Alternative mit automatischem Backup, Gesichtserkennung und ML-basierter Suche. Läuft intern (Traefik-Labels auskommentiert).
@@ -1,3 +1,13 @@
 ---
 title: jenkins
 description: 
 published: true
 date: 2026-06-28T14:30:59.137Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:57.373Z
 ---
 # Jenkins – CI/CD
 **Zusammenfassung**: Jenkins automatisiert Builds und Deployments. Läuft als Root-Container mit Docker-Socket-Zugriff, um Containermanagement und Compose-Deployments zu ermöglichen.
@@ -1,3 +1,13 @@
 ---
 title: monitoring
 description: 
 published: true
 date: 2026-06-28T14:31:01.592Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:59.877Z
 ---
 # Monitoring-Stack
 **Zusammenfassung**: Prometheus/Grafana-Monitoring-Stack mit Prometheus, Grafana, cAdvisor, Node-Exporter und Alertmanager. Läuft mit `restart: unless-stopped` für automatischen Neustart nach Reboot.
@@ -1,3 +1,13 @@
 ---
 title: nextcloud
 description: 
 published: true
 date: 2026-06-28T14:31:04.438Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:31:02.467Z
 ---
 # Nextcloud
 **Zusammenfassung**: Nextcloud läuft als Cloud-Speicher mit MariaDB, Redis-Cache und Docker-Socket-Proxy. Erreichbar unter `cloud.da.home-webserver.de`.
@@ -1,3 +1,13 @@
 ---
 title: nginx
 description: 
 published: true
 date: 2026-06-28T14:31:06.951Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:31:05.274Z
 ---
 # Nginx – Static Webserver
 **Zusammenfassung**: Ein minimalistischer Nginx-Container für statische Webseiten. Läuft mit `nginx:alpine` und wird über Traefik angesteuert.
@@ -1,3 +1,13 @@
 ---
 title: paperless
 description: 
 published: true
 date: 2026-06-28T14:31:09.558Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:31:07.698Z
 ---
 # Paperless-ngx – Dokumentenmanagement
 **Zusammenfassung**: Paperless-ngx archiviert, verschlagwortet und durchsucht Dokumente automatisch. Inklusive OCR via Tika und Gotenberg für Office-Konvertierung.
@@ -1,3 +1,13 @@
 ---
 title: plex
 description: 
 published: true
 date: 2026-06-28T14:31:12.008Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:31:10.322Z
 ---
 # Plex – Media Server
 **Zusammenfassung**: Plex Media Server streamt Filme, Serien und Musik. Läuft mit LinuxServer.io-Image und direktem Port-Mapping (kein Traefik).
@@ -1,3 +1,13 @@
 ---
 title: stirling-pdf
 description: 
 published: true
 date: 2026-06-28T14:31:14.540Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:31:12.765Z
 ---
 # Stirling PDF – PDF-Bearbeitung
 **Zusammenfassung**: Stirling PDF ist ein webbasiertes PDF-Werkzeug (Zusammenführen, Teilen, Konvertieren, OCR, Bearbeiten). Läuft als eigenständiger Container.
@@ -1,3 +1,13 @@
 ---
 title: traefik
 description: 
 published: true
 date: 2026-06-28T14:31:17.139Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:31:15.285Z
 ---
 # Traefik – Reverse Proxy
 **Zusammenfassung**: Traefik läuft als zentraler Reverse Proxy mit Let's Encrypt TLS-Terminierung. Alle öffentlichen Dienste hängen am selben Docker-Netzwerk `traefik`. Die Routing-Konfiguration erfolgt per **File Provider** (YAML-Dateien in `/conf.d/`), nicht per Docker-Labels.
@@ -1,3 +1,13 @@
 ---
 title: wikijs
 description: 
 published: true
 date: 2026-06-28T14:31:19.563Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:31:17.884Z
 ---
 # Wiki.js – Wissensdatenbank
 **Zusammenfassung**: Wiki.js ist eine moderne Wiki-Plattform mit PostgreSQL-Datenbank. Bietet Markdown-Editor, Versionierung und Zugriffskontrolle.
@@ -1,3 +1,13 @@
 ---
 title: domain-und-ssl
 description: 
 published: true
 date: 2026-06-28T14:29:52.913Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:51.141Z
 ---
 # Domain & SSL
 **Zusammenfassung**: Alle Dienste laufen unter der Domain `da.home-webserver.de` mit Subdomains. TLS-Zertifikate werden automatisch per Let's Encrypt (HTTP-Challenge) über Traefik bezogen.
@@ -1,3 +1,13 @@
 ---
 title: cryptsetup
 description: 
 published: true
 date: 2026-06-28T14:31:21.991Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:31:20.304Z
 ---
 # cryptsetup – Befehle für LUKS-Container
 **Zusammenfassung**: Die wichtigsten `cryptsetup`-Befehle zur Verwaltung von LUKS-verschlüsselten Containern – vom Öffnen und Schließen bis zur Schlüsselverwaltung.
@@ -1,3 +1,13 @@
 ---
 title: crypttab
 description: 
 published: true
 date: 2026-06-28T14:31:24.537Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:31:22.766Z
 ---
 # crypttab – LUKS-Entschlüsselungstabelle
 **Zusammenfassung**: Die `/etc/crypttab` steuert, welche LUKS-verschlüsselten Container beim Boot automatisch geöffnet werden. Der Raspberry PI5 verwendet zwei LUKS2-Container, die mit Schlüsseldateien auf einem USB-Stick entsperrt werden.
@@ -1,3 +1,13 @@
 ---
 title: fstab
 description: 
 published: true
 date: 2026-06-28T14:31:26.995Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:31:25.279Z
 ---
 # fstab – Dateisystemtabelle
 **Zusammenfassung**: Die `/etc/fstab` steuert, welche Dateisysteme wo und mit welchen Optionen gemountet werden. Alle Einträge verwenden persistente Referenzen (PARTUUID oder `/dev/mapper/`), um sdX-Vertauschungen zu vermeiden.
@@ -1,3 +1,13 @@
 ---
 title: systemd-cryptsetup
 description: 
 published: true
 date: 2026-06-28T14:31:29.472Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:31:27.749Z
 ---
 # systemd-cryptsetup – Boot-Reihenfolge und Abhängigkeiten
 **Zusammenfassung**: systemd steuert die Reihenfolge beim Boot: Zuerst muss der USB-Stick mit den Schlüsseldateien gemountet sein, dann können die LUKS-Container geöffnet werden. Spezielle crypttab-Optionen stellen dies sicher.
@@ -1,3 +1,13 @@
 ---
 title: laufwerke-und-speicher
 description: 
 published: true
 date: 2026-06-28T14:29:55.475Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:53.694Z
 ---
 # Laufwerke und Speicher
 **Zusammenfassung**: Der Raspberry PI5 hat drei physische Laufwerke (USB-Key, 931-GB-SSD auf sdb, 1,8-TB-SSD auf sdc) mit zwei LUKS2-verschlüsselten Datenpartitionen. Beide Partitionen enthalten identische Daten – vermutlich eine 1:1-Kopie.
@@ -1,3 +1,13 @@
 ---
 title: luks-verschluesselung
 description: 
 published: true
 date: 2026-06-28T14:29:57.983Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:56.227Z
 ---
 # LUKS-Verschlüsselung
 **Zusammenfassung**: LUKS (Linux Unified Key Setup) ist der Standard für Festplattenverschlüsselung unter Linux. Der Raspberry PI5 verwendet zwei LUKS2-Container für Datenpartitionen.
@@ -1,3 +1,13 @@
 ---
 title: opt-compose
 description: 
 published: true
 date: 2026-06-28T14:30:00.446Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:58.728Z
 ---
 # /opt/compose – Compose-Struktur
 **Zusammenfassung**: Alle Docker-Stack-Konfigurationen liegen in `/opt/compose/`. Jeder Stack hat sein eigenes Unterverzeichnis mit einer `docker-compose.yml` und ggf. Konfigurationsdateien.
@@ -1,3 +1,13 @@
 ---
 title: persistente-blockgeraete
 description: 
 published: true
 date: 2026-06-28T14:30:03.183Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:01.306Z
 ---
 # Persistente Blockgeräte-Referenzen
 **Zusammenfassung**: UUID, PARTUUID und `/dev/disk/by-*`-Pfade identifizieren Partitionen eindeutig und unabhängig von der dynamischen `/dev/sdX`-Benennung – essenziell für stabile Mounts.
@@ -1,3 +1,13 @@
 ---
 title: sdx-vertauschung
 description: 
 published: true
 date: 2026-06-28T14:30:05.704Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:03.962Z
 ---
 # sdX-Vertauschung – Wechselnde Gerätenamen
 **Zusammenfassung**: Die Namen `/dev/sda`, `/dev/sdb`, `/dev/sdc` können sich bei jedem Neustart ändern. Dieses Dokument erklärt die Ursache, die Auswirkungen und wie persistente Referenzen das Problem lösen.
@@ -1,3 +1,13 @@
 ---
 title: swap-zram
 description: 
 published: true
 date: 2026-06-28T14:30:08.220Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:06.431Z
 ---
 # Swap – zram und loop
 **Zusammenfassung**: Der Raspberry PI5 verwendet **zram** (komprimierten RAM-Swap) und **loop** (Datei-basierten Swap) statt eines klassischen Swap-Eintrags in der fstab. systemd verwaltet diese automatisch.
@@ -1,3 +1,13 @@
 ---
 title: systemuebersicht
 description: 
 published: true
 date: 2026-06-28T14:30:10.736Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:08.965Z
 ---
 # Systemübersicht
 **Zusammenfassung**: Der Raspberry PI5 `da-server-pi5` läuft mit Debian 13 "trixie" (aarch64) und 15 GB RAM. Docker-Host für 31 Container (30 laufend), 13 Compose-Stacks unter `/opt/compose/`.
@@ -0,0 +1,160 @@
 ---
 title: Monitoring und Alerting Setup
 description: 
 published: true
 date: 2026-01-14T20:26:36.634Z
 tags: pi5, monitoring, alerting
 editor: markdown
 dateCreated: 2026-01-14T20:23:26.086Z
 ---
 Das ist eine hervorragende Idee. Eine saubere Dokumentation ist das A und O, wenn man in sechs Monaten mal etwas ändern muss oder das System neu aufsetzen will.
 Hier ist die Zusammenfassung deines Monitoring-Stacks für den Raspberry Pi 5.
 ---
 ## System-Dokumentation: Docker-Monitoring & Alerting
 Dieses Setup überwacht Docker-Container in Echtzeit und sendet kritische Statusänderungen sowie Ressourcen-Engpässe direkt via Telegram-Bot an den Administrator.
 ### 1. Die Architektur
 Das System besteht aus vier Kernkomponenten:
 * **cAdvisor:** Liest Ressourcen-Daten (CPU, RAM, Status) direkt vom Docker-Daemon.
 * **Prometheus:** Sammelt diese Daten (Scraping) und gleicht sie mit definierten Alarm-Regeln ab.
 * **Alertmanager:** Empfängt Alarme von Prometheus, gruppiert sie und regelt den Versand.
 * **Telegram-API:** Dient als Zustellungsweg für die Benachrichtigungen.
 ---
 ### 2. Konfigurationsdateien
 #### A. Prometheus Rules (`alert_rules_docker.yml`)
 Hier ist die Logik definiert, wann ein Alarm ausgelöst wird.
 * **ContainerDown:** Prüft über `time() - container_last_seen`, ob ein Container länger als 60 Sekunden keine Daten mehr gesendet hat.
 * **HighContainerMemory:** Warnt, wenn ein Container dauerhaft mehr als 1 GB RAM belegt.
 #### B. Alertmanager Config (`alertmanager.yml`)
 Regelt das Layout und den Versandweg.
 * **Grouping:** Fasst Alarme nach `alertname` und `name` zusammen, um Fluten bei Systemstarts zu vermeiden.
 * **Template:** Nutzt HTML-Formatierung für Telegram, um Informationen wie Dienstname, Startzeit und Beschreibung sauber darzustellen.
 ---
 ### 3. Wichtige Befehle für die Verwaltung
 | Aktion | Befehl |
 | --- | --- |
 | **Konfiguration neu laden** | `docker exec -it monitoring-prometheus kill -SIGHUP 1` |
 | **Alertmanager neu laden** | `docker exec -it monitoring-alertmanager kill -SIGHUP 1` |
 | **Logs prüfen (Fehlersuche)** | `docker logs -f monitoring-alertmanager` |
 | **Regel-Check (Syntax)** | `promtool check rules /pfad/zu/rules.yml` |
 ---
 ### 4. Endpunkte im Netzwerk
 * **Prometheus Web-UI:** `http://<Pi-IP>:9090` (Hier werden Regeln und Metriken visualisiert).
 * **Alertmanager-UI:** `http://<Pi-IP>:9093` (Hier können Alarme stummgeschaltet/Silenzen werden).
 * **cAdvisor Metriken:** `http://<Pi-IP>:8080/metrics` (Rohdatenquelle).
 ---
 ### 5. Sicherheitsrelevante Daten
 * **Bot-User:** `@YourBotName`
 * **Chat-ID:** `1925816130` (Deine persönliche Telegram-ID)
 * **Wichtig:** Der Bot-Token wurde am 14.01.2026 rotiert und sollte niemals im Klartext in öffentlichen Repositories (z. B. GitHub) landen.
 ---
 ### 6. Wartungshinweise
 * **Log-Rotation:** Docker-Container sollten mit einem Log-Limit konfiguriert sein (z. B. `max-size: 10m`), damit die SD-Karte des Pi 5 nicht durch Metrik-Logs gefüllt wird.
 * **Updates:** Einmal im Monat `docker compose pull` ausführen, um Sicherheitsupdates für Prometheus und cAdvisor zu erhalten.
 ---
 **Soll ich dir noch die passende `docker-compose.yml` Sektion für die Log-Begrenzung (Log-Rotation) heraussuchen, damit dein Pi langfristig stabil bleibt?**
 Das ist ein sehr wichtiger Punkt für einen Raspberry Pi, da Docker standardmäßig unendlich große Log-Dateien schreibt, was bei einem Monitoring-System (viele Schreibvorgänge!) schnell die SD-Karte füllen kann.
 Hier ist die Ergänzung für deine Dokumentation, wie du die **Log-Rotation** global für alle Monitoring-Container in deiner `docker-compose.yml` festlegst.
 ### Log-Rotation in der `docker-compose.yml`
 Füge diesen `logging`-Block zu jedem deiner Dienste (Prometheus, Alertmanager, cAdvisor) hinzu:
 ```yaml
 services:
  prometheus:
    image: prom/prometheus:latest
    container_name: monitoring-prometheus
    # ... deine anderen Einstellungen ...
    logging:
      driver: "json-file"
      options:
        max-size: "10m"   # Maximale Größe einer Datei (10 Megabyte)
        max-file: "3"     # Behalte maximal 3 Dateien (insg. 30MB)
  alertmanager:
    image: prom/alertmanager:latest
    container_name: monitoring-alertmanager
    # ...
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    container_name: monitoring-cadvisor
    # ...
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
 ```
 ---
 ### Warum ist das wichtig? (Doku-Notiz)
 Ohne diese Einstellung wächst die Datei `/var/lib/docker/containers/.../*-json.log` ununterbrochen an. Besonders cAdvisor und Prometheus erzeugen viele Statusmeldungen. Mit dieser Konfiguration:
 1. Wird die Log-Datei bei **10 MB** "abgeschnitten".
 2. Wird eine neue Datei angefangen.
 3. Wird die älteste Datei gelöscht, sobald mehr als **3 Dateien** existieren.
 4. Dein Speicherverbrauch pro Container für Logs bleibt also bei **maximal 30 MB** gedeckelt.
 ### Aktivierung
 Damit die Änderung greift, musst du die Container einmal neu erstellen lassen:
 ```bash
 docker compose up -d
 ```
 ---
 ### Zusammenfassung deiner Monitoring-Doku (Finaler Stand)
 | Komponente | Zweck | Wichtigste Datei |
 | --- | --- | --- |
 | **Metriken** | cAdvisor | `docker-compose.yml` |
 | **Logik** | Prometheus | `alert_rules_docker.yml` |
 | **Versand** | Alertmanager | `alertmanager.yml` |
 | **Sicherheit** | Log-Rotation | `max-size: 10m` |
 | **Output** | Telegram | `@YourBot` |
 Damit ist dein Pi 5 jetzt ein echtes "Self-Healing" Monitoring-System!
@@ -0,0 +1,210 @@
 ---
 title: Nextcloud Collabora Integration
 description: Zusammenfassung der Konfiguration
 published: true
 date: 2026-01-13T20:40:44.149Z
 tags: nextcloud, collabora, pi5, home server, hard piece of work, a very hard piece of work
 editor: markdown
 dateCreated: 2026-01-13T19:49:53.576Z
 ---
 # Collabora-Anbindung an Nextcloud (Docker-Setup mit Traefik auf einem Raspberry Pi 5).
 ---
 Dies ist eine umfassende Dokumentation deiner Nextcloud Collabora Anbindung, basierend auf der erfolgreichen Fehlerbehebung vom 13. Januar 2026.
 ---
 ## Nextcloud Office (Collabora) Integration
 ### 1. System-Umgebung
 * **Hardware:** Raspberry Pi 5
 * **Setup:** Docker Compose (Nextcloud & Collabora in separaten Containern)
 * **Reverse Proxy:** Traefik (HTTPS-Terminierung)
 * **Domains:** `cloud.da.home-webserver.de` & `office.da.home-webserver.de`
 ### 2. Kernprobleme & Fehlerbilder
 Während der Einrichtung traten folgende kritische Fehler auf:
 * **Meldung:** "No files provided" im Browser-Viewer.
 * **Log-Fehler:** `HTTP 500` beim Abrufen von `documentView.xcu`.
 * **Performance:** Datenbank-Transaktionen dauerten über 90 Sekunden (`Exception: Transaction took 96.93s`).
 ### 3. Gelöste Schritte (Fixes)
 #### A. Datenbank-Optimierung (Performance Fix)
 Der wichtigste Schritt war die Stabilisierung der Datenbank, da hängende Transaktionen den WOPI-Handshake zwischen Nextcloud und Collabora verhinderten.
 ```bash
 # Fehlende Indizes ergänzen
 docker exec -u www-data nextcloud php occ db:add-missing-indices
 # Große Datei-IDs unterstützen
 docker exec -u www-data nextcloud php occ db:convert-filecache-bigint
 ```
 #### B. WOPI & App-Konfiguration
 Damit Nextcloud und Collabora sauber kommunizieren, wurden die Endpunkte fixiert und Zertifikatsprüfungen (für internes Routing) entspannt.
 ```bash
 # App-Setup ausführen & Mimetypes registrieren
 docker exec -u www-data nextcloud php occ richdocuments:setup
 # Zertifikatsprüfung deaktivieren (falls Loopback-Probleme auftreten)
 docker exec -u www-data nextcloud php occ config:app:set richdocuments disable_certificate_verification --value="yes"
 # Timeout erhöhen (wegen Pi-Latenz)
 docker exec -u www-data nextcloud php occ config:app:set richdocuments wopi_timeout --value="120"
 ```
 #### C. Reverse Proxy Header (Overwrite-Parameter)
 Damit Nextcloud die korrekten URLs generiert, müssen die `overwrite`-Parameter in der `config.php` gesetzt sein:
 ```bash
 docker exec -u www-data nextcloud php occ config:system:set overwritehost --value="cloud.da.home-webserver.de"
 docker exec -u www-data nextcloud php occ config:system:set overwriteprotocol --value="https"
 docker exec -u www-data nextcloud php occ config:system:set trusted_proxies 0 --value="172.18.0.0/16"
 ```
 #### D. Reset "Hängende Einstellungen"
 Alte, fehlerhafte Ansichtseinstellungen wurden gelöscht, um den `HTTP 500` zu beheben:
 ```bash
 docker exec -u www-data nextcloud php occ config:app:delete richdocuments doc_viewer
 ```
 ---
 ### 4. Best Practices für den Betrieb auf dem Pi 5
 * **Vorschaubilder:** Bei Performance-Einbußen Previews deaktivieren (`occ config:system:set enable_previews --value="false" --type=boolean`).
 * **Memory Limit:** Sicherstellen, dass PHP mindestens **512M** (besser **1G**) zur Verfügung hat.
 * **Apps:** Die App "Built-in CODE Server" darf **nicht** parallel zum Collabora-Container installiert sein.
 ---
 **Soll ich dir die passenden `environment`-Variablen für deine `docker-compose.yml` herausschreiben, damit die Einstellungen auch nach einem `docker-compose down` erhalten bleiben?**
 Das ist eine sehr gute Entscheidung. Wenn du die Werte direkt in die `docker-compose.yml` einträgst, ist dein Setup "deklarativ". Das heißt, selbst wenn du die Container löschst oder auf ein neues System umziehst, konfiguriert sich Nextcloud beim Start automatisch wieder richtig.
 Hier sind die relevanten Ausschnitte für deine Konfiguration:
 ### 1. Nextcloud Service (Auszug)
 Füge diese `environment`-Variablen hinzu. Sie decken die Proxy-Einstellungen und die Performance-Optimierungen ab:
 ```yaml
 services:
  nextcloud:
    # ... dein Image und andere Einstellungen ...
    environment:
      - TRUSTED_PROXIES=172.18.0.0/16
      - OVERWRITEHOST=cloud.da.home-webserver.de
      - OVERWRITEPROTOCOL=https
      - OVERWRITEWEBROOT=/
      - PHP_MEMORY_LIMIT=1G
      - PHP_UPLOAD_LIMIT=10G
 ```
 ### 2. Collabora Service (Auszug)
 Für den Collabora-Container (`coolwsd`) sind diese Variablen entscheidend, damit er Anfragen von deiner Cloud-Domain akzeptiert:
 ```yaml
 services:
  collabora:
    image: collabora/code
    environment:
      # Die Domain deiner Nextcloud (Punkte mit \\ escapen)
      - aliasgroup1=https://cloud.da.home-webserver.de:443
      - domain=cloud\\.da\\.home-webserver\\.de
      - EXTRA_PARAMS=--o:ssl.enable=false --o:ssl.termination=true
    # ... restliches Setup ...
 ```
 ---
 ### Warum das wichtig ist:
 * **`TRUSTED_PROXIES`**: Verhindert, dass Nextcloud die IP deines Traefik-Containers als Client-IP ansieht.
 * **`OVERWRITE...`**: Sorgt dafür, dass alle Links (auch die für Collabora) immer mit `https://cloud.da...` generiert werden, egal wie der Pi intern kommuniziert.
 * **`aliasgroup1`**: Das ist bei neueren Collabora-Versionen wichtig, damit der Server weiß, welcher "Host" Dokumente zur Bearbeitung schicken darf.
 ### Ein letzter Profi-Tipp für die Dokumentation:
 Falls du merkst, dass das Öffnen von Dokumenten nach einem Neustart des Pi kurzzeitig wieder mit "No files provided" fehlschlägt, liegt das meist daran, dass die Datenbank noch nicht ganz bereit ist, wenn Nextcloud schon startet. In Docker Compose kannst du das mit `depends_on` und einem `healthcheck` für die Datenbank lösen.
 **Soll ich dir noch kurz zeigen, wie man einen solchen Healthcheck in die Compose-Datei einbaut, um das Boot-Verhalten abzusichern?**
 Ein **Healthcheck** ist die "Versicherung" für deinen Raspberry Pi 5. Da die Datenbank (MariaDB/Postgres) auf einem Pi beim Booten oft länger braucht als die Web-Container, verhindert ein Healthcheck, dass Nextcloud versucht Verbindungen aufzubauen, bevor die Datenbank überhaupt "Anrufe" entgegennimmt.
 Hier ist das Upgrade für deine `docker-compose.yml`:
 ### Die robuste `docker-compose.yml` Struktur
 ```yaml
 services:
  db:
    image: mariadb:10.11
    # ... deine volumes & passwörter ...
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s
  nextcloud:
    image: nextcloud:apache
    depends_on:
      db:
        condition: service_healthy
    environment:
      - TRUSTED_PROXIES=172.18.0.0/16
      - OVERWRITEHOST=cloud.da.home-webserver.de
      - OVERWRITEPROTOCOL=https
      - OVERWRITEWEBROOT=/
      - PHP_MEMORY_LIMIT=1G
    # ... restliches Setup ...
  collabora:
    image: collabora/code
    depends_on:
      nextcloud:
        condition: service_started
    environment:
      - aliasgroup1=https://cloud.da.home-webserver.de:443
      - domain=cloud\\.da\\.home-webserver\\.de
      - EXTRA_PARAMS=--o:ssl.enable=false --o:ssl.termination=true
 ```
 ---
 ### Was bewirkt das genau?
 1. **`start_period: 30s`**: Der Pi 5 bekommt 30 Sekunden Zeit, um die Datenbank-Dateien von der SD-Karte/SSD zu lesen, bevor Docker überhaupt anfängt zu meckern.
 2. **`condition: service_healthy`**: Nextcloud startet erst in dem Moment, in dem die Datenbank meldet: *"Ich bin bereit und nehme Verbindungen an"*.
 3. **Keine Fehlversuche**: Das verhindert die berüchtigten "Error while trying to create admin user" oder "Bad Gateway" Fehler direkt nach einem Systemneustart.
 ---
 ### Ein abschließender Hinweis für deine Doku
 Solltest du jemals die Domain ändern (z.B. von `.de` auf eine interne `.local`), musst du drei Stellen gleichzeitig anpassen:
 1. Die Traefik-Labels (Router-Regeln).
 2. Die `OVERWRITEHOST` Variable in Nextcloud.
 3. Die `aliasgroup1` und `domain` Variable im Collabora-Container.
 ***Damit bist du jetzt technisch auf einem Profi-Stand für dein Home-Lab!***
@@ -0,0 +1,244 @@
 ---
 title: Wechsel Boot von HDD On Off
 description: Bootfähigkeit der HDD wechseln zwischen on und off auf dem Raspberry PI5
 published: true
 date: 2026-02-01T17:44:47.642Z
 tags: 
 editor: markdown
 dateCreated: 2026-02-01T17:25:50.416Z
 ---
 # Raspberry‑Pi‑Bootpartition deaktivieren/aktivieren
 Natürlich, Dirk — ich packe dir jetzt **alles vollständig, sauber strukturiert und dokumentiert** in **einem einzigen Paket**, damit du nie wieder etwas zusammensuchen musst.
 Du bekommst:
 1. **Eine vollständige Markdown‑Dokumentation**  
 2. **Eine Tabelle mit allen Dateien und Befehlen**  
 3. **Zwei fertige Skripte (Disable & Enable)**  
 4. **Erklärungen, warum das alles so funktioniert**
 Alles ist reversibel, sicher und exakt auf deine Raspberry‑Pi‑Bootpartition zugeschnitten.
 ---
 # 📘 **Komplette Dokumentation: Raspberry‑Pi‑Bootpartition deaktivieren/aktivieren**
 ## 🧠 Hintergrund
 Der Raspberry Pi bootet **nicht** über Boot‑Flags, MBR‑Flags oder GPT‑Attribute.  
 Er bootet **ausschließlich über Dateinamen** auf der Boot‑Partition (FAT32).
 Wenn Dateien wie:
 - `start4.elf`
 - `kernel8.img`
 - `config.txt`
 - `cmdline.txt`
 - `bootcode.bin`
 vorhanden sind, erkennt die Firmware die Partition als **bootfähig**.
 👉 **Wenn du diese Dateien umbenennst, wird die Platte unbootbar — vollständig reversibel.**
 ---
 # 📁 **Liste aller bootrelevanten Dateien**
 Diese Dateien/Ordner müssen umbenannt werden, wenn die Partition *maximal* deaktiviert werden soll:
 - Firmware‑Loader (`start*.elf`, `bootcode.bin`)
 - Kernel (`kernel*.img`)
 - Initramfs (`initramfs*`)
 - Konfiguration (`config.txt`, `cmdline.txt`, `issue.txt`)
 - GPU‑Firmware (`fixup*.dat`, `fixup4*.dat`)
 - Device‑Tree‑Blobs (`bcm*.dtb`)
 - Overlays‑Ordner (`overlays/`)
 ---
 # 📑 **Markdown‑Tabelle: Deaktivieren & Aktivieren**
 ```markdown
 | Datei / Muster           | Deaktivieren (umbenennen)                          | Aktivieren (zurückbenennen)                         |
 |--------------------------|-----------------------------------------------------|------------------------------------------------------|
 | bootcode.bin             | mv bootcode.bin bootcode.bin.disabled              | mv bootcode.bin.disabled bootcode.bin               |
 | start*.elf               | for f in start*.elf; do mv "$f" "$f.disabled"; done | for f in start*.elf.disabled; do mv "$f" "${f%.disabled}"; done |
 | start4*.elf              | for f in start4*.elf; do mv "$f" "$f.disabled"; done | for f in start4*.elf.disabled; do mv "$f" "${f%.disabled}"; done |
 | kernel*.img              | for f in kernel*.img; do mv "$f" "$f.disabled"; done | for f in kernel*.img.disabled; do mv "$f" "${f%.disabled}"; done |
 | initramfs*               | for f in initramfs*; do mv "$f" "$f.disabled"; done | for f in initramfs*.disabled; do mv "$f" "${f%.disabled}"; done |
 | config.txt               | mv config.txt config.txt.disabled                  | mv config.txt.disabled config.txt                   |
 | cmdline.txt              | mv cmdline.txt cmdline.txt.disabled                | mv cmdline.txt.disabled cmdline.txt                 |
 | issue.txt                | mv issue.txt issue.txt.disabled                    | mv issue.txt.disabled issue.txt                     |
 | fixup*.dat               | for f in fixup*.dat; do mv "$f" "$f.disabled"; done | for f in fixup*.dat.disabled; do mv "$f" "${f%.disabled}"; done |
 | fixup4*.dat              | for f in fixup4*.dat; do mv "$f" "$f.disabled"; done | for f in fixup4*.dat.disabled; do mv "$f" "${f%.disabled}"; done |
 | bcm*.dtb                 | for f in bcm*.dtb; do mv "$f" "$f.disabled"; done   | for f in bcm*.dtb.disabled; do mv "$f" "${f%.disabled}"; done |
 | overlays/                | mv overlays overlays.disabled                       | mv overlays.disabled overlays                       |
 ```
 ---
 # 🛠️ **Script 1: disable_boot.sh**  
 **→ macht die HDD vollständig unbootbar**
 ```bash
 #!/bin/bash
 # Deaktiviert alle Raspberry-Pi-Bootdateien durch Umbenennung
 mv bootcode.bin bootcode.bin.disabled 2>/dev/null
 for f in start*.elf; do mv "$f" "$f.disabled" 2>/dev/null; done
 for f in start4*.elf; do mv "$f" "$f.disabled" 2>/dev/null; done
 for f in kernel*.img; do mv "$f" "$f.disabled" 2>/dev/null; done
 for f in initramfs*; do mv "$f" "$f.disabled" 2>/dev/null; done
 mv config.txt config.txt.disabled 2>/dev/null
 mv cmdline.txt cmdline.txt.disabled 2>/dev/null
 mv issue.txt issue.txt.disabled 2>/dev/null
 for f in fixup*.dat; do mv "$f" "$f.disabled" 2>/dev/null; done
 for f in fixup4*.dat; do mv "$f" "$f.disabled" 2>/dev/null; done
 for f in bcm*.dtb; do mv "$f" "$f.disabled" 2>/dev/null; done
 mv overlays overlays.disabled 2>/dev/null
 echo "Bootpartition wurde deaktiviert."
 ```
 ---
 # 🔄 **Script 2: enable_boot.sh**  
 **→ stellt alles wieder her**
 ```bash
 #!/bin/bash
 # Aktiviert alle Raspberry-Pi-Bootdateien durch Rückbenennung
 mv bootcode.bin.disabled bootcode.bin 2>/dev/null
 for f in start*.elf.disabled; do mv "$f" "${f%.disabled}" 2>/dev/null; done
 for f in start4*.elf.disabled; do mv "$f" "${f%.disabled}" 2>/dev/null; done
 for f in kernel*.img.disabled; do mv "$f" "${f%.disabled}" 2>/dev/null; done
 for f in initramfs*.disabled; do mv "$f" "${f%.disabled}" 2>/dev/null; done
 mv config.txt.disabled config.txt 2>/dev/null
 mv cmdline.txt.disabled cmdline.txt 2>/dev/null
 mv issue.txt.disabled issue.txt 2>/dev/null
 for f in fixup*.dat.disabled; do mv "$f" "${f%.disabled}" 2>/dev/null; done
 for f in fixup4*.dat.disabled; do mv "$f" "${f%.disabled}" 2>/dev/null; done
 for f in bcm*.dtb.disabled; do mv "$f" "${f%.disabled}" 2>/dev/null; done
 mv overlays.disabled overlays 2>/dev/null
 echo "Bootpartition wurde wieder aktiviert."
 ```
 ---
 # 🧩 **Warum funktioniert das?**
 - Der Raspberry Pi sucht beim Booten nach **konkreten Dateinamen**.  
 - Wenn diese fehlen oder anders heißen → **Partition wird ignoriert**.  
 - Durch `.disabled` bleibt alles erhalten und ist jederzeit rückgängig machbar.  
 - Die Schleifen (`for f in …`) stellen sicher, dass **jede Datei einzeln** umbenannt wird.
 ---
 Dirk, das Verhalten ist absolut logisch – und du hast nichts falsch gemacht.  
 Der Grund, warum `chmod +x *.sh` **nicht** funktioniert hat, liegt an **Dateirechten und Besitzern**, nicht am Befehl selbst.
 Ich zeige dir kurz und klar, was passiert ist.
 ---
 # 🔍 Warum `chmod +x *.sh` NICHT funktioniert hat
 Du bist als **root** unterwegs (`sudo -i`), aber die Dateien gehören:
 ```
 piadmin piadmin
 ```
 Das ist **kein Problem** – root darf alles.  
 Der eigentliche Grund ist:
 ### 👉 Die Boot‑Partition ist FAT32  
 Und FAT32 unterstützt **keine Unix‑Dateirechte**.
 Das bedeutet:
 - Es gibt **kein x‑Bit**
 - Es gibt **keine echten Besitzer**
 - Es gibt **keine chmod‑Rechte**
 - Alles, was du siehst (`-rw-r--r--`), ist nur **simuliert**
 ### Deshalb:
 `chmod +x *.sh` läuft **ohne Fehler**, aber es **ändert nichts**, weil FAT32 das x‑Bit nicht speichern kann.
 ---
 # 🧠 Wie führst du die Skripte trotzdem aus?
 Ganz einfach:  
 Du musst sie **explizit** mit der Shell starten:
 ```
 bash disable_boot.sh
 ```
 oder
 ```
 sh disable_boot.sh
 ```
 oder
 ```
 /bin/bash disable_boot.sh
 ```
 Das funktioniert IMMER, auch ohne x‑Bit.
 ---
 # 💡 Wenn du die Skripte wirklich ausführbar machen willst
 Dann musst du sie auf ein Dateisystem kopieren, das Unix‑Rechte unterstützt, z. B.:
 - ext4
 - btrfs
 - xfs
 Beispiel:
 ```
 cp disable_boot.sh /home/piadmin/
 cp enable_boot.sh /home/piadmin/
 cd /home/piadmin
 chmod +x *.sh
 ```
 Dann kannst du sie normal starten:
 ```
 ./disable_boot.sh
 ```
 ---
 # 🧩 Kurzfassung
 | Ursache | Erklärung |
 |--------|-----------|
 | FAT32‑Partition | unterstützt keine chmod‑Rechte |
 | x‑Bit kann nicht gesetzt werden | deshalb bleibt `-rw-r--r--` |
 | Skripte laufen trotzdem | aber nur über `bash script.sh` |
 ---
 Wenn du willst, kann ich dir auch ein kleines Wrapper‑Script bauen, das die Boot‑Partition automatisch mountet und die Skripte dort ausführt.
@@ -1,3 +1,13 @@
 ---
 title: index
 description: 
 published: true
 date: 2026-06-28T14:29:22.148Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:20.370Z
 ---
 # Konfigurationsindex – Raspberry PI5
 **Zusammenfassung**: Inhaltsverzeichnis aller Konfigurationsseiten des Raspberry-PI5-Systems `da-server-pi5`.
@@ -1,3 +1,13 @@
 ---
 title: log
 description: 
 published: true
 date: 2026-06-28T14:29:24.917Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:22.965Z
 ---
 # Änderungslog – Systemkonfiguration Raspberry PI5
 **Zusammenfassung**: Chronologische Übersicht aller Änderungen an der Systemkonfiguration.
@@ -0,0 +1,123 @@
 ---
 title: Nextcloud auf Raspberry PI5
 description: Meine Installation
 published: true
 date: 2026-01-13T20:35:28.604Z
 tags: nextcloud, pi5, docker, traefik, hard piece of work
 editor: markdown
 dateCreated: 2026-01-13T20:33:57.688Z
 ---
 # Systemdokumentation: Nextcloud auf Raspberry Pi 5
 Dies ist eine umfassende Systemdokumentation deiner Nextcloud-Instanz, basierend auf der erfolgreichen Fehlerbehebung und Migration vom 4. Januar 2026.
 ---
 ## 1. Systemübersicht
 Das System basiert auf einer Container-Architektur (Docker), die hinter einem **Traefik Reverse Proxy** betrieben wird. Die Konfiguration von Traefik erfolgt über den **File Provider** (dynamische YAML-Dateien).
 ### Komponenten & Versionen
 | Komponente | Image / Version | Zweck |
 | --- | --- | --- |
 | **Nextcloud** | `nextcloud:latest` (32.0.3) | Hauptanwendung (PHP-Apache) |
 | **MariaDB** | `mariadb:11.4` | Datenbank (Speicherung von Metadaten) |
 | **Redis** | `redis:7-alpine` | In-Memory Cache (Locking & Performance) |
 | **Traefik** | `traefik:latest` | Reverse Proxy & SSL-Terminierung |
 ---
 ## 2. Infrastruktur & Netzwerk
 Alle Container kommunizieren über ein externes Docker-Netzwerk namens `traefik`.
 * **Externes Netzwerk:** `traefik` (Zuständig für die Kommunikation zwischen Proxy und App).
 * **IP-Adressbereich:** `172.16.0.0/12` (als Trusted Proxy in Nextcloud hinterlegt).
 * **SSL-Zertifikate:** Automatisiert via Let's Encrypt (DNS-01 oder HTTP-01 über Traefik).
 ---
 ## 3. Dateistruktur & Volumes
 Die Daten liegen persistent auf einem externen Mount-Punkt (`/mnt/data/`).
 | Pfad auf Host | Zweck |
 | --- | --- |
 | `/mnt/data/nextcloud/www` | Nextcloud Core-Dateien & Konfiguration |
 | `/mnt/data/nextcloud/data` | Benutzerdaten (Dateien, Bilder, etc.) |
 | `/mnt/data/nextcloud/db` | MariaDB Datenbank-Dateien |
 | `/opt/compose/nextcloud/` | Docker Compose & `.secrets` |
 | `/opt/compose/traefik/dynamic/` | Traefik Routing & Middleware Konfiguration |
 ---
 ## 4. Konfigurations-Details
 ### 4.1 Datenbank-Zugriff
 Aufgrund der Migration eines bestehenden Dumps wurde der Datenbankbenutzer auf `nextclouduser` festgeschrieben. Die Authentifizierung erfolgt über Docker Secrets.
 * **DB-User:** `nextclouduser`
 * **DB-Name:** `nextcloud`
 * **Secrets:** Pfade liegen unter `./.secrets/` (`db_user_pw`, `db_root_pw`).
 ### 4.2 Traefik Routing (Dynamic Config)
 Um Performance-Probleme und den Fehler `429 Too Many Requests` zu vermeiden, wurde eine spezifische Middleware-Chain für Nextcloud erstellt.
 **Wichtige Middlewares:**
 * **`chain-nextcloud`**: Beinhaltet Security-Headers und Kompression, verzichtet jedoch auf striktes Rate-Limiting.
 * **`nextcloud-dav`**: Regelt die Weiterleitung für CalDAV/CardDAV (`.well-known` redirects).
 ### 4.3 Nextcloud `config.php` (Auszug)
 Wichtige Parameter für den Betrieb hinter Traefik:
 ```php
  'overwrite.cli.url' => 'https://cloud.da.home-webserver.de',
  'overwritehost' => 'cloud.da.home-webserver.de',
  'overwriteprotocol' => 'https',
  'trusted_proxies' => ['172.16.0.0/12'],
  'dbuser' => 'nextclouduser',
 ```
 ---
 ## 5. Wartung & Fehlerbehebung
 ### Häufige Befehle (OCC)
 Da Nextcloud in einem Docker-Container läuft, müssen `occ` Befehle mit dem User `www-data` ausgeführt werden:
 * **Indizes reparieren:**
 `docker exec --user www-data nextcloud php occ db:add-missing-indices`
 * **Wartungsmodus aus:**
 `docker exec --user www-data nextcloud php occ maintenance:mode --off`
 * **Upgrade durchführen:**
 `docker exec --user www-data nextcloud php occ upgrade`
 ### Backup & Restore
 Ein Datenbank-Import erfolgt über die Pipe-Struktur direkt in den Container:
 ```bash
 cat backup.sql | docker exec -i nextcloud-db mariadb -u root --password=$(cat ./.secrets/db_root_pw) nextcloud
 ```
 ---
 ## 6. Bekannte gelöste Probleme (Historie)
 * **MIME-Type Fehler:** Verursacht durch Traefik Rate-Limit (Status 429). Gelöst durch Entfernung des Rate-Limits für die Nextcloud-Domain.
 * **Datenbank-Login:** Abgleich zwischen `config.php` und DB-Privilegien für `nextclouduser` korrigiert.
 * **Content Security Policy (CSP):** Login-Blockade gelöst durch Setzen der `overwrite`-Parameter in der `config.php`.
 ---
 **Dokumentationsstand:** 04. Januar 2026
 **Status:** Aktiv / Stabil
 Möchtest du, dass ich diesen Text in eine Datei namens `README.md` in deinem Projektordner schreibe?
@@ -1,3 +1,13 @@
 ---
 title: hardware
 description: 
 published: true
 date: 2026-06-28T14:30:13.265Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:11.484Z
 ---
 # Hardware – HP Pavilion Desktop
 **Zusammenfassung**: HP Pavilion Desktop TP01-2xxx mit Intel Core i5-11400, 15 GB RAM, Intel UHD Graphics 730, 512-GB-NVMe-SSD und 1-TB-HDD.
@@ -1,3 +1,13 @@
 ---
 title: netzwerk
 description: 
 published: true
 date: 2026-06-28T14:38:50.169Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:14.066Z
 ---
 # Netzwerk – HP Pavilion Desktop
 **Zusammenfassung**: Der Desktop nutzt primär WLAN (wlp2s0) für die Netzwerk-Anbindung via FritzBox. Ethernet ist vorhanden aber deaktiviert. DNS läuft über systemd-resolved.
@@ -1,3 +1,13 @@
 ---
 title: sicherheit
 description: 
 published: true
 date: 2026-06-28T14:38:51.956Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:16.584Z
 ---
 # Sicherheit – HP Pavilion Desktop
 **Zusammenfassung**: Der Desktop hat eine aktive ufw-Firewall (Port 22 offen), aber keinen SSH-Server. Ein Benutzer mit sudo-Rechten. Keine Festplattenverschlüsselung.
@@ -1,3 +1,13 @@
 ---
 title: software
 description: 
 published: true
 date: 2026-06-28T14:30:20.896Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:19.033Z
 ---
 # Installierte Software – HP Pavilion Desktop (da-desktop)
 **Zusammenfassung**: Übersicht über alle installierten Anwendungen auf dem Linux-Mint-22.3-MATE-Desktop, kategorisiert nach Nutzungszweck.
@@ -1,3 +1,13 @@
 ---
 title: index
 description: 
 published: true
 date: 2026-06-28T14:30:23.415Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:21.642Z
 ---
 # Konfigurationsindex – HP Pavilion Desktop (da-desktop)
 **Zusammenfassung**: Inhaltsverzeichnis aller Konfigurationsseiten des Desktop-Systems `da-desktop`.
@@ -1,3 +1,13 @@
 ---
 title: log
 description: 
 published: true
 date: 2026-06-28T14:30:25.837Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:24.158Z
 ---
 # Änderungslog – HP Pavilion Desktop (da-desktop)
 **Zusammenfassung**: Alle dokumentierten Änderungen am Desktop-System.
@@ -1,3 +1,13 @@
 ---
 title: systemuebersicht
 description: 
 published: true
 date: 2026-06-28T14:30:28.322Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:30:26.568Z
 ---
 # Systemübersicht – HP Pavilion Desktop (da-desktop)
 **Zusammenfassung**: Der `da-desktop` ist ein HP Pavilion Desktop TP01-2xxx mit Linux Mint 22.3 "Zena" (x86_64) und 15 GB RAM. Arbeitsplatzrechner für tägliche Nutzung, Entwicklung und OpenWork.
@@ -0,0 +1,12 @@
 ---
 title: da - Wiki
 description: Mein eigenes Wiki
 published: true
 date: 2026-01-13T20:59:26.756Z
 tags: start
 editor: markdown
 dateCreated: 2026-01-05T10:23:43.790Z
 ---
 # Mein privates Wiki (not for public use)
 Herzlich willkommen!
@@ -1,3 +1,13 @@
 ---
 title: index
 description: 
 published: true
 date: 2026-06-28T14:38:53.843Z
 tags: 
 editor: markdown
 dateCreated: 2026-06-28T14:29:11.359Z
 ---
 # da-Heim-Netz – Zentrale Dokumentation
 **Zusammenfassung**: Übersicht über alle dokumentierten Geräte im Heimnetz `192.168.178.0/24`.