Warum das Ganze?

Ich bin kein großer Nutzer von Social Media. Eigentlich verwende ich so wirklich nur Youtube regelmäßig (und lese Kommentare unter Zeitungsartikel, falls das überhaupt als Social Media zählt) und gelegentlich ein paar Meisen_aus_Urfahr. Aber diese Plattform hat durch das jahrzehntelange quasi-Monopol eine enorme kulturelle Stellung in Europa und weiten Teilen der Welt erlangt. Von belangloser Unterhaltung, zu Anleitung für die obskursten Dinge über hochpolitischen Inhalte (von Diskussionen gescheiter Leute bis hin zu extremistischen Rotz), ganz zu schweigen von den unzähligen Musikstücken und der größten Sammlung an Aufnahmen von Videospielen der Menschheitsgeschichte, Youtube sitzt nicht nur in den Datenzentren, sondern auch ganz tief in den Köpfen von Milliarden von Menschen.

Das war lange Zeit auch kein Problem, wir leben ja in der globalisierten Welt, Daten, Güter und Menschen kommen von einem Teil in den anderen. Wir konsumieren amerikanische Kultur und Softwaredienste, dafür kaufen die Amerikaner europäische Autos und Maschinen. Dass sich dieses Verhältnis jemals ändern würde, war und ist für Viele undenkbar. Doch seitdem Donald Trump und seine Clique fleißig am Kleinholz-Schlagen sind, sind zumindest schon einmal alle Gewissheiten Kleinholz. So wie es vor dem 20. Jänner 2025 absurd angemutet hätte, wenn ein Verbündeter das Land eines anderen Verbündeten weg-annektieren wollte, so klingt es womöglich jetzt auch absurd anzunehmen solch Selbstverständlichkeiten wie Google oder Youtube könnten einmal weg sein. Ich denke zwar nicht unbedingt, dass die US-Techgiganten ihre dominante Rolle in Europa verlieren werden. Aber man kann es auch nicht mehr ausschließen, dass ein wütender Trump seinen IT-Firmen die Anweisung gibt, erst einmal die Cloud-Services der Europäer auszuschalten (wenn auch nur vorübergehend), falls sie nicht seinen Forderungen nachgeben.

Aber wie stehen wir Europäer in Sachen soziale Medien überhaupt da? Eher armselig. Aber Pessimismus (“Ois Oasch”) und Fatalismus (“Kauma eh (mehr) nix mochn”) sind mir etwas zu bequeme Ausflüchte in diesen unbequemen Zeiten, oder frei nach “Poidl”:

“Ich kann Euch zu Social Media nichts geben. Kein Stück Plattform, keine Gründer- und keine Netzwerkeffekte für Reichweiten. Wir haben nichts. Ich kann Euch nur bitten: Glaubt an dieses Digital-Europa”

Als ersten Schritt sehe ich daher an, den Blick herumschweifen zu lassen und nachzusehen, was es denn da sonst noch gibt. Und da die große Videoplattform auch für mich eine hohe Relevanz hat, werden wir heute, wie angekündigt, Peertube installieren.

Was ist das Fediverse und wird es klassische Social Media Plattformen ersetzen?

Das Fediverse ist Gruppe an verschiedenen Social Media Services, die als Open Source Software auf eigene Server installiert werden können. Diese dezentralen Dienste nutzen jedoch den offenen Standard namens ActivityPub und können somit miteinander kommunizieren. Ein wenig wie Email oder RSS-Feeds für Podcast. Es ist egal bei welchem Anbieter man ist und welche App man verwenden möchte, alle sind untereinander kompatibel. Das verspricht auch das Fediverse. Neben den “Youtube-Klon” (was es nicht ist) Peertube, gibt es auch noch X und Instagram Alternativen namens Mastodon und Pixelfed.

Es ist ein interessantes Unterfangen, auch wenn ich nicht glaube das sich so schnell etwas an der Dominanz der Techgiganten ändern wird. Aus Interesse an Neuem und dem Versuch auszuloten, was zumindest technisch möglich ist, werde ich in diesem Beitrag die Installation Peertube auf Proxmox in einem LXC Container herzeigen. Nachmachen ist erwünscht. So könnten nach und nach ein paar Pflänzchen in der Social Media Digitalwüste Europa erblühen. Wenn nicht haben wir zumindest etwas gelernt.

Docker auf Proxmox LXC

