lscloud Inventur

Stand: read-only Inventur über SSH von root@lscloud

Überblick

lscloud ist ein aktiv genutzter Proxmox-Host auf Debian 13 (trixie) mit lokalem Reverse Proxy (Caddy), Tailscale, mehreren LXCs und einer Windows-VM. Es handelt sich nicht um einen Einzweckserver, sondern um einen produktiven Virtualisierungshost in einem Homelab-/Server-Setup.

Host-Basis

• Hostname: lscloud
• OS: Debian GNU/Linux 13 (trixie)
• Kernel: 6.17.2-1-pve
• Architektur: x86_64
• Hardware: Lenovo ThinkPad T14 Gen 3
• CPU: Intel Core i5-1235U
• RAM: 23 GiB
• Swap: 8 GiB
• Uptime zum Prüfzeitpunkt: ca. 13 Stunden

Einordnung

Der Host ist ein physischer Laptop, der als Proxmox-System eingesetzt wird. Das erklärt einige Hardware-spezifische Logeinträge (Audio/Firmware), die für den Virtualisierungsbetrieb nicht primär kritisch wirken.

Netzwerk

Wichtige Adressen

• LAN / Bridge: vmbr0 → 192.168.178.46/24
• Tailscale: 100.90.138.17
• Loopback: 127.0.0.1

Interfaces

• vmbr0 → primäre LAN-Bridge
• vmbr1 → weitere Bridge, teils mit WLAN-Verbindung / Sondernutzung
• tailscale0 → Tailnet-Anbindung
• diverse veth*, fwbr*, fwpr*, fwln*, tap200i0 → LXC-/VM-Netzwerkpfade

Default Route

• Gateway: 192.168.178.1

Offen lauschende Dienste / Ports

Direkt relevant

• 22/tcp → SSH
• 80/tcp → Caddy
• 443/tcp → Caddy
• 443/udp → Caddy / QUIC
• 8006/tcp → Proxmox Web UI
• 3128/tcp → SPICE Proxy
• 111/tcp+udp → rpcbind

Lokal / intern

• 127.0.0.1:25 → Postfix lokal
• 127.0.0.1:85 → pvedaemon lokal
• 127.0.0.1:2019 → Caddy admin lokal
• 127.0.0.1:61000 → KVM intern

Einordnung

Der Host exponiert Management- und Proxy-Dienste. Wichtigste Eintrittspunkte sind:

• SSH (22)
• Proxmox (8006)
• Caddy (80/443)
• Tailnet

Firewall / Sicherheitsrelevantes

Aktiv

• proxmox-firewall.service → aktiv
• pve-firewall.service → aktiv
• nftables.service → aktiviert

Gesehen

• PermitRootLogin yes in SSH-Konfiguration
• PasswordAuthentication wurde im ersten Grobcheck nicht explizit bestätigt oder verneint

Einordnung

Root-Login via SSH ist aktuell erlaubt. Das ist in Sergejs lokal kontrolliertem Setup bewusst möglich, sollte aber als operative Besonderheit dokumentiert bleiben.

Laufende Dienste

Wichtige aktive Services:

• caddy
• ssh
• tailscaled
• postfix
• proxmox-firewall
• pve-firewall
• pve-cluster
• pvedaemon
• pveproxy
• pvescheduler
• spiceproxy
• lxc-monitord
• lxcfs
• chrony
• rpcbind
• smartmontools
• rrdcached

Keine fehlgeschlagenen systemd-Units zum Prüfzeitpunkt.

DDNS / DNS / Tailnet

Tailscale

• tailscaled läuft aktiv auf dem Host
• Tailnet-IP vorhanden: 100.90.138.17

Aktuell sichtbare Tailnet-Geräte

• lscloud → aktiv
• iphone-15-pro → aktiv
• win11 → aktiv
• guacamole → offline
• cloud → offline
• weitere Geräte zeitweise offline

DDNS

In der schnellen Host-Inventur wurde kein separates klassisches DDNS-Skript gefunden. Das öffentliche Domain-Handling scheint primär über:

• Cloudflare DNS
• Caddy mit Cloudflare-DNS-Challenge

zu laufen.

DNS-relevante Beobachtung

• Caddy nutzt einen Cloudflare API Token aus einem systemd Override
• Domains unter *.ls-cloud.biz werden über Caddy terminiert

Einordnung

Die öffentliche Namens- und Zertifikatslogik läuft offenbar eher über Cloudflare + Caddy als über ein separates DDNS-Bastelskript.

