Kapitel 12/Free Rohtext.md hinzugefügt
This commit is contained in:
839
Kapitel 12/Free Rohtext.md
Normal file
839
Kapitel 12/Free Rohtext.md
Normal file
@@ -0,0 +1,839 @@
|
||||
# Kapitel 12 – Asset-LXC
|
||||
|
||||
## Einleitung
|
||||
|
||||
Der **Asset-LXC** ist ein zentraler Bestandteil des **UCC** und dient als dauerhafte Ablage für statische Dateien, die von verschiedenen Diensten gemeinsam genutzt werden.
|
||||
Er ermöglicht die klare Trennung zwischen produktiven Anwendungen und den zugrunde liegenden Mediendateien, wodurch Systeme wie OBS, n8n, Nextcloud oder Webseiten effizienter und stabiler arbeiten können.
|
||||
|
||||
Im Gegensatz zu Nextcloud, das für Zusammenarbeit, Synchronisation und Benutzerfreigaben gedacht ist, konzentriert sich der Asset-LXC ausschließlich auf die **Bereitstellung und Verwaltung von Dateien**.
|
||||
Er ist schlank, schnell und lokal vollständig unter deiner Kontrolle – unabhängig von externen Anbietern oder Cloud-Diensten.
|
||||
|
||||
Kern des Systems ist **Filebrowser**, eine leichtgewichtige Weboberfläche, über die du Dateien direkt im Browser hochladen, umbenennen, verschieben oder löschen kannst.
|
||||
Damit steht ein eigenständiger Medien-Manager zur Verfügung, der einfach zu bedienen ist, keine aufwendige Datenbank benötigt und sich nahtlos in die bestehende UCC-Struktur einfügt.
|
||||
|
||||
> [!NOTE]
|
||||
> Filebrowser wird vollständig eingerichtet und ist nach Abschluss der Konfiguration direkt einsatzbereit.
|
||||
> Erweiterungen wie Netzlaufwerks-Einbindung unter Windows oder zusätzliche Automatisierungen bauen später auf diesem System auf, nutzen aber dieselbe Basis.
|
||||
|
||||
Ziel dieses Kapitels ist der Aufbau eines stabilen und sicheren Containers, der alle statischen Inhalte zentral verwaltet, klar strukturiert und langfristig als feste Infrastruktur-Komponente im UCC bestehen bleibt.
|
||||
|
||||
---
|
||||
|
||||
## Voraussetzungen & Ressourcen
|
||||
|
||||
Bevor du mit der Einrichtung des Asset-LXC beginnst, überprüfe, ob dein System vollständig vorbereitet ist.
|
||||
Die folgenden Punkte legen fest, welche Ressourcen und Bedingungen zwingend erfüllt sein müssen, damit der Container fehlerfrei betrieben werden kann.
|
||||
|
||||
### Container-Ressourcen
|
||||
|
||||
* **CPU: 2 vCPUs**
|
||||
Zwei virtuelle Kerne sind die empfohlene Mindestgröße.
|
||||
Filebrowser und Nginx profitieren von getrennten Threads für Uploads und gleichzeitige Webzugriffe.
|
||||
|
||||
* **RAM: 2 GB**
|
||||
Diese Menge stellt sicher, dass Uploads, Dateiverwaltung und Nginx-Dienste stabil laufen.
|
||||
Bei geringeren Werten kann es unter Last zu Verzögerungen kommen.
|
||||
|
||||
* **Speicherplatz: 20 GB**
|
||||
Reicht für System, Logdateien, temporäre Uploads und kleinere Medienbestände.
|
||||
Wenn du größere Mengen an Medien ablegen willst, sollte der Speicher direkt beim Erstellen des Containers erweitert oder ein zusätzliches Volume eingebunden werden.
|
||||
|
||||
* **Betriebssystem: Debian 12 (Bookworm)**
|
||||
Debian ist für den Asset-LXC optimal geeignet.
|
||||
Es ist stabil, ressourcenschonend und erfordert keine zusätzliche Konfiguration für Nginx oder Filebrowser.
|
||||
Alle Befehle und Pfade in diesem Kapitel beziehen sich auf Debian 12.
|
||||
|
||||
* **Netzwerk: statische IP-Adresse oder DHCP-Reservierung**
|
||||
Der Container muss dauerhaft unter derselben Adresse erreichbar sein,
|
||||
da die spätere Proxy-Einbindung über eine feste Ziel-IP erfolgt.
|
||||
|
||||
> [!TIP]
|
||||
> Weise die IP-Adresse direkt bei der Containereinrichtung zu.
|
||||
> Eine nachträgliche Änderung würde sämtliche Proxy- und DNS-Einträge betreffen.
|
||||
|
||||
### Technische Voraussetzungen
|
||||
|
||||
* **Proxmox VE ist installiert und funktionsfähig.**
|
||||
Der Container wird direkt über die Proxmox-Oberfläche erstellt und verwaltet.
|
||||
|
||||
* **Nginx Proxy Manager (NPM) ist eingerichtet.**
|
||||
Er wird benötigt, um die Weboberfläche von Filebrowser über HTTPS bereitzustellen.
|
||||
|
||||
* **DNS- oder DynDNS-Eintrag ist vorhanden.**
|
||||
Eine Subdomain wie `assets.deinedomain.tld` ist vorbereitet und im DNS eingetragen.
|
||||
|
||||
* **SSH-Zugriff auf den Container ist möglich.**
|
||||
Entweder über die Proxmox-Konsole oder per Terminal (z. B. `ssh root@10.0.0.12`).
|
||||
|
||||
* **Grundstruktur des UCC ist aktiv.**
|
||||
Proxmox, Nginx Proxy Manager und Netzwerkverbindungen laufen stabil,
|
||||
damit der Container nach Fertigstellung sofort in das System eingebunden werden kann.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Der Asset-LXC ist ein eigenständiger, dauerhaft aktiver Dienst.
|
||||
> Stelle sicher, dass er auf einem Host mit stabiler Netzwerkverbindung liegt und nicht mit anderen produktiven Containern gemeinsam auf einem kritischen Volume betrieben wird.
|
||||
|
||||
---
|
||||
|
||||
## Schritt-für-Schritt-Anleitung
|
||||
|
||||
In diesem Abschnitt richtest du den Asset-LXC vollständig ein.
|
||||
Alle Befehle sind direkt übernehmbar und so gewählt, dass sie ohne Anpassung ausgeführt werden können.
|
||||
Am Ende dieses Abschnitts steht ein voll funktionsfähiger Container mit Nginx und Filebrowser, erreichbar über HTTPS.
|
||||
|
||||
### Schritt 1 – System aktualisieren
|
||||
|
||||
Starte den Container über die Proxmox-Oberfläche und öffne anschließend die Konsole oder verbinde dich per SSH.
|
||||
Bringe das System auf den aktuellen Stand:
|
||||
|
||||
```bash
|
||||
apt update && apt upgrade -y
|
||||
reboot
|
||||
```
|
||||
|
||||
Nach dem Neustart erneut einloggen.
|
||||
|
||||
> [!NOTE]
|
||||
> Auch bei frisch erstellten Containern ist ein Systemupdate erforderlich.
|
||||
> Veraltete Paketquellen führen später zu Problemen bei der Installation von Nginx oder Filebrowser.
|
||||
|
||||
### Schritt 2 – Grundverzeichnisse anlegen
|
||||
|
||||
Lege die Verzeichnisstruktur an, in der später alle Medien abgelegt werden.
|
||||
Diese Struktur wird sowohl vom Webserver als auch von Filebrowser genutzt:
|
||||
|
||||
```bash
|
||||
mkdir -p /srv/assets/{overlays,videos,sounds,projects,_meta}
|
||||
```
|
||||
|
||||
Anschließend die Besitzerrechte für das System korrekt setzen:
|
||||
|
||||
```bash
|
||||
chown -R www-data:www-data /srv/assets
|
||||
chmod -R 755 /srv/assets
|
||||
```
|
||||
|
||||
> [!TIP]
|
||||
> Lege die Verzeichnisstruktur zu Beginn konsequent an.
|
||||
> Einheitliche Pfade erleichtern dir später den Umgang mit Nginx, SMB und automatisierten Backups.
|
||||
|
||||
### Schritt 3 – Nginx installieren
|
||||
|
||||
Installiere Nginx als Webserver.
|
||||
Er wird benötigt, um die Dateien aus `/srv/assets` später per HTTPS auszuliefern.
|
||||
|
||||
```bash
|
||||
apt install nginx -y
|
||||
```
|
||||
|
||||
Nach Abschluss der Installation den Dienst prüfen:
|
||||
|
||||
```bash
|
||||
systemctl status nginx
|
||||
```
|
||||
|
||||
Wenn der Status **active (running)** angezeigt wird, läuft Nginx korrekt.
|
||||
|
||||
> [!NOTE]
|
||||
> Nginx dient in diesem Container ausschließlich der Dateiauslieferung und wird später über den Proxy Manager abgesichert.
|
||||
> Er übernimmt keine komplexen Webdienste.
|
||||
|
||||
### Schritt 4 – Filebrowser installieren
|
||||
|
||||
Filebrowser wird direkt aus dem offiziellen Repository installiert.
|
||||
Er benötigt keine zusätzlichen Abhängigkeiten und läuft als eigenständiger Dienst innerhalb des Containers.
|
||||
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/filebrowser/get/master/get.sh | bash
|
||||
```
|
||||
|
||||
Nach erfolgreicher Installation kann der Dienst mit folgendem Befehl gestartet werden:
|
||||
|
||||
```bash
|
||||
filebrowser -r /srv/assets -p 8080 &
|
||||
```
|
||||
|
||||
Damit wird Filebrowser gestartet, nutzt `/srv/assets` als Arbeitsverzeichnis und ist über Port `8080` erreichbar.
|
||||
|
||||
> [!NOTE]
|
||||
> Der Befehl startet Filebrowser im Vordergrund.
|
||||
> Im nächsten Schritt wird er als dauerhafter Systemdienst eingerichtet, damit er automatisch startet.
|
||||
|
||||
### Schritt 5 – Filebrowser als Dienst einrichten
|
||||
|
||||
Damit Filebrowser nach einem Neustart automatisch gestartet wird, muss ein Systemdienst erstellt werden.
|
||||
|
||||
```bash
|
||||
nano /etc/systemd/system/filebrowser.service
|
||||
```
|
||||
|
||||
Füge den folgenden Inhalt ein:
|
||||
|
||||
```
|
||||
[Unit]
|
||||
Description=Filebrowser Service
|
||||
After=network.target
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
ExecStart=/usr/local/bin/filebrowser -r /srv/assets -p 8080
|
||||
Restart=on-failure
|
||||
User=root
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
Datei speichern (**Strg + O**, **Enter**, **Strg + X**) und den Dienst aktivieren:
|
||||
|
||||
```bash
|
||||
systemctl daemon-reload
|
||||
systemctl enable filebrowser
|
||||
systemctl start filebrowser
|
||||
```
|
||||
|
||||
Den Status prüfen:
|
||||
|
||||
```bash
|
||||
systemctl status filebrowser
|
||||
```
|
||||
|
||||
Wenn dort **active (running)** angezeigt wird, ist der Dienst aktiv und funktionsfähig.
|
||||
|
||||
> [!TIP]
|
||||
> Filebrowser läuft jetzt dauerhaft im Hintergrund und startet automatisch bei jedem Container-Neustart.
|
||||
> Alle Benutzer- und Dateiänderungen bleiben erhalten.
|
||||
|
||||
### Schritt 6 – Zugriff im Browser testen
|
||||
|
||||
Öffne einen Browser und rufe die IP-Adresse des Containers mit Port `8080` auf, z. B.:
|
||||
|
||||
```
|
||||
http://10.0.0.12:8080
|
||||
```
|
||||
|
||||
Wenn alles korrekt eingerichtet wurde, erscheint die Anmeldeseite von **Filebrowser**.
|
||||
Standardmäßig ist der Benutzername **admin** und das Passwort **admin**.
|
||||
|
||||
Melde dich an und ändere das Passwort unmittelbar nach dem ersten Login:
|
||||
|
||||
1. Oben rechts auf **Benutzername → Einstellungen** klicken.
|
||||
2. Neues Passwort setzen und speichern.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Das Standardpasswort ist öffentlich bekannt.
|
||||
> Ändere es sofort nach dem ersten Login, bevor der Container über den Proxy Manager nach außen erreichbar ist.
|
||||
|
||||
Nach dem Login siehst du die Verzeichnisse, die du in `/srv/assets` angelegt hast.
|
||||
Filebrowser zeigt sie automatisch an und ermöglicht dir den Upload, das Verschieben und Löschen von Dateien direkt im Browser.
|
||||
|
||||
> [!TIP]
|
||||
> Über das Zahnrad-Symbol oben rechts kannst du neue Benutzer anlegen.
|
||||
> Lege mindestens einen zusätzlichen Benutzer mit eingeschränkten Rechten an, wenn du den Zugriff an andere weitergeben möchtest.
|
||||
|
||||
### Schritt 7 – Nginx für Dateiauslieferung konfigurieren
|
||||
|
||||
Neben der Verwaltungsoberfläche soll der Container die Inhalte auch öffentlich bereitstellen können.
|
||||
Dazu wird Nginx so konfiguriert, dass er die Dateien aus `/srv/assets` als statische Inhalte ausliefert.
|
||||
|
||||
Öffne die Konfigurationsdatei:
|
||||
|
||||
```bash
|
||||
nano /etc/nginx/sites-available/assets.conf
|
||||
```
|
||||
|
||||
Füge folgenden Inhalt ein:
|
||||
|
||||
```
|
||||
server {
|
||||
listen 80;
|
||||
server_name assets.local;
|
||||
|
||||
root /srv/assets;
|
||||
index index.html;
|
||||
|
||||
location / {
|
||||
autoindex on;
|
||||
autoindex_exact_size off;
|
||||
autoindex_localtime on;
|
||||
}
|
||||
|
||||
location ~ /\. {
|
||||
deny all;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Datei speichern (**Strg + O**, **Enter**, **Strg + X**) und aktivieren:
|
||||
|
||||
```bash
|
||||
ln -s /etc/nginx/sites-available/assets.conf /etc/nginx/sites-enabled/
|
||||
nginx -t
|
||||
systemctl restart nginx
|
||||
```
|
||||
|
||||
Wenn der Test (`nginx -t`) mit „syntax is ok“ und „test is successful“ endet, ist die Konfiguration gültig.
|
||||
|
||||
Nun kannst du prüfen, ob Nginx die Dateien korrekt ausliefert:
|
||||
|
||||
```
|
||||
http://10.0.0.12/
|
||||
```
|
||||
|
||||
Im Browser sollte jetzt ein automatisches Verzeichnislisting mit deinen Medien erscheinen.
|
||||
Bilder und Videos lassen sich direkt öffnen oder herunterladen.
|
||||
|
||||
> [!NOTE]
|
||||
> Dieses lokale Verzeichnislisting wird später über den Nginx Proxy Manager abgesichert und mit HTTPS versehen.
|
||||
> Innerhalb des Netzwerks kannst du es jedoch schon jetzt nutzen, um schnell auf die Dateien zuzugreifen.
|
||||
|
||||
### Schritt 8 – Einbindung in Nginx Proxy Manager (NPM)
|
||||
|
||||
Nachdem der Container intern erfolgreich getestet wurde, kann er jetzt über den **Nginx Proxy Manager** erreichbar gemacht werden.
|
||||
Damit erhält Filebrowser eine eigene Subdomain mit HTTPS-Zertifikat und ist über eine feste Adresse erreichbar.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Führe diesen Schritt erst durch, wenn du Filebrowser bereits per IP und Port getestet hast.
|
||||
> Nur so kannst du sicherstellen, dass eventuelle Fehler eindeutig auf den Proxy und nicht auf den Container zurückzuführen sind.
|
||||
|
||||
#### 1. Proxy-Host für Filebrowser anlegen
|
||||
|
||||
1. Öffne das Dashboard des **Nginx Proxy Manager**.
|
||||
2. Klicke auf **Add Proxy Host**.
|
||||
3. Trage folgende Werte ein:
|
||||
|
||||
| Feld | Wert |
|
||||
|------|------|
|
||||
| **Domain Names** | `assets-admin.deinedomain.tld` |
|
||||
| **Scheme** | `http` |
|
||||
| **Forward Hostname / IP** | IP-Adresse des Containers |
|
||||
| **Forward Port** | `8080` |
|
||||
| **Block Common Exploits** | aktivieren |
|
||||
| **Websockets Support** | aktivieren |
|
||||
|
||||
Wechsle anschließend in den Reiter **SSL**:
|
||||
|
||||
- **Request a new SSL Certificate** → aktivieren
|
||||
- **Force SSL** → aktivieren
|
||||
- **HTTP/2 Support** → aktivieren
|
||||
|
||||
Speichern mit **Save**.
|
||||
|
||||
#### 2. Proxy-Host für öffentliche Dateiausgabe anlegen
|
||||
|
||||
Wiederhole den Vorgang mit den folgenden Werten:
|
||||
|
||||
| Feld | Wert |
|
||||
|------|------|
|
||||
| **Domain Names** | `assets.deinedomain.tld` |
|
||||
| **Scheme** | `http` |
|
||||
| **Forward Hostname / IP** | IP-Adresse des Containers |
|
||||
| **Forward Port** | `80` |
|
||||
| **Block Common Exploits** | aktivieren |
|
||||
|
||||
SSL-Einstellungen wie oben übernehmen.
|
||||
|
||||
> [!TIP]
|
||||
> Du kannst die interne Verwaltungsoberfläche (`assets-admin`) durch Basic-Auth oder IP-Access-Lists zusätzlich absichern.
|
||||
> Die öffentliche Dateiausgabe (`assets`) sollte hingegen ohne Authentifizierung erreichbar sein, damit andere Systeme darauf zugreifen können.
|
||||
|
||||
#### 3. Verbindung prüfen
|
||||
|
||||
Öffne im Browser:
|
||||
|
||||
```
|
||||
https://assets-admin.deinedomain.tld
|
||||
```
|
||||
|
||||
Wenn die Filebrowser-Anmeldung erscheint, funktioniert die Weiterleitung korrekt.
|
||||
Anschließend testest du die öffentliche Auslieferung über:
|
||||
|
||||
```
|
||||
https://assets.deinedomain.tld
|
||||
```
|
||||
|
||||
Im Browser sollte jetzt das automatische Verzeichnislisting erscheinen, das Nginx bereitstellt.
|
||||
|
||||
> [!NOTE]
|
||||
> Beide Adressen laufen über denselben Container, jedoch auf unterschiedlichen Ports.
|
||||
> Der Proxy Manager trennt Verwaltung (Port 8080) und Dateiauslieferung (Port 80) logisch voneinander.
|
||||
|
||||
### Schritt 9 – Benutzerverwaltung und Rechte in Filebrowser
|
||||
|
||||
Filebrowser unterstützt eine integrierte Benutzerverwaltung.
|
||||
Damit kannst du gezielt festlegen, wer Zugriff auf welche Bereiche innerhalb des Containers hat.
|
||||
So verhinderst du unbeabsichtigte Änderungen oder versehentliches Löschen von Dateien.
|
||||
|
||||
#### 1. Benutzerübersicht öffnen
|
||||
|
||||
Melde dich über die Subdomain oder IP im Filebrowser an und klicke oben rechts auf dein Profilbild → **Benutzer**.
|
||||
Hier kannst du neue Benutzer anlegen oder bestehende verwalten.
|
||||
|
||||
#### 2. Neuen Benutzer anlegen
|
||||
|
||||
1. Klicke auf **Neu**.
|
||||
2. Trage einen **Benutzernamen** und ein **Passwort** ein.
|
||||
3. Wähle im Feld **Verzeichnis** das Root-Verzeichnis des jeweiligen Benutzers, z. B.
|
||||
```
|
||||
/srv/assets/overlays
|
||||
```
|
||||
4. Setze die Berechtigungen nach Bedarf:
|
||||
- **Can Delete:** Benutzer darf Dateien löschen
|
||||
- **Can Rename:** Benutzer darf Dateien umbenennen
|
||||
- **Can Create:** Benutzer darf neue Dateien und Ordner anlegen
|
||||
- **Can Upload:** Benutzer darf Dateien hochladen
|
||||
- **Admin:** Vollzugriff auf alle Bereiche
|
||||
|
||||
> [!TIP]
|
||||
> Erstelle keine Admin-Benutzer für alltägliche Arbeiten.
|
||||
> Für Uploads und Korrekturen reichen Benutzer mit eingeschränkten Rechten aus.
|
||||
|
||||
#### 3. Benutzerrollen strukturieren
|
||||
|
||||
Für den Betrieb im UCC hat sich folgende Struktur bewährt:
|
||||
|
||||
| Benutzer | Verzeichnis | Rechte | Zweck |
|
||||
|-----------|--------------|---------|-------|
|
||||
| **admin** | `/srv/assets` | Vollzugriff | Systempflege und Strukturverwaltung |
|
||||
| **upload** | `/srv/assets/_upload` | Upload, Create, Rename | Upload von neuen Dateien |
|
||||
| **readonly** | `/srv/assets` | Nur Lesen | interner Zugriff durch andere Dienste |
|
||||
|
||||
Diese Rollenverteilung sorgt dafür, dass die Struktur stabil bleibt und nur definierte Benutzer Änderungen vornehmen können.
|
||||
|
||||
#### 4. Änderungen testen
|
||||
|
||||
Melde dich testweise mit einem eingeschränkten Benutzer an und prüfe:
|
||||
- Upload einer Datei
|
||||
- Anlegen eines Ordners
|
||||
- Versuch, eine Datei außerhalb des zugewiesenen Pfades zu öffnen
|
||||
|
||||
Wenn Filebrowser die Berechtigungen korrekt setzt, kann der Benutzer nur innerhalb seines Bereichs arbeiten.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Änderungen an der Benutzerverwaltung werden sofort aktiv.
|
||||
> Ein Neustart des Dienstes ist nicht erforderlich, sobald du einen Benutzer anlegst oder Rechte änderst.
|
||||
|
||||
### Schritt 10 – Sicherheit und Zugriffsbeschränkung
|
||||
|
||||
Da Filebrowser direkten Schreibzugriff auf das Dateisystem ermöglicht, ist eine sichere Konfiguration zwingend notwendig.
|
||||
Unabhängig davon, ob der Zugriff intern oder über das Internet erfolgt, müssen die folgenden Sicherheitsmaßnahmen umgesetzt werden.
|
||||
|
||||
#### 1. Standard-Admin sichern
|
||||
|
||||
Der Benutzer **admin** wird bei der Installation automatisch angelegt.
|
||||
Wenn du diesen Account weiterhin nutzt, ändere das Passwort auf ein sicheres, langes Kennwort mit mindestens 16 Zeichen.
|
||||
Alternativ solltest du den Standard-Account vollständig entfernen und einen eigenen Administrator mit eindeutigem Namen anlegen.
|
||||
|
||||
**Admin löschen:**
|
||||
|
||||
```bash
|
||||
filebrowser users rm admin
|
||||
```
|
||||
|
||||
**Neuen Administrator anlegen:**
|
||||
|
||||
1. Melde dich im Filebrowser mit einem bestehenden Benutzer an.
|
||||
2. Öffne oben rechts das Menü → **Benutzerverwaltung**.
|
||||
3. Klicke auf **Neu**.
|
||||
4. Gib einen eindeutigen **Benutzernamen** an (z. B. `systemadmin`).
|
||||
5. Trage ein sicheres **Passwort** ein.
|
||||
6. Wähle als **Verzeichnis** `/srv/assets`.
|
||||
7. Aktiviere den Schalter **Adminrechte**.
|
||||
8. Speichere mit **Erstellen**.
|
||||
9. Melde dich ab und anschließend mit dem neuen Benutzer wieder an, um die Anmeldung zu prüfen.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Verwende für den Adminzugang keine generischen Namen wie *admin*, *root* oder *file*.
|
||||
> Diese sind die ersten Zielnamen bei automatisierten Loginversuchen.
|
||||
|
||||
#### 2. Zugriff über NPM absichern
|
||||
|
||||
Im **Nginx Proxy Manager** kann der Zugang zu `assets-admin.deinedomain.tld` zusätzlich geschützt werden.
|
||||
Das reduziert die Angriffsfläche erheblich und blockiert unautorisierte Verbindungen bereits auf Proxy-Ebene.
|
||||
|
||||
1. Öffne im Dashboard den Proxy-Host für `assets-admin`.
|
||||
2. Wechsle in den Reiter **Access List**.
|
||||
3. Klicke auf **Add Access List** und konfiguriere:
|
||||
- **Access Authorization:** aktivieren
|
||||
- Benutzername und Passwort vergeben
|
||||
- **IP-Whitelist (optional):**
|
||||
Wenn du den Zugriff auf Filebrowser zusätzlich auf dein Heimnetz begrenzen willst,
|
||||
trage hier den Adressbereich deines lokalen Netzwerks ein.
|
||||
Beispiel für ein typisches Heimnetz: `192.168.100.0/24`
|
||||
(bedeutet: alle Geräte zwischen `192.168.100.1` und `192.168.100.254` dürfen zugreifen)
|
||||
Wenn du dir unsicher bist, kannst du diesen Schritt auch weglassen –
|
||||
der Zugang bleibt dann über Benutzername und Passwort geschützt.
|
||||
4. Speichere die Liste und wähle sie anschließend für den Proxy-Host aus.
|
||||
|
||||
Damit ist Filebrowser bereits vor dem eigentlichen Login geschützt.
|
||||
Zugriffe ohne gültige NPM-Anmeldung oder außerhalb der Whitelist werden direkt blockiert.
|
||||
|
||||
> [!NOTE]
|
||||
> Diese doppelte Authentifizierung – NPM + Filebrowser – ist ausdrücklich gewollt.
|
||||
> Selbst bei versehentlich schwachen Filebrowser-Logins schützt NPM zuverlässig vor externem Zugriff.
|
||||
|
||||
#### 3. Portzugriff einschränken
|
||||
|
||||
Filebrowser läuft intern auf Port **8080**, Nginx auf Port **80**.
|
||||
Diese Ports dürfen **nicht von außen erreichbar** sein.
|
||||
Der Zugriff erfolgt ausschließlich über den Nginx Proxy Manager.
|
||||
|
||||
Damit kein direkter Zugriff aus dem Internet möglich ist, aktivierst du im Container die Firewall **UFW** und erlaubst nur dein internes Netzwerk.
|
||||
|
||||
**Beispiel für ein typisches Heimnetz:**
|
||||
|
||||
Wenn dein internes Netz z. B. im Bereich `192.168.100.x` liegt, lautet die Regel:
|
||||
|
||||
```bash
|
||||
apt install ufw -y
|
||||
ufw allow from 127.0.0.1
|
||||
ufw allow from 192.168.100.0/24
|
||||
ufw deny 8080
|
||||
ufw deny 80
|
||||
ufw enable
|
||||
```
|
||||
|
||||
Damit dürfen nur Geräte aus deinem Heimnetz (z. B. dein PC oder OBS-Rechner) direkt auf den Container zugreifen.
|
||||
Alle externen Verbindungen werden blockiert, außer sie kommen über den Proxy Manager mit gültigem Zertifikat.
|
||||
|
||||
> [!NOTE]
|
||||
> Ersetze den Bereich `192.168.100.0/24` durch dein eigenes Netzwerk, falls du einen anderen IP-Bereich verwendest.
|
||||
> Du findest diesen Wert in Proxmox unter **Network** oder auf deinem Router.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Prüfe nach dem Aktivieren der Firewall sofort, ob du den Container noch über Proxmox oder SSH erreichst.
|
||||
> Eine falsche Regel kann dich komplett aussperren.
|
||||
|
||||
#### 4. Dienststatus regelmäßig prüfen
|
||||
|
||||
Überprüfe regelmäßig, ob die zentralen Dienste aktiv sind:
|
||||
|
||||
```bash
|
||||
systemctl status filebrowser
|
||||
systemctl status nginx
|
||||
```
|
||||
|
||||
Wenn einer der Dienste gestoppt wurde oder „failed“ anzeigt, starte ihn neu:
|
||||
|
||||
```bash
|
||||
systemctl restart filebrowser
|
||||
systemctl restart nginx
|
||||
```
|
||||
|
||||
> [!TIP]
|
||||
> Der Asset-LXC ist dauerhaft aktiv.
|
||||
> Eine Kontrolle im Rahmen der wöchentlichen Systempflege genügt, um mögliche Probleme frühzeitig zu erkennen.
|
||||
|
||||
### Schritt 11 – Funktionstest
|
||||
|
||||
Bevor du den Container dauerhaft nutzt oder in OBS einbindest, musst du prüfen, ob alles korrekt läuft.
|
||||
Der Funktionstest besteht aus zwei Teilen: erst direkt über die IP-Adresse, dann über den Proxy.
|
||||
|
||||
#### 1. Interner Test – direkter Aufruf
|
||||
|
||||
Damit du sicher sein kannst, dass **Filebrowser selbst** richtig funktioniert, wird der erste Test **ohne Proxy** durchgeführt.
|
||||
So lässt sich eindeutig unterscheiden, ob ein Fehler später vom Container oder vom Nginx Proxy Manager stammt.
|
||||
|
||||
**So findest du die IP-Adresse deines Asset-LXC:**
|
||||
|
||||
1. Öffne in **Proxmox** den Container mit der Bezeichnung `asset`.
|
||||
2. Klicke auf **Network** (links in der Menüleiste).
|
||||
3. In der Zeile **IPv4 Address** steht die interne Adresse, z. B. `192.168.100.30`.
|
||||
|
||||
Mit dieser Adresse öffnest du Filebrowser direkt im Browser.
|
||||
Setze dabei deine eigene IP ein:
|
||||
|
||||
```
|
||||
http://<IP-des-Asset-LXC>:8080
|
||||
```
|
||||
|
||||
Beispiel:
|
||||
|
||||
```
|
||||
http://192.168.100.30:8080
|
||||
```
|
||||
|
||||
Wenn die Login-Seite erscheint, läuft Filebrowser korrekt.
|
||||
|
||||
Melde dich mit deinem Administrator-Account an und überprüfe:
|
||||
|
||||
- Die Ordnerstruktur (`overlays`, `videos`, `sounds`, `projects`, `_meta`) wird angezeigt.
|
||||
- Das Hochladen einer Testdatei funktioniert.
|
||||
- Eine hochgeladene Datei lässt sich wieder herunterladen oder öffnen.
|
||||
- Rechtefehler wie „permission denied“ treten nicht auf.
|
||||
|
||||
> [!NOTE]
|
||||
> Wenn der Login oder Upload nicht funktioniert, liegt der Fehler **im Container selbst**.
|
||||
> In diesem Fall Proxy-Einbindung noch nicht aktivieren, sondern zuerst die interne Funktion reparieren.
|
||||
|
||||
#### 2. Test über den Nginx Proxy Manager
|
||||
|
||||
Wenn der interne Test erfolgreich war, erfolgt der Aufruf über die eingerichteten Subdomains:
|
||||
|
||||
```
|
||||
https://assets-admin.deinedomain.tld
|
||||
https://assets.deinedomain.tld
|
||||
```
|
||||
|
||||
- `assets-admin` führt zur Filebrowser-Oberfläche.
|
||||
- `assets` zeigt die öffentliche Dateiausgabe (Verzeichnislisting).
|
||||
|
||||
Öffne eine Datei im Browser.
|
||||
Wenn sie sofort geladen wird und in der Adresszeile **https://** steht, ist die verschlüsselte Verbindung aktiv.
|
||||
|
||||
> [!TIP]
|
||||
> Sollte `assets` zwar erreichbar sein, aber keine Inhalte anzeigen, überprüfe im Nginx Proxy Manager den **Forward-Port**.
|
||||
> Für die Dateiausgabe muss er auf **80** stehen, während Filebrowser über **8080** läuft.
|
||||
|
||||
#### 3. Browser-Caching prüfen
|
||||
|
||||
Lade die Seite mehrfach neu (z. B. mit **Strg + F5**).
|
||||
Wenn die Dateien direkt und ohne merkliche Verzögerung erscheinen, arbeitet das lokale Caching über Nginx korrekt.
|
||||
Das ist entscheidend für OBS – Overlays und Mediendateien werden dadurch sofort geladen, ohne jedes Mal neu übertragen zu werden.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Der Funktionstest bestätigt, dass dein Container vollständig und stabil läuft.
|
||||
> Erst wenn beide Adressen (intern und über Domain) fehlerfrei reagieren, gilt das Setup als abgeschlossen.
|
||||
|
||||
### Schritt 12 – Integration mit OBS
|
||||
|
||||
Nach erfolgreichem Funktionstest kann der Asset-LXC nun in **OBS Studio** eingebunden werden.
|
||||
Damit stehen alle gespeicherten Overlays, Sounds oder Videos direkt als Quelle zur Verfügung – ohne Cloud-Dienste oder manuelle Uploads.
|
||||
|
||||
#### 1. Vorbereitung
|
||||
|
||||
Vergewissere dich, dass:
|
||||
- Der Container stabil läuft und per Domain erreichbar ist.
|
||||
- Die Subdomain `assets.deinedomain.tld` im Browser funktioniert.
|
||||
- Deine Overlays oder Medien im Filebrowser-Ordner `/srv/assets/overlays` liegen.
|
||||
|
||||
Nur so kann OBS die Dateien korrekt laden.
|
||||
|
||||
> [!NOTE]
|
||||
> Alle URLs werden im lokalen Netzwerk oder über HTTPS ausgeliefert.
|
||||
> Eine aktive Internetverbindung ist für die Nutzung innerhalb des Heimnetzes nicht erforderlich.
|
||||
|
||||
#### 2. Overlay als Browserquelle einbinden
|
||||
|
||||
1. Öffne in OBS das **Szenenfenster**.
|
||||
2. Klicke auf das **„+“** unter den Quellen → **Browser**.
|
||||
3. Vergib einen eindeutigen Namen, z. B. `Chat Overlay` oder `Followerbanner`.
|
||||
4. Im Feld **URL** trägst du den vollständigen Pfad zur Overlay-Datei ein:
|
||||
|
||||
```
|
||||
https://assets.deinedomain.tld/overlays/chat.html
|
||||
```
|
||||
|
||||
5. Setze die Breite und Höhe entsprechend der Overlay-Größe (z. B. 1920 × 1080 px).
|
||||
6. Aktiviere **„Lokale Datei“ nicht** – die Datei wird direkt vom Asset-Server geladen.
|
||||
7. Klicke auf **OK**.
|
||||
|
||||
Das Overlay wird sofort geladen und angezeigt.
|
||||
Wenn du im Filebrowser eine Änderung an der Datei vornimmst (z. B. Text, Grafik, CSS), genügt in OBS ein **Rechtsklick → Aktualisieren**, um die neue Version zu sehen.
|
||||
|
||||
> [!TIP]
|
||||
> Über das Kontextmenü → **„Browser neu laden, wenn Szene aktiviert wird“** kannst du sicherstellen,
|
||||
> dass jedes Overlay beim Szenenwechsel automatisch aktualisiert wird.
|
||||
|
||||
#### 3. Statische Medien einbinden
|
||||
|
||||
Für Videos, Sounds oder Hintergrundgrafiken gilt dasselbe Prinzip.
|
||||
Beispiele:
|
||||
|
||||
| Medientyp | URL-Beispiel | OBS-Quelle |
|
||||
|------------|---------------|-------------|
|
||||
| Hintergrundvideo | `https://assets.deinedomain.tld/videos/intro.mp4` | Medienquelle |
|
||||
| Soundeffekt | `https://assets.deinedomain.tld/sounds/alert.mp3` | Medienquelle |
|
||||
| Grafik | `https://assets.deinedomain.tld/overlays/logo.png` | Bildquelle |
|
||||
|
||||
OBS lädt die Dateien direkt vom Asset-Server.
|
||||
Das reduziert lokale Speicherlast und sorgt dafür, dass alle Assets zentral gepflegt werden.
|
||||
|
||||
> [!NOTE]
|
||||
> Wenn ein Asset nicht geladen wird, prüfe zunächst, ob die URL im Browser funktioniert.
|
||||
> Wenn sie dort korrekt angezeigt wird, liegt das Problem in OBS (z. B. Cache).
|
||||
> In diesem Fall die Quelle löschen und erneut anlegen.
|
||||
|
||||
#### 4. Verhalten im lokalen Netzwerk
|
||||
|
||||
Wenn OBS und der Asset-LXC im selben LAN laufen, erfolgt der Zugriff mit minimaler Latenz.
|
||||
Der Aufruf über HTTPS bleibt bestehen, die Datenübertragung erfolgt aber ausschließlich intern.
|
||||
Es entstehen keine spürbaren Verzögerungen – selbst große Overlays oder Videos laden nahezu sofort.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Für Liveproduktionen sollten Overlays, Sounds und Grafiken immer lokal über den Asset-LXC eingebunden werden.
|
||||
> Dadurch entfällt die Abhängigkeit von externen Servern, und du behältst die volle Kontrolle über deine Stream-Assets.
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting & Tipps
|
||||
|
||||
Auch wenn der Asset-LXC im Normalbetrieb sehr stabil läuft, können nach der Einrichtung kleinere Probleme auftreten.
|
||||
Die folgenden Punkte decken die häufigsten Ursachen ab und zeigen, wie du sie systematisch behebst.
|
||||
|
||||
### Filebrowser nicht erreichbar
|
||||
|
||||
Wenn die Login-Seite nicht lädt oder der Browser „Verbindung fehlgeschlagen“ meldet:
|
||||
|
||||
1. In **Proxmox** prüfen, ob der Container läuft.
|
||||
Falls gestoppt → **Start** klicken.
|
||||
2. In der Konsole prüfen, ob der Dienst aktiv ist:
|
||||
```bash
|
||||
systemctl status filebrowser
|
||||
```
|
||||
Wenn der Dienst „inactive“ oder „failed“ anzeigt:
|
||||
```bash
|
||||
systemctl restart filebrowser
|
||||
```
|
||||
3. Direkt im Browser testen:
|
||||
```
|
||||
http://<IP-des-Asset-LXC>:8080
|
||||
```
|
||||
Wenn das funktioniert, liegt das Problem beim Proxy (Domain oder SSL-Zertifikat prüfen).
|
||||
|
||||
> [!TIP]
|
||||
> Nach einem Neustart benötigt Filebrowser bis zu 10 Sekunden, bevor die Login-Seite wieder erreichbar ist.
|
||||
|
||||
### Login funktioniert, aber keine Dateien sichtbar
|
||||
|
||||
Wenn nach dem Einloggen ein leeres Verzeichnis angezeigt wird:
|
||||
|
||||
- Prüfe, ob der Benutzer im richtigen Pfad arbeitet:
|
||||
Menü → **Benutzerverwaltung** → Benutzer → Feld **Verzeichnis**
|
||||
Der Pfad muss auf `/srv/assets` oder einen Unterordner zeigen.
|
||||
- Überprüfe die Berechtigungen:
|
||||
```bash
|
||||
ls -ld /srv/assets
|
||||
```
|
||||
Eigentümer muss `www-data` sein:
|
||||
```bash
|
||||
chown -R www-data:www-data /srv/assets
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> Filebrowser zeigt nur Inhalte an, auf die der Benutzer Zugriff hat.
|
||||
> Wenn der Pfad leer oder falsch gesetzt ist, bleibt die Oberfläche leer.
|
||||
|
||||
### Kein Zugriff über Subdomain
|
||||
|
||||
Wenn `https://assets.deinedomain.tld` oder `https://assets-admin.deinedomain.tld` nicht erreichbar ist:
|
||||
|
||||
1. Im **Nginx Proxy Manager** den Proxy-Host öffnen.
|
||||
2. **Forward Hostname / IP** prüfen – dort muss die IP des Asset-LXC stehen.
|
||||
3. **Forward Port** prüfen –
|
||||
- `8080` für Filebrowser
|
||||
- `80` für öffentliche Dateiausgabe
|
||||
4. SSL-Zertifikat kontrollieren – ggf. erneuern über **Renew Certificate**.
|
||||
|
||||
> [!TIP]
|
||||
> Wenn beide Domains gleichzeitig ausfallen, liegt der Fehler fast immer an einer DNS-Änderung oder einem abgelaufenen Zertifikat.
|
||||
|
||||
### Upload bricht ab oder lädt nicht
|
||||
|
||||
Wenn der Upload von größeren Dateien fehlschlägt oder einfriert:
|
||||
|
||||
1. Prüfen, ob noch genügend Speicherplatz verfügbar ist:
|
||||
```bash
|
||||
df -h /srv/assets
|
||||
```
|
||||
Wenn weniger als 1 GB frei ist, Dateien löschen oder Speicher erweitern.
|
||||
2. Prüfen, ob Filebrowser genügend Rechte hat:
|
||||
```bash
|
||||
systemctl restart filebrowser
|
||||
```
|
||||
3. Browser-Cache leeren und Upload erneut testen.
|
||||
|
||||
> [!NOTE]
|
||||
> Filebrowser lädt Dateien vollständig in den RAM, bevor sie geschrieben werden.
|
||||
> Wenn der Container zu wenig Arbeitsspeicher hat, kann der Upload abbrechen.
|
||||
|
||||
### Verzeichnislisting zeigt keine Vorschau
|
||||
|
||||
Wenn du `https://assets.deinedomain.tld` öffnest und nur Text statt einer Übersicht siehst:
|
||||
|
||||
- Stelle sicher, dass Nginx mit aktiviertem Autoindex läuft:
|
||||
```bash
|
||||
nano /etc/nginx/sites-available/assets.conf
|
||||
```
|
||||
Prüfe, ob folgender Block enthalten ist:
|
||||
```
|
||||
autoindex on;
|
||||
autoindex_exact_size off;
|
||||
autoindex_localtime on;
|
||||
```
|
||||
Danach:
|
||||
```bash
|
||||
nginx -t
|
||||
systemctl restart nginx
|
||||
```
|
||||
|
||||
> [!TIP]
|
||||
> Wenn du lieber ein strukturiertes Weblayout möchtest, kann später eine eigene HTML-Startseite unter `/srv/assets/index.html` hinterlegt werden.
|
||||
|
||||
### Filebrowser startet nach Reboot nicht automatisch
|
||||
|
||||
Wenn Filebrowser nach einem Neustart nicht läuft:
|
||||
|
||||
1. Dienststatus prüfen:
|
||||
```bash
|
||||
systemctl is-enabled filebrowser
|
||||
```
|
||||
Wenn „disabled“:
|
||||
```bash
|
||||
systemctl enable filebrowser
|
||||
systemctl start filebrowser
|
||||
```
|
||||
2. Funktion mit Browseraufruf verifizieren:
|
||||
```
|
||||
http://<IP-des-Asset-LXC>:8080
|
||||
```
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Wenn Filebrowser manuell über den CLI-Befehl gestartet wurde, läuft er nur temporär.
|
||||
> Der Dienst muss eingerichtet und aktiviert sein, damit er nach jedem Neustart automatisch startet.
|
||||
|
||||
### Regelmäßige Kontrolle
|
||||
|
||||
Damit der Container langfristig stabil bleibt:
|
||||
|
||||
- Einmal pro Monat Systemupdates durchführen:
|
||||
```bash
|
||||
apt update && apt upgrade -y
|
||||
```
|
||||
- Datei- und Benutzerrechte prüfen
|
||||
- Speicherplatz regelmäßig überwachen (`df -h`)
|
||||
- Backups von `/srv/assets` in Kopia oder ein externes Laufwerk einbinden
|
||||
|
||||
> [!TIP]
|
||||
> Eine einfache Routine:
|
||||
> - Monatlich Updates
|
||||
> - Wöchentlich Funktionstest
|
||||
> - Nach jedem größeren Upload ein Backup auslösen
|
||||
> Damit bleibt der Asset-LXC wartungsarm und jederzeit einsatzbereit.
|
||||
|
||||
---
|
||||
|
||||
## Abschluss
|
||||
|
||||
Der Asset-LXC stellt die zentrale Ablage für alle Streaming- und Produktionsdateien bereit.
|
||||
Mit Nginx und Filebrowser ist ein System entstanden, das sowohl für Einzelanwender als auch für größere Content-Projekte geeignet ist.
|
||||
Es kombiniert einfache Bedienung mit direktem Zugriff auf alle wichtigen Assets – ohne Abhängigkeit von Cloud-Diensten oder Drittanbietern.
|
||||
|
||||
Die Verbindung mit OBS ermöglicht eine nahtlose Integration von Overlays, Sounds, Grafiken und Videodateien direkt aus dem eigenen Netzwerk.
|
||||
Damit entfallen manuelle Uploads oder externe Links – Änderungen werden sofort wirksam, sobald die Dateien im Filebrowser aktualisiert werden.
|
||||
|
||||
Ein korrekt eingerichteter Asset-LXC bietet:
|
||||
|
||||
- Zentrale Verwaltung aller Mediendateien
|
||||
- Direkten Zugriff über HTTPS und klare Benutzerrechte
|
||||
- Sichere Authentifizierung über den Nginx Proxy Manager
|
||||
- Lokale Performance ohne externe Abhängigkeiten
|
||||
- Erweiterbarkeit durch zusätzliche LXC-Container oder Automatisierung über n8n
|
||||
|
||||
> [!NOTE]
|
||||
> Der Asset-LXC ist bewusst modular aufgebaut.
|
||||
> Er funktioniert eigenständig, kann aber in späteren Kapiteln weiter ausgebaut werden – z. B. durch automatische Synchronisierung mit Cloudspeichern, Integration in Produktionsabläufe oder automatisierte Asset-Distribution für mehrere Streaming-PCs.
|
||||
|
||||
Mit Abschluss dieses Kapitels steht ein vollständig funktionsfähiger und abgesicherter Dateiserver zur Verfügung,
|
||||
der die Grundlage für alle visuellen und akustischen Inhalte innerhalb des UCC bildet.
|
||||
Er ist damit ein zentrales Element der gesamten Infrastruktur – klein, effizient und jederzeit erweiterbar.
|
||||
Reference in New Issue
Block a user