Wenn möglich, dann setzte ich lieber auf nicht-Docker-Lösungen, denn die extra Komplexität von Docker Containern, plus deren eigener Netzwerkstack, sind oft nicht notwendig. Außerdem habe ich mich in den letzten beiden Jahren intensiv mit Proxmox auseinander gesetzt. Ich genieße die Vorzüge der übersichtlichen Verwaltung von virtuellen Maschinen und LXC-Containern. Da diese Peertube Installation jedoch auf meinem Mietserver laufen wird, und dort keine verschachtelte Virtualisierung möglich ist, werde ich diese Installation in LXC machen. Mir ist klar, dass hier die Verschachtelung wieder einschleicht, aber vorerst werde ich es bei dieser Installationsart belassen. Für die Leser ist es ja vielleicht interessant zu erfahren, wie so ein Setup funktioniert.

LXC erstellen und Docker Compose Config anpassen

Zuerst klone ich ein bereits vorbereitetes LXC-Template mit Ubuntu 24.04 und Docker vorinstalliert. Dort Updates einspielen und schon kann es los gehen.

Die offizielle Dokumentation bietet eine Anleitung für die Installation mit Docker Compose. Darin wird auf eine die Docker Compose Konfigurationsdatei verwiesen. Diese beinhaltet ein Setup mit certbot, einer Software für das automatische aktualisieren der SSL-Zertifikate. Das brauche ich aber nicht, da ich dafür Caddy verwende.

Ich habe daher den Chatbot bemüht eine “schlankere” Version zu erstellen, die ohne Zertfizierung auskommt. Außerdem habe ich die Docker Volumes, wenn nötig, durch die POSIX-konformen Pfade unter /opt, für die Konfiguration und Programm-Daten, wie die Datenbank, und /srv für die Videos. Letztere werden vorerst einfach lokal innerhalb des Containers gespeichert. Später möchte ich dies durch das Einbinden von Mountpoints, sei es mit extra Speicher vom Mietserver oder eines Netzwerkshares, ersetzen.

Zuerst muss man die entsprechenden Verzeichnisse erstellen:

mkdir /opt/peertube
mkdir /srv/peertube/data

Hier ist das verschlankte docker-compose.yml File, welches statt nginx Caddy verwendet:

services:

  peertube:
    image: chocobozzz/peertube:production-bookworm
    env_file:
      - .env
    ports:
      - "9000:9000"   # Expose internal port for Caddy reverse proxy
      - "1935:1935"   # For live streaming (if needed)
    volumes:
      - assets:/app/client/dist
      - /srv/peertube/data:/data
      - /opt/peertube/config:/config
    depends_on:
      - postgres
      - redis
      - postfix
    restart: "always"

  postgres:
    image: postgres:13-alpine
    env_file:
      - .env
    volumes:
      - /opt/peertube/db:/var/lib/postgresql/data
    restart: "always"

  redis:
    image: redis:6-alpine
    volumes:
      - /opt/peertube/redis:/data
    restart: "always"

  postfix:
    image: mwader/postfix-relay
    env_file:
      - .env
    volumes:
      - /opt/peertube/opendkim/keys:/etc/opendkim/keys
    restart: "always"

volumes:
  assets:

Die .env Datei kann in etwa so aussehen, obwohl sie hier eher angeführt wird, um zu zeigen welche Funktionen aktiviert sind und welche nicht:

# Database / Postgres service configuration
POSTGRES_USER=postgres_user
POSTGRES_PASSWORD=
# Postgres database name "peertube"
POSTGRES_DB=peertube
# The database name used by PeerTube will be PEERTUBE_DB_NAME (only if set) *OR* 'peertube'+PEERTUBE_DB_SUFFIX
#PEERTUBE_DB_NAME=<MY POSTGRES DB NAME>
#PEERTUBE_DB_SUFFIX=_prod
# Database username and password used by PeerTube must match Postgres', so they are copied:
PEERTUBE_DB_USERNAME=$POSTGRES_USER
PEERTUBE_DB_PASSWORD=$POSTGRES_PASSWORD
PEERTUBE_DB_SSL=false
# Default to Postgres service name "postgres" in docker-compose.yml
PEERTUBE_DB_HOSTNAME=postgres

# PeerTube server configuration
# If you test PeerTube in local: use "peertube.localhost" and add this domain to your host file resolving on 127.0.0.1
PEERTUBE_WEBSERVER_HOSTNAME=zagma.at
# If you just want to test PeerTube on local
#PEERTUBE_WEBSERVER_PORT=9000
#PEERTUBE_WEBSERVER_HTTPS=false
# If you need more than one IP as trust_proxy
# pass them as a comma separated array:
PEERTUBE_TRUST_PROXY=["127.0.0.1", "loopback", "10.10.1.0/24"]

# Generate one using `openssl rand -hex 32`
PEERTUBE_SECRET=