Caddy / Reverse Proxy

Dienstzustand

• caddy.service ist aktiv und per systemd gestartet
• Binärpfad: /usr/local/bin/caddy
• Config: /etc/caddy/Caddyfile
• Admin API lokal auf:
  • 127.0.0.1:2019

Caddy-Umgebungsvariable

In override.conf ist ein Cloudflare API Token als Environment gesetzt.

Konfigurierte Domains / Reverse Proxies

Reale Erreichbarkeit vom Host

Backend-TCP-Checks

Caddy-Audit

Globale Konfiguration

caddy
{
    email Sergej.concept@gmail.com
}

• global nur ACME-Mail gesetzt
• keine globale Hardening-/Logging-/Admin-Änderung
• Admin-API bleibt lokal auf 127.0.0.1:2019, was grundsätzlich okay ist

TLS-Strategie

Alle öffentlichen Sites nutzen:

• tls { dns cloudflare {env.CF_API_TOKEN} }

Das ist konsistent und logisch für dein Setup.

Validierungsbefund

caddy validate zeigte:

• Caddyfile ist nicht formatiert
• die separate Validierung außerhalb von systemd scheitert auf dem Host an leerem Token, weil das Environment nur im Service-Kontext gesetzt ist
  • das ist erklärbar und kein direkter Produktionsfehler

Site-spezifische Logik

admin.ls-cloud.biz

• Reverse Proxy auf https://localhost:8006
• tls_insecure_skip_verify gesetzt
• sinnvoll, weil Proxmox lokal mit eigenem Zertifikat spricht
• keine zusätzlichen Header / keine Spielereien

live.ls-cloud.biz

• Reverse Proxy auf 192.168.178.54:8080
• zusätzlicher Redirect / → /guacamole
• sinnvoll wenn Guacamole lebt
• aktuell aber tot, weil Backend nicht erreichbar ist

files, stream, fotos, qbit, usenet, dl, net

• alle schlicht und sauber als Reverse Proxies
• keine unnötigen Sonderregeln
• technisch eher pragmatisch als elegant, aber lesbar und ausreichend klar

backup.ls-cloud.biz

• Reverse Proxy auf https://192.168.178.60:8007
• tls_insecure_skip_verify aktiv
• für PBS mit internem Zertifikat logisch

Wichtige Logbeobachtungen

2. live.ls-cloud.biz

   • wiederholt i/o timeout

3. fotos.ls-cloud.biz

   • zeitweise connection refused auf 192.168.178.62:2283
   • später auch unvollständige Responses / connection reset by peer
   • heißt: nicht nur die zwei bekannten Ziele sind auffällig, auch Immich hatte zumindest zeitweise Erreichbarkeitsprobleme

4. Caddy startet sauber, aber meldet:

   • fehlendes $HOME
   • Fallback auf ./caddy für manche interne Daten

Caddy-Gesamtbewertung

Positiv

• klarer Aufbau
• Cloudflare-DNS-Challenge konsistent
• lokale Admin-API
• Reverse-Proxy-Logik gut nachvollziehbar
• keine unnötig komplizierten Matcher-/Snippet-Monster

Unschön / mittel

• uneinheitliche Formatierung
• Validierung nur im Service-Kontext wirklich repräsentativ wegen Environment-Token
• kein erkennbar bewusstes zentrales Logging-/Policy-Konzept im Caddyfile selbst

Kritisch / operativ relevant

• mehrere Backends sind real instabil oder nicht erreichbar
• Caddy ist damit derzeit nicht der Hauptfehler, aber der Hauptsichtbarkeitsknoten für Störungen
• durch öffentliche Domains werden diese Ausfälle auch direkt von Bots/Scannern sichtbar erfasst

Einordnung

Die Caddy-Konfiguration ist grundsätzlich funktionsfähig und architektonisch passend für den Host. Die größten aktuellen Probleme liegen hinter Caddy, nicht in Caddy selbst.

Trotzdem ist Caddy betriebsstrategisch zentral, weil:

• fast die gesamte öffentliche Sichtbarkeit über ihn läuft
• er zuverlässig anzeigt, welche Backends real kaputt oder nicht erreichbar sind
• er damit der wichtigste Edge-Knoten des Hosts ist

Proxmox-Gäste

LXC-Container

CT 100 — guacamole

• Status: gestoppt
• OS: Ubuntu
• Cores: 2
• RAM: 1024 MB
• Rootfs: 8G
• Features: fuse=1,nesting=1
• Unprivileged: 0
• Netz: DHCP auf vmbr0
• Bemerkung: sehr wahrscheinlich Ziel von live.ls-cloud.biz, aktuell aber gestoppt und in Caddy-Logs als fehlerhaftes Backend sichtbar (192.168.178.54:8080).

CT 101 — jellyfin

• Status: running
• OS: Ubuntu 22.04
• IP: 192.168.178.55
• Cores: 2
• RAM: 2048 MB
• Rootfs: 16G
• Onboot: ja
• Features: nesting=1
• Unprivileged: 1
• Firewall an net0: ja
• Laufende Hauptdienste: jellyfin
• Offene Ports:
  • 8096/tcp (Jellyfin)
  • 7359/udp
  • 22/tcp
• Caddy-Zuordnung: stream.ls-cloud.biz → 192.168.178.55:8096

Tieferer Stand

• dedizierter Service-Container, kein Docker
• relevanter Medien-Mount:
  • /srv/media → Host-Storage (/dev/sda1)
• relevante Config-Pfade:
  • /etc/jellyfin
  • /etc/default/jellyfin
• zentrale Konfig-Dateien sichtbar:
  • system.xml
  • network.xml
  • encoding.xml
  • database.xml
  • logging.json
• lokaler Start über Standardpaket-/Servicepfad
• lokal vorhanden:
  • ufw.service aktiviert
  • nftables.service aktiviert

CT 102 — pbs

• Status: running
• OS: Debian 12
• IP: 192.168.178.60
• Cores: 1
• RAM: 1024 MB
• Rootfs: 50G
• Onboot: ja
• Features: nesting=1
• Laufende Hauptdienste: proxmox-backup, proxmox-backup-proxy
• Offene Ports:
  • 8007/tcp (PBS)
  • 22/tcp
• Caddy-Zuordnung: backup.ls-cloud.biz → https://192.168.178.60:8007

Tieferer Stand

• zusätzlicher Storage-Mount:
  • /mnt/datastore → Host-Storage (/dev/sda1)
• ZFS-nahe Services im Container aktiviert:
  • zfs-import-cache
  • zfs-mount
  • zfs-share
  • zfs-zed
• klare Rolle als dedizierter PBS-Container

CT 103 — fileserver

• Status: running
• OS: Debian 12
• IP: 192.168.178.61
• Cores: 2
• RAM: 2048 MB
• Rootfs: 8G
• Onboot: ja
• Features: nesting=1,keyctl=1
• Laufende Hauptdienste: filebrowser, watch-perms
• Offene Ports:
  • 8080/tcp (Filebrowser)
  • 22/tcp
• Caddy-Zuordnung: files.ls-cloud.biz → 192.168.178.61:8080

Tieferer Stand

• zusätzlicher Storage-Mount:
  • /srv/storage → Host-Storage (/dev/sda1)
• relevante Config-Pfade:
  • /etc/filebrowser
• systemd-Unit filebrowser.service ist lokal manuell unter /etc/systemd/system/ definiert
• Startbefehl:
  • /usr/local/bin/filebrowser
  • Root-Verzeichnis: /srv/storage
  • Datenbank: /var/lib/filebrowser/filebrowser.db
  • Bind auf 0.0.0.0:8080
• Auffälligkeit: In der Unit-Datei fehlt hinter --port 8080 sichtbar ein Zeilenfortsetzungs-Backslash vor --token-expiration-time 72h; wenn die laufende Unit funktioniert, sollte das später trotzdem bewusst geprüft werden
• zusätzlicher Spezialdienst:
  • watch-perms.service → startet /usr/local/bin/watch_perms.sh
  • deutet auf automatische Rechte-/Besitzkorrekturen hin

CT 104 — immich

• Status: running
• OS: Debian 12
• IP: 192.168.178.62
• Cores: 4
• RAM: 6144 MB
• Rootfs: 40G
• Onboot: ja
• Features: nesting=1,keyctl=1
• Laufende Hauptdienste: docker, containerd
• Offene Ports:
  • 2283/tcp (Immich via Docker)
  • 22/tcp
• Interne Netze zusätzlich sichtbar: 172.17.0.1, 172.18.0.1
• Caddy-Zuordnung: fotos.ls-cloud.biz → 192.168.178.62:2283

Docker-Stack CT 104