# E-mail configuration
# If you use a Custom SMTP server
#PEERTUBE_SMTP_USERNAME=
#PEERTUBE_SMTP_PASSWORD=
# Default to Postfix service name "postfix" in docker-compose.yml
# May be the hostname of your Custom SMTP server
PEERTUBE_SMTP_HOSTNAME=postfix
PEERTUBE_SMTP_PORT=25
PEERTUBE_SMTP_FROM=noreply@domain.com
PEERTUBE_SMTP_TLS=false
PEERTUBE_SMTP_DISABLE_STARTTLS=false
PEERTUBE_ADMIN_EMAIL=

# Postfix service configuration
POSTFIX_myhostname=
# If you need to generate a list of sub/DOMAIN keys
# pass them as a whitespace separated string <DOMAIN>=<selector>
OPENDKIM_DOMAINS=zagma.at=peertube
# see https://github.com/wader/postfix-relay/pull/18
OPENDKIM_RequireSafeKeys=no

# Comment these variables if your S3 provider does not support object ACL
# PEERTUBE_OBJECT_STORAGE_UPLOAD_ACL_PUBLIC="public-read"
# PEERTUBE_OBJECT_STORAGE_UPLOAD_ACL_PRIVATE="private"

#PEERTUBE_LOG_LEVEL=info

# /!\ Prefer to use the PeerTube admin interface to set the following configurations /!\
#PEERTUBE_SIGNUP_ENABLED=true
PEERTUBE_TRANSCODING_ENABLED=true
#PEERTUBE_CONTACT_FORM_ENABLED=true

Für Caddy muss man dann noch folgende Zeilen hinzufügen:

domain.com {
	reverse_proxy xxx.xxx.xxx.xxx:9000
}

User und Ordner erstellen und Docker starten

Als nächstes erstellen wir einen User für Docker.

adduser peertube

Zur Dockergruppe hinzufügen:

usermod -aG docker peertube

Der Besitzer der vorher erstellten Verzeichnisse und Dateien muss nun auf den neuen User übertragen werden, sonst funktioniert es nicht:

chown -R peertube:peertube /opt/peertube
chown -R peertube:peertube /srv/peertube
  • -R sorgt dafür das alles rekursiv abläuft und alle Unterordner samt Dateien miteinschließt

Vorher:

Nachher:

Die Berechtigungen für die Verzeichnisse müssen bei 755 bzw. 750 liegen. Bei letzterem kann es jedoch zu Problemen kommen, wenn der Webserver (in den Onlinebeispielen nginx, aber womöglich auch bei Caddy). Zuerst probieren wir 750, also etwas strenger/sicherer, falls das nicht klappt bleiben wir hier bei 755. Es kann also nur der Besitzer (7) Änderungen durchführen, Gruppenmitglieder (5) und Andere (5) können nur lesen.

Mit diesen Befehlen kann man selektiv die Ordnerberechtigungen ändern:

find /opt/peertube -type d -exec chmod 750 {} \;

Und für den Video-Ordner:

find /srv/peertube -type d -exec chmod 750 {} \;

Update: 750 funktioniert nicht, der Webserver kann nicht mehr drauf, also doch 755:

find /srv/peertube -type d -exec chmod 755 {} \;

Für die Config-Dateien genügt 640, also keine Ausführbarkeit (execute), das wird nicht benötigt, da nur bei den Verzeichnissen ausgeführt werden muss um das Verzeichnis überhaupt aufrufen zu können. Die Videodateien selbst brauchen zumindest bei nginx 644, da dort der Webserver (bei Debian-Systemen) mit dem User www-data operiert und sonst keinen Zugriff mehr hat.

Daher 640 für /opt/peertube

find /opt/peertube -type f -exec chmod 640 {} \;

… und 644 für /srv/peertube:

find /srv/peertube -type f -exec chmod 644 {} \;

Was jetzt noch nicht relevant ist, da eh noch keine Daten im Video-Ordner sind.

Docker hochfahren, vorerst ohne -d für den Hintergrundbetrieb…

docker compose up

… denn wir brauchen noch das generierte root Passwort aus den Logs:

Voilà

Und schon kann man auf die neue Peertube Instanz zugreifen und mit dem mitgegebenen Passwort einloggen:

Wunderbar!

Das sind die nützlichen Links:

Sowie:

Jetzt muss man noch das generierte Passwort ändern und kann mit dem Erstellen eines Useraccounts beginnen.

Ich denke das genügt vorerst einmal. Beim nächsten Mal werde ich das die Videoplattform präsentieren und eine kleine Tour durch die Einstellungen machen.

Hilfreiche Websites:

  • Dieser Artikel beschreibt gut die Grundfunktion von Peertube aus Sicht der System Administration. Mit vielen Troubleshooting Tipps!