• Compose-Projekt: /opt/immich/docker-compose.yml
• Laufende Container:
  • immich_server
  • immich_postgres
  • immich_machine_learning
  • immich_redis
• Bind Mounts / Datenpfade:
  • /mnt/storage → /data (Immich-Daten)
  • /var/lib/immich-postgres → PostgreSQL-Daten
  • Docker Volume immich_model-cache → ML-Cache

Compose-/Konfig-Details

• Projektname: immich
• Versionen kommen aus .env (${IMMICH_VERSION} usw.)
• Server bindet Port 2283:2283
• Postgres nutzt Environment-Variablen:
  • DB_PASSWORD
  • DB_USERNAME
  • DB_DATABASE_NAME
• zusätzliche Projektdatei vorhanden:
  • /opt/immich/.env

Tieferer Stand

• zusätzlicher Host-Mount:
  • /mnt/storage → Host-Storage (/dev/sda1)
• relevante Config-Pfade:
  • /etc/docker
  • /etc/containerd/config.toml
  • /opt/immich/docker-compose.yml
  • /opt/immich/.env
• keine nativen App-Dienste außerhalb Docker sichtbar

CT 105 — downloads

• Status: running
• OS: Debian 12
• IP: 192.168.178.63
• Cores: 4
• RAM: 4096 MB
• Rootfs: 150G
• Onboot: ja
• Features: nesting=1,keyctl=1
• Laufende Hauptdienste: docker, containerd, prowlarr
• Offene Ports:
  • 8081/tcp (qBittorrent laut Caddy)
  • 8082/tcp (Usenet/SABnzbd laut Caddy)
  • 9696/tcp (Prowlarr)
  • 6881/tcp+udp (Torrent)
  • 22/tcp
• Interne Netze zusätzlich sichtbar: 172.17.0.1, 172.18.0.1
• Caddy-Zuordnung:
  • qbit.ls-cloud.biz → 192.168.178.63:8081
  • usenet.ls-cloud.biz → 192.168.178.63:8082
  • dl.ls-cloud.biz → 192.168.178.63:9696

Docker-Stack CT 105

• Compose-Projekt: /opt/downloads-stack/docker-compose.yml
• Laufende Container:
  • sabnzbd
  • qbittorrent
• Zusätzlich direkt auf dem Hostsystem des CT laufend:
  • Prowlarr
• Bind Mounts / Datenpfade:
  • /srv/storage/downloads/usenet → SABnzbd /downloads
  • /srv/downloads/incomplete/sabnzbd → SABnzbd /incomplete-downloads
  • /srv/downloads/watch → SABnzbd /watch
  • /opt/downloads-stack/sabnzbd-config → SABnzbd /config
  • /srv/storage/downloads/torrents → qBittorrent /downloads
  • /srv/downloads/incomplete/qbittorrent → qBittorrent /incomplete
  • /opt/downloads-stack/qbittorrent-config → qBittorrent /config

Compose-/Konfig-Details

• Projektname: downloads
• Sowohl qbittorrent als auch sabnzbd laufen mit:
  • PUID=0
  • PGID=0
  • also effektiv als root innerhalb des Containers
• qbittorrent veröffentlicht:
  • 8081
  • 6881/tcp
  • 6881/udp
• sabnzbd veröffentlicht:
  • 8082 → intern 8080
• Konfigdateien sichtbar:
  • /opt/downloads-stack/sabnzbd-config/sabnzbd.ini
  • /opt/downloads-stack/docker-compose.yml
• Prowlarr läuft separat per systemd:
  • Binary: /opt/Prowlarr/Prowlarr
  • Datenpfad: /var/lib/prowlarr
  • User/Group: prowlarr

Tieferer Stand

• zusätzliche Host-Mounts:
  • /srv/storage/downloads
  • /srv/storage/media
• relevante Config-/App-Pfade:
  • /opt/downloads-stack/docker-compose.yml
  • /opt/downloads-stack/qbittorrent-config
  • /opt/downloads-stack/sabnzbd-config
  • /opt/Prowlarr/Prowlarr.runtimeconfig.json
• Mischung aus Docker-Services und nativem Prowlarr-Service

CT 106 — openclaw

• Status: running
• OS: Ubuntu 22.04.5
• IP: 192.168.178.64
• Cores: 2
• RAM: 2048 MB
• Rootfs: 15G
• Onboot: ja
• Features: nesting=1
• Unprivileged: 1
• Firewall an net0: ja
• Laufende Hauptdienste: openclaw.service
• Offene Ports:
  • 18789/tcp
  • 18791/tcp
  • 18792/tcp
  • 22/tcp
• Einordnung: produktive OpenClaw-Instanz / Gateway-Host

Tieferer Stand

• kein zusätzlicher Host-Datenmount sichtbar
• relevanter systemd-Pfad:
  • /etc/systemd/system/openclaw.service
• lokal aktiviert:
  • openclaw.service
  • ufw.service
  • nftables.service
• Host wirkt relativ dediziert für OpenClaw

CT 107 — monitoring

• Status: running
• OS: Debian 12
• IP: 192.168.178.72
• zusätzliche IP: 192.168.178.73
• Cores: 2
• RAM: 1024 MB
• Rootfs: 8G
• Onboot: ja
• Laufende Hauptdienste: ntopng, ntop-license-manager, redis
• Offene Ports:
  • 3000/tcp
  • 4444/tcp
  • 7153/tcp
  • 6379/tcp lokal
  • 22/tcp
• Caddy-Zuordnung: net.ls-cloud.biz → 192.168.178.72:3000

Tieferer Stand

• relevante Config-Pfade:
  • /etc/ntopng/ntopng.conf
  • /etc/ntopng/ntopng.conf.d
  • /etc/rsyslog.d/20-ntopng.conf
• ntopng.conf enthält derzeit sichtbar:
  • -i=eth1
  • -w=3000
  • --community
• zusätzliche Besonderheit:
  • mirror-win11.service aktiviert
• Monitoring-Stack ist nativ, kein Docker sichtbar

Mirror-Windows-11-Logik

mirror-win11.service ist ein oneshot-Service, der per nft Traffic auf tap200i0 dupliziert:

• Quelle/Ziel VM-IP: 192.168.178.71
• gespiegelt nach: vmbr1

Das deutet stark darauf hin, dass der Monitoring-Container Verkehr der Windows-VM gezielt gespiegelt/mitgeschnitten bekommt.

CT 109 — claw

• Status: running
• OS: Ubuntu 24.04.4
• IP: 192.168.178.75
• Cores: 4
• RAM: 4096 MB
• Rootfs: 32G
• Features: nesting=1
• Unprivileged: 1
• Laufende Hauptdienste: OpenClaw-Gateway (lokal auf Loopback), fail2ban, SSH, Postfix
• Offene Ports:
  • 22/tcp
  • 127.0.0.1:18789
  • 127.0.0.1:18791
• Einordnung: weiterer OpenClaw-/KI-naher Host, offenbar die aktuell genutzte Laufumgebung

Tieferer Stand

• relevanter Benutzer:
  • openclaw (/home/openclaw)
• relevante Pfade:
  • /home/openclaw/.openclaw
  • /home/openclaw/.config
  • /home/openclaw/openclaw-gateway.log
  • /etc/sudoers.d/openclaw
• relevante Inhalte sichtbar:
  • OpenClaw-Workspace mit SOUL.md, AGENTS.md, USER.md, docs/, memory/
  • .ssh mit Keymaterial für den lokalen User
  • .openclaw/credentials inkl. Telegram-bezogener Dateien
  • Python-Venv perplexity-env
  • diverse Perplexity-/Debug-Skripte im Home
• zusätzliche Services aktiviert:
  • fail2ban
  • ufw
  • sysstat
  • viele systemd-/Ubuntu-Hardening-Komponenten
• aktueller Betriebszustand wirkt deutlich „arbeitsnah“ und eher gepflegt

VM

VM 200 — Windows11Pro

• Status: running
• OS: Windows 11
• Cores: 6
• RAM: 11400 MB
• Disk: 85G (scsi0 auf local-lvm)
• Onboot: ja
• Netz: virtio auf vmbr0, Firewall aktiv

Zugriffsmodell / Exposition

Öffentlich über Caddy (Port 80/443)

Diese Dienste sind öffentlich über ls-cloud.biz-Subdomains exponiert oder dafür vorgesehen:

• Proxmox UI (admin.ls-cloud.biz)
• Guacamole (live.ls-cloud.biz) — aktuell tot
• Fileserver/Filebrowser (files.ls-cloud.biz)
• PBS (backup.ls-cloud.biz)
• Jellyfin (stream.ls-cloud.biz)
• Immich (fotos.ls-cloud.biz)
• qBittorrent (qbit.ls-cloud.biz)
• SABnzbd / Usenet (usenet.ls-cloud.biz)
• Prowlarr (dl.ls-cloud.biz)
• ntopng (net.ls-cloud.biz)

Direkt auf dem Host exponiert

• 22/tcp → SSH auf allen Interfaces (0.0.0.0, ::)
• 8006/tcp → Proxmox Web UI auf allen Interfaces
• 3128/tcp → SPICE Proxy auf allen Interfaces
• 80/443 → Caddy auf allen Interfaces

Nur lokal auf dem Host

• 127.0.0.1:2019 → Caddy Admin API
• 127.0.0.1:25 → Postfix lokal
• 127.0.0.1:85 → pvedaemon lokal
• 127.0.0.1:61000 → KVM intern

Tailnet-Zugriff

• Host selbst im Tailnet (100.90.138.17)
• mehrere weitere Geräte vorhanden
• Tailnet dient offensichtlich als zusätzlicher Management-/Fernzugangspfad

Interne Service-Exposition in Containern

• mehrere Container bieten ihre App-Ports direkt im LAN an
• Caddy routet im Wesentlichen auf diese LAN-Ziele
• einige Container haben zusätzlich direkte SSH-Exposition auf Port 22

Einordnung

Das Modell ist aktuell:

• Host als zentrale Edge und Managementschicht
• Caddy als öffentlicher Eingang
• Container als interne Service-Endpunkte im LAN
• Tailnet als zusätzlicher Verwaltungs-/Fernzugangspfad

Storage

Verfügbare Speicher

• local → Dir Storage auf Host
• local-lvm → aktiver Thin-LVM Storage
• hdd5tb → Directory-Storage auf /mnt/storage
• pbs-backups → PBS-Storage aktiv

Auslastung

• hdd5tb → ca. 22.86%
• local → ca. 17.92%
• local-lvm → ca. 30.09%
• pbs-backups → ca. 22.86%

Host-Dateisysteme

• Root (/) auf pve-root ext4, ~19% genutzt
• /mnt/storage auf sda1, ~25% genutzt
• /boot/efi klein und unkritisch belegt

Container-/VM-Disk-Zuordnung

Alle LXCs liegen mit ihrem Rootfs auf local-lvm.

• CT 100 → vm-100-disk-0 (8G)
• CT 101 → vm-101-disk-0 (16G)
• CT 102 → vm-102-disk-0 (50G)
• CT 103 → vm-103-disk-0 (8G)
• CT 104 → vm-104-disk-0 (40G)
• CT 105 → vm-105-disk-0 (150G)
• CT 106 → vm-106-disk-0 (15G)
• CT 107 → vm-107-disk-0 (8G)
• CT 109 → vm-109-disk-0 (32G)

VM 200:

• scsi0 → local-lvm:vm-200-disk-0 (85G)

Host-Storage-Mounts in Containern

ZFS

• zpool status zeigte keinen aktiven ZFS-Pool
• dennoch sind ZFS-Pakete und update-relevante ZFS-Komponenten vorhanden

Ressourcen / Last

RAM

• Gesamt: 23 GiB
• genutzt: 17 GiB
• verfügbar: 6.1 GiB
• Swap-Nutzung: gering

CPU

• 12 logische CPUs
• keine offensichtliche Lastspitze im Prüfzeitpunkt
• Load Average moderat

Einordnung

Der Host ist belastet, aber nicht am Anschlag. Für einen Proxmox-Homelab-Host mit mehreren Gästen ist der Zustand aktuell unauffällig.

Auffällige Pakete / Softwarelandschaft

Sichtbar und relevant:

• Proxmox VE Stack
• Caddy
• Tailscale
• Postfix
• Python 3.13
• OpenSSH
• Ceph-/Storage-nahe Komponenten

Nicht als aktiv genutzt sichtbar:

• Docker auf dem Host
• Podman auf dem Host
• Nginx/Apache als Host-Webserver
• MySQL/PostgreSQL als Host-DB

Einordnung

Der Host wirkt rollenrein genug: Virtualisierung, Reverse Proxy, Management. Anwendungsdienste scheinen überwiegend in Gästen zu laufen.

Verknüpfungsmatrix

Domain → Backend → Gast → Dienst

Gast → weitere interne Abhängigkeiten

• CT 101 jellyfin
  • hängt an Host-Medienmount /srv/media
• CT 102 pbs
  • hängt an Host-Datastore-Mount /mnt/datastore
• CT 103 fileserver
  • hängt an Host-Storage-Mount /srv/storage
  • besitzt automatisches Rechte-Korrektur-Skript für Mediapfade
• CT 104 immich
  • Docker-Compose-Stack
  • immich_server ↔ immich_postgres ↔ immich_redis ↔ immich_machine_learning
  • Host-Storage-Bind auf /mnt/storage
  • Konfiguration teilweise in .env
• CT 105 downloads
  • Docker-Compose-Stack für qbittorrent und sabnzbd
  • zusätzlicher nativer Dienst Prowlarr
  • Bind Mounts auf /srv/storage/downloads/*, /srv/downloads/*, /opt/downloads-stack/*
  • Docker-Apps laufen mit PUID=0/PGID=0
• CT 107 monitoring
  • überwacht primär den Traffic der Windows-11-VM
  • ntopng hängt lokal an redis
  • mirror-win11.service spiegelt den VM-Traffic gezielt auf vmbr1
• CT 108 wiki
  • OtterWiki läuft per Docker
  • aktiver Datenpfad: /opt/otterwiki/runtime-data
• CT 110 dns
  • Pi-hole-DNS auf Port 53
  • Admin-Oberfläche über dns.ls-cloud.biz
  • Webzugriff aktuell faktisch über Pi-hole/FTL auf Port 80
• CT 106 / CT 109
  • OpenClaw-bezogene Umgebungen, aber mit unterschiedlichem Betriebsbild
• Host
  • Caddy ist zentraler Einstiegspunkt für nahezu alle externen Webdienste

Mount-Übersicht

Host-seitige relevante Mounts

LXC-Bind-Mounts laut Konfiguration

Operative Einordnung

• Die zentrale Zusatz-Storage hängt aktuell an /mnt/storage auf dem Host.
• Mehrere produktive Container referenzieren darin Pfade unter /mnt/storage/fileserver/....
• Der Vorfall mit Jellyfin zeigte, dass genau diese Storage-/Bind-Beziehungen kritisch sind und bei Aussetzern sehr schnell zu Input/output error in den Containern führen können.
• Wenn Medien, Uploads oder Dateizugriffe plötzlich ausfallen, sollte künftig immer früh geprüft werden:
  1. ist /mnt/storage auf dem Host sauber vorhanden?
  2. existieren die referenzierten Unterpfade wirklich?
  3. liefern die Container-Bind-Mounts dort normale Lesezugriffe oder bereits I/O-Fehler?

Wartungs- und Risikobild

Besonders kritische Komponenten

1. Host selbst (lscloud)

Wenn der Host ausfällt oder ungeplant neu startet, betrifft das gleichzeitig:

• Proxmox-Management
• Caddy / öffentliche Domains
• alle LXCs
• die Windows-VM
• Tailscale-Zugang

2. Host-Storage /dev/sda1 / /mnt/storage

Davon hängen mehrere produktive Dienste ab:

• Jellyfin
• PBS-Datastore
• Fileserver
• Immich
• Downloads

Das ist ein zentraler Datenanker und damit klar ein Single Point of Storage Failure.

3. Caddy

Caddy ist der zentrale Edge-Knoten:

• Zertifikate
• öffentliche Domains
• Reverse Proxy
• Sichtbarkeit aller Backend-Probleme

4. CT 109 claw

Operativ sensibel, weil dort liegt:

• OpenClaw-Workspace
• Credentials
• SSH-Material
• Telegram-bezogene Daten
• laufende Agenten-/Gateway-Umgebung

5. CT 102 pbs

Backup-Systeme sind nicht glamourös, aber wenn sie kaputt sind, merkt man es üblicherweise im schlechtesten Moment.

Mittlere Risiken

• handgebaute systemd-Units in Containern (filebrowser, watch-perms, prowlarr, mirror-win11)
• Docker-Stacks mit Root-Kontext in CT 105
• nicht sauber erreichbare externe Ziele in Caddy

Geringere, aber dokumentationswürdige Themen

• Caddyfile-Formatierung / Redundanzen
• $HOME-Warnung bei Caddy
• Root-SSH bewusst aktiv
• Postfix / rpcbind auf dem Host

Update-/Neustart-Sensibilität

Besonders vorsichtig behandeln bei späteren Wartungsfenstern:

• Host-Updates mit Kernel-/Proxmox-Komponenten
• alles, was /mnt/storage betrifft
• Caddy / Cloudflare / Zertifikatslogik
• CT 102 PBS
• CT 109 claw
• CT 104/105 wegen Docker-Stacks und Medien-/Downloadpfaden

Log-/Fehlerhinweise

Relevante Beobachtungen

• Caddy meldet Backend-Ausfälle / Timeouts
• lokaler Auth-Fehler root@pam gegen Proxmox vorhanden
• Hardware-/Firmware-Rauschen bei Audio / SPI / NFS-Blockmap

Vorläufige Einordnung

• keine akute Systeminstabilität sichtbar
• aber Netzwerk-/Erreichbarkeitsprobleme zu einzelnen Backends sind real

Vorläufiges Fazit

lscloud ist ein produktiver und grundsätzlich stabiler Proxmox-Host mit:

• sauberer Grundstruktur
• funktionierendem Reverse Proxy
• mehreren aktiv genutzten LXCs/VMs
• Tailnet-Integration
• PBS-Backup-Anbindung

Aber auch mit klaren Themen für spätere Nacharbeit:

1. Host wurde bereits aktualisiert; spätere Wartung bleibt dennoch generell relevant
2. SSH Root-Login aktiv
3. Caddy-Backends teils unzuverlässig erreichbar
4. einige Dienste/Ports offen, die bewusst bewertet werden sollten
5. Postfix und rpcbind laufen — Bedarf später gezielt prüfen
6. live.ls-cloud.biz verweist sehr wahrscheinlich auf den aktuell gestoppten Guacamole-Container
7. Immich und Downloads basieren stark auf Docker-Stacks innerhalb ihrer Container
8. wichtige Datenpfade liegen mehrfach auf dem gleichen großen Host-Storage (/dev/sda1)
9. mehrere produktive Dienste hängen an individuellen, teils handgebauten systemd-Units innerhalb der Container
10. Caddy ist architektonisch der wichtigste öffentliche Knoten und sollte bei späteren Änderungen immer früh mitgedacht werden

Sinnvolle nächste Analyseblöcke

1. Sensible Dienste gesondert dokumentieren
   • CT 109 (claw)
   • CT 106 (openclaw)
   • CT 102 (pbs)
2. Tote Backends gezielt klären
   • 192.168.178.54

Nachtrag: CT 110 dns / Pi-hole

Rolle

CT 110 stellt einen dedizierten Pi-hole-DNS-/Adblock-Container bereit.

Basisdaten

• CT-ID: 110
• Hostname: dns
• IP: 192.168.178.78
• Netzkonzept: statische Adresse im Container, vom Nutzer per Router dauerhaft zugewiesen
• Öffentliche Admin-URL: https://dns.ls-cloud.biz/admin/
• Lokale Admin-URL: http://192.168.178.78/admin/

Technischer Zustand

• Debian-basierter LXC auf lscloud
• Pi-hole-Dienst über pihole-FTL
• Weboberfläche aktuell auf Port 80 funktionsfähig, faktisch über Pi-hole/FTL erreichbar
• DNS-Port 53 aktiv (TCP/UDP)
• Caddy leitet dns.ls-cloud.biz auf 192.168.178.78:80

Besonderheiten bei der Einrichtung

Die erste automatische Pi-hole-Installation scheiterte wiederholt am Installer-Check Static IP Needed, obwohl die Container-Netzkonfiguration bereits statisch gesetzt war.

Daraufhin wurde die Einrichtung pragmatisch vervollständigt:

• Resolver im Container vorübergehend auf öffentliche Resolver gesetzt, damit die Installation externe Quellen erreicht
• Pi-hole-Komponenten außerhalb des blockierenden Wizard-Pfads fertig eingerichtet
• gravity.db anschließend sauber neu aufgebaut
• Caddy-Eintrag für dns.ls-cloud.biz aktiviert und Zertifikat erfolgreich via DNS-01/Cloudflare bezogen

Validierter Betriebszustand

• pihole-FTL läuft
• lighttpd ist derzeit nicht der maßgebliche funktionierende Webpfad
• gravity.db ist vorhanden und enthält die erwarteten Tabellen
• https://dns.ls-cloud.biz/admin/ antwortet mit HTTP/2 200

Hinweis

Wenn Pi-hole in Zukunft neu aufgesetzt oder reproduzierbar automatisiert werden soll, sollte der Installer-Pfad für statische IP-Prüfung in diesem LXC-Kontext gesondert dokumentiert oder bewusst umgangen werden. Der offizielle Wizard verhielt sich hier unzuverlässig.