OpenCloud Pilot — Aufbau- und Betriebsdokumentation

Eine souveräne Cloud auf ARM-Basis, die in eine Hand passt.

Diese Dokumentation beschreibt vollständig, wie das Gerät aufgebaut, eingerichtet, abgesichert und betrieben wird. Sie ist so geschrieben, dass auch jemand mit wenig technischer Erfahrung Schritt für Schritt nachvollziehen und das Gerät nachbauen kann. Jeder Befehl wird in einfacher Sprache erklärt.

Lizenz

Lizenziert unter der European Union Public Licence v1.2 (EUPL-1.2) oder, nach Wahl, jeder späteren Version. Du darfst dieses Dokument nutzen, weitergeben und verändern, solange du diese Lizenz und die Urheberangabe erhältst. Der vollständige Lizenztext ist verfügbar unter: https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12

Bei Weiterverwendung bitte als Quelle nennen: Pandolin — pandolin.io.

Wichtiger Hinweis zu Geheimnissen: Dieses Dokument enthält keine echten Passwörter, Schlüssel oder privaten Adressen. Überall, wo <...> steht, musst du deinen eigenen Wert einsetzen. Trage echte Passwörter niemals in eine Datei ein, die du veröffentlichst oder weitergibst.

1. Was ist das Gerät, und was ist es nicht

Das OpenCloud Pilot ist ein kleiner, energieeffizienter Einplatinen-Computer (Raspberry Pi 5), der die quelloffene Software OpenCloud betreibt. OpenCloud ist eine Sync-und-Share-Cloud: Dateien ablegen, versionieren, in geteilten Bereichen (Spaces) zusammenarbeiten, über eine Weboberfläche und mobile Apps zugreifen. Die Daten liegen physisch auf einem Laufwerk im Gerät selbst, nicht bei einem fremden Anbieter.

Wofür es gedacht ist: als produktiver Prototyp für kleine Szenarien (Verein, kleiner Mittelständler, Familie, Community), als Proof of Concept für größere Infrastrukturen, und als Demonstrationsgerät, an dem man digitale Souveränität anfassen kann.

Was es nicht ist: kein klassischer NAS-Fileserver. OpenCloud bietet keine Windows-Netzlaufwerke (SMB) oder NFS-Freigaben im klassischen Sinn an, sondern Sync und Share über Web, WebDAV und eigene Clients. Es ist außerdem keine hochverfügbare Infrastruktur: Es ist ein einzelnes Gerät. Wer Ausfallsicherheit über mehrere Knoten oder zwanzig Terabyte RAID-Speicher braucht, ist mit anderer Hardware besser bedient. Diese Grenzen sind bewusst gewählt.

2. Stückliste (verwendete Hardware)

Komponente	Konkret verwendetes Modell	Funktion	Hinweis
Einplatinen-Computer	Raspberry Pi 5 (8 GB RAM)	Das Herzstück, die CPU	Ein 16-GB-Modell geht auch, ist aber 2026 deutlich teurer geworden
HAT (Aufsteckplatine)	52Pi M.2 NVMe M-Key & PoE+ HAT	Hält die System-SSD (NVMe) und ermöglicht Stromversorgung über das Netzwerkkabel (PoE)	Unterstützt NVMe in Baugröße 2230 bis 2280
System-Laufwerk	Samsung PM961 128 GB (NVMe, M.2 2280)	Betriebssystem und Programme	Gebraucht beschafft, vor Einsatz geprüft (siehe Schritt 4)
Daten-Laufwerk	Samsung 870 EVO 1 TB (2,5″ SATA-SSD)	Hier liegen die eigentlichen Cloud-Daten	Sichtbar als Datenträger, „die Daten in deiner Hand"
SATA-Adapterplatine	Geekworm X1100 (USB-3.0-SATA-Shield, Unterseite)	Verbindet die SATA-SSD mit dem Pi	Wird unter dem Pi montiert, lässt die GPIO-Leiste fürs PoE-HAT frei
Kühlung	Raspberry Pi Active Cooler	Aktive Kühlung der CPU	Lag dem HAT-Set bei
Stromversorgung	PoE+ (über Netzwerkkabel) oder USB-C-Netzteil (5V/5A)	Strom	PoE = ein Kabel für Strom und Daten zugleich

Software-Stand zur Erstellung dieser Doku:

Betriebssystem: Raspberry Pi OS Lite (64-bit)
Docker Engine 29.x, Docker Compose v2 (v5.x der Compose-Auslieferung)
OpenCloud Container-Image: opencloudeu/opencloud-rolling:6.2.0 (fest gepinnt)
Reverse Proxy: Traefik v3.6.14 (Teil des OpenCloud-Compose-Pakets)

3. Konventionen in dieser Anleitung

Zeilen in grauen Kästen sind Befehle, die du im Terminal eingibst. Nach jedem Befehl steht, was er bewirkt.
<PLATZHALTER> musst du durch deinen eigenen Wert ersetzen. Die spitzen Klammern entfernst du dabei mit.
Befehle mit sudo werden mit Administratorrechten ausgeführt. Das System fragt dann eventuell nach deinem Passwort.
Das Gerät heißt im Netzwerk opencloudpilot und ist als opencloudpilot.local erreichbar. Diesen Namen kannst du anpassen.

4. Schritt für Schritt: Aufbau und Einrichtung

Schritt 4.1 — Hardware zusammenbauen

Der Aufbau ist ein dreistöckiger Turm: unten der Pi 5, darüber das PoE-/NVMe-HAT mit der System-SSD, und seitlich beziehungsweise unten die Daten-SSD auf der X1100-Platine. Die System-NVMe wird in den M.2-Steckplatz des HAT geschoben und verschraubt, die Daten-SSD auf die X1100 gesteckt und mit dem USB-3.0-Brückenstecker mit dem Pi verbunden.

Wenn du Strom über PoE beziehst (ein Kabel): Damit der Pi über das Netzwerkkabel genug Strom für die angeschlossenen Laufwerke freigibt, muss eine Einstellung gesetzt werden (siehe Schritt 4.3). Ohne sie begrenzt der Pi den USB-Strom vorsichtshalber.

Schritt 4.2 — Betriebssystem auf die System-SSD schreiben

Verwende den offiziellen Raspberry Pi Imager (auf einem beliebigen Rechner) und schreibe Raspberry Pi OS Lite (64-bit) auf die NVMe-SSD. „Lite" bedeutet ohne grafische Oberfläche, das ist für einen Server genau richtig und spart Ressourcen. Aktiviere im Imager am besten gleich SSH und einen ersten Benutzer.

Hintergrund: Die OpenCloud-Dokumentation empfiehlt Raspberry Pi OS als Host-System. Dass die Software in einem Container läuft, macht das darunterliegende Betriebssystem weitgehend unkritisch.

Schritt 4.3 — Grundkonfiguration des Systems

Melde dich per SSH am Gerät an und setze die Grundeinstellungen.

Gerätenamen setzen (damit es im Netzwerk auffindbar ist):

sudo hostnamectl set-hostname opencloudpilot

Bewirkt: Das Gerät heißt fortan opencloudpilot und ist über opencloudpilot.local im lokalen Netz erreichbar (per mDNS/Avahi, das bei Raspberry Pi OS vorinstalliert ist).

Zeitzone setzen:

sudo timedatectl set-timezone Europe/Berlin

Bewirkt: Logs und Zeitstempel laufen auf mitteleuropäischer Zeit statt auf der Standardzeit.

USB-Stromgrenze anheben (nur nötig bei PoE-Betrieb):

echo 'usb_max_current_enable=1' | sudo tee -a /boot/firmware/config.txt

Bewirkt: Erlaubt dem Pi, den angeschlossenen Laufwerken mehr Strom bereitzustellen. Bei Stromversorgung über das offizielle USB-C-Netzteil ist das nicht nötig.

Danach einmal neu starten:

sudo reboot

Schritt 4.4 — Daten-Laufwerk prüfen und vorbereiten

Wenn du eine gebrauchte SSD verwendest, prüfe zuerst, ob sie wirklich leer ist. Ziel ist festzustellen, ob sie ordentlich gelöscht wurde, nicht, die Daten eines Vorbesitzers anzusehen. Diese Prüfungen verändern nichts, sie lesen nur.

sudo wipefs -n /dev/sda
sudo lsblk -f /dev/sda
sudo dd if=/dev/sda bs=1M count=64 status=none | hexdump -C | head -n 20

Bewirkt: Zeigt vorhandene Dateisystem-Signaturen, Partitionen und den Anfang des Laufwerks an. Lauter 00 am Anfang bedeutet „leer". Tauchen Texte oder Dateisystemstrukturen auf, war die Platte nicht sauber gelöscht.

Achtung: /dev/sda ist hier die Daten-SSD. Vergewissere dich mit lsblk, dass du wirklich die richtige Platte ansprichst, nicht die System-NVMe. Ein falsches Ziel löscht das falsche Laufwerk.

Falls Restdaten gefunden wurden (oder zur Sicherheit immer): Laufwerk sauber leeren.

sudo blkdiscard /dev/sda

Bewirkt: Weist die SSD an, alle Speicherzellen freizugeben (TRIM). Schnell und schonend, der richtige Weg für eine SSD.

Dateisystem anlegen und benennen:

sudo mkfs.ext4 -L opencloud-data /dev/sda

Bewirkt: Legt ein frisches ext4-Dateisystem mit dem Namen (Label) opencloud-data an.

Einhängepunkt anlegen und die eindeutige Kennung (UUID) auslesen:

sudo mkdir -p /opt/opencloud/data
sudo blkid /dev/sda

Bewirkt: Erstellt den Zielordner und zeigt die UUID des Laufwerks an. Notiere die UUID, du brauchst sie gleich.

Dauerhaftes Einhängen einrichten (ersetze <DEINE_UUID> durch die gerade ausgelesene UUID):

echo 'UUID=<DEINE_UUID> /opt/opencloud/data ext4 defaults,nofail,x-systemd.device-timeout=10 0 2' | sudo tee -a /etc/fstab
sudo systemctl daemon-reload
sudo mount -a
df -h /opt/opencloud/data

Bewirkt: Trägt das Laufwerk in die Boot-Konfiguration ein, sodass es bei jedem Start automatisch eingehängt wird. Das nofail sorgt dafür, dass der Pi auch dann startet, wenn die Platte einmal fehlt (zum Beispiel beim Transport). df zeigt zur Kontrolle die eingehängte Platte mit ihrer Größe.

Rechte für OpenCloud setzen (wichtig, bitte genau so):

sudo chown -R 1000:1000 /opt/opencloud/data

Bewirkt: Übergibt das Datenverzeichnis dem Benutzer mit der Nummer 1000. Die OpenCloud-Software läuft im Container unter genau dieser Nummer und braucht diese Eigentümerschaft, um schreiben zu können. Merke dir diese 1000, sie ist später bei der Absicherung wichtig.

Schritt 4.5 — Docker installieren

OpenCloud läuft in Containern, dafür wird Docker benötigt.

curl -fsSL https://get.docker.com | sudo sh

Bewirkt: Lädt das offizielle Docker-Installationsskript und richtet Docker Engine samt Docker Compose v2 ein. Das ist der saubere Weg, der die moderne Compose-Version mitbringt.

Schritt 4.6 — OpenCloud einrichten

Das OpenCloud-Compose-Paket holen und an einen neutralen Ort legen:

git clone https://github.com/opencloud-eu/opencloud-compose.git
sudo mv opencloud-compose /opt/opencloud-compose
cd /opt/opencloud-compose

Bewirkt: Lädt die offiziellen Compose-Vorlagen herunter und verschiebt sie nach /opt/opencloud-compose, einen benutzerunabhängigen Ort. So hängt die Verwaltung nicht am Heimatverzeichnis einer einzelnen Person.

Konfigurationsdatei .env erstellen. Lege im Ordner eine Datei .env an (zum Beispiel mit nano .env) mit folgendem Inhalt. Die Kommentare hinter # erklären jede Zeile:

# Adresse, unter der die Cloud erreichbar ist (lokaler Netzwerkname)
OC_DOMAIN=opencloudpilot.local

# Erstes Administrator-Passwort. Nur beim allerersten Start wirksam.
# Spaeter nur ueber die Weboberflaeche aenderbar. Echtes Passwort einsetzen!
INITIAL_ADMIN_PASSWORD=<ADMIN_PASSWORT>

# Wohin die Daten und die Konfiguration geschrieben werden
OC_DATA_DIR=/opt/opencloud/data
OC_CONFIG_DIR=/opt/opencloud/config

# Selbstsigniertes Zertifikat erlauben (reiner Lokalbetrieb, kein oeffentliches Internet)
INSECURE=true

# Welche Bausteine gestartet werden: nur Datei-Cloud, ohne Office-Modul (schlank)
COMPOSE_FILE=docker-compose.yml:traefik/opencloud.yml

# Feste, getestete Version einfrieren (kein automatisches Wandern auf neue Versionen)
OC_DOCKER_IMAGE=opencloudeu/opencloud-rolling
OC_DOCKER_TAG=6.2.0

# Optionale Demo-Nutzer fuer Vorfuehrungen (alan, mary, margaret, dennis, lynn / Passwort: demo)
DEMO_USERS=true

Konfigurationsverzeichnis vorbereiten und Rechte setzen:

sudo mkdir -p /opt/opencloud/config
sudo chown -R 1000:1000 /opt/opencloud/config
sudo chown -R pilot:pilot /opt/opencloud-compose

Bewirkt: Legt das Konfigurationsverzeichnis an (ebenfalls Eigentümer 1000, wie die Daten) und übergibt die Compose-Steuerdateien dem Wartungsbenutzer (siehe Schritt 5).

OpenCloud starten:

docker compose up -d
docker compose ps

Bewirkt: Lädt die Container herunter und startet sie im Hintergrund. ps zeigt, ob die zwei Container (opencloud und traefik) laufen. Der erste Start dauert ein paar Minuten.

Zugriff testen: Rufe im Browser https://opencloudpilot.local auf. Weil ein selbstsigniertes Zertifikat verwendet wird, zeigt der Browser eine Sicherheitswarnung, die du im Lokalbetrieb bewusst bestätigst. Melde dich als Benutzer admin mit deinem <ADMIN_PASSWORT> an.

5. Absicherung (Härtung) des Zugangs

Dieser Abschnitt ist besonders für einen Dienstleister relevant, der das Gerät später verwaltet. Das Sicherheitsmodell ist bewusst einfach und streng:

Kein Passwort-Login über SSH. Zugang ausschließlich über kryptografische Schlüssel.
Nur zwei autorisierte Administrationsgeräte. Nur die hinterlegten Schlüssel dieser zwei Geräte kommen herein.
Nur im lokalen Netzwerk erreichbar. Das Gerät ist nicht aus dem Internet zugänglich (keine Portfreigabe, keine öffentliche Adresse).
Ein generischer Wartungsbenutzer (pilot) statt eines persönlichen Kontos.
Das ursprüngliche persönliche Konto ist stillgelegt.

Schritt 5.1 — Generischen Wartungsbenutzer anlegen

sudo adduser --gecos "" pilot
sudo usermod -aG sudo,docker pilot

Bewirkt: Legt den Benutzer pilot an und gibt ihm Administratorrechte (sudo) sowie das Recht, Docker zu bedienen. Beim Anlegen wird ein Passwort gesetzt, <PILOT_PASSWORT>, das nur lokal für sudo dient, nicht für SSH.

Schritt 5.2 — Öffentliche Schlüssel der zwei Admin-Geräte hinterlegen

Auf jedem der beiden Administrationsgeräte (zum Beispiel Arbeitslaptop und Notebook) brauchst du ein Schlüsselpaar. Falls noch keines existiert, erzeugst du es dort mit:

ssh-keygen -t ed25519 -C "<BESCHREIBUNG_GERAET>"

Bewirkt: Erstellt ein Schlüsselpaar. Der private Teil bleibt geheim auf dem Gerät, der öffentliche Teil (.pub) wird auf den Pilot kopiert.

Den öffentlichen Schlüssel jedes Geräts anzeigen und kopieren:

cat ~/.ssh/id_ed25519.pub

Auf dem Pilot die Schlüssel hinterlegen (beide Geräte eintragen):

sudo mkdir -p /home/pilot/.ssh
echo '<SSH_PUBKEY_GERAET_1>' | sudo tee /home/pilot/.ssh/authorized_keys
echo '<SSH_PUBKEY_GERAET_2>' | sudo tee -a /home/pilot/.ssh/authorized_keys
sudo chown -R 1001:1001 /home/pilot/.ssh
sudo chmod 700 /home/pilot/.ssh
sudo chmod 600 /home/pilot/.ssh/authorized_keys

Bewirkt: Trägt die öffentlichen Schlüssel beider Admin-Geräte ein (tee für den ersten, tee -a zum Anhängen des zweiten). Setzt anschließend die korrekten Eigentums- und Zugriffsrechte. 1001 ist die Benutzernummer von pilot; prüfe sie im Zweifel mit id pilot.

Wichtig: Erst weitermachen, wenn der Schlüssel-Login nachweislich funktioniert. Teste von beiden Geräten: ssh pilot@opencloudpilot.local muss ohne Passwortabfrage hereinlassen, und sudo whoami muss root ergeben. Lass während der Härtung sicherheitshalber eine bestehende Sitzung offen.

Schritt 5.3 — SSH absichern

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

Inhalt der Datei:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

Danach prüfen und neu laden:

sudo sshd -t
sudo systemctl restart ssh

Bewirkt: Schaltet den Passwort-Login über SSH ab, erlaubt nur noch Schlüssel und verbietet die direkte Anmeldung als root. sshd -t prüft die Konfiguration auf Fehler, bevor der Dienst neu startet (verhindert, dass man sich durch einen Tippfehler aussperrt). Der Neustart trennt bestehende Sitzungen, das ist normal, einfach neu verbinden.

Schritt 5.4 — Ursprüngliches persönliches Konto stilllegen

Angenommen, das beim Imager angelegte Erstkonto heißt <ERSTBENUTZER>:

sudo passwd -l <ERSTBENUTZER>
sudo usermod -s /usr/sbin/nologin <ERSTBENUTZER>

Bewirkt: Sperrt das Passwort des Erstkontos und entzieht ihm die Anmelde-Shell. Wichtig: Das beeinträchtigt OpenCloud nicht. Die Software läuft unter der numerischen Nummer 1000, unabhängig davon, welcher Benutzername diese Nummer trägt. Selbst wenn das Erstkonto zufällig die Nummer 1000 hatte, bleiben die Datenverzeichnisse (Eigentümer 1000) zugreifbar. Verändere die Eigentümerschaft der Datenverzeichnisse niemals weg von 1000.

Schritt 5.5 — Notfall: Wieder hereinkommen, wenn der Schlüssel fehlt

Falls einmal kein autorisiertes Gerät mehr Zugang hat, ist das Gerät trotzdem nicht verloren, weil die Hardware physisch greifbar ist:

Pilot stromlos machen (Netzwerk-/Stromkabel ziehen).
Die System-NVMe aus dem HAT nehmen und über einen USB-Adapter an einen anderen Rechner (Linux) hängen.
Die System-Partition einhängen und einen gültigen öffentlichen Schlüssel in /home/pilot/.ssh/authorized_keys ergänzen, dann die Rechte wie in Schritt 5.2 setzen.
NVMe zurückbauen, starten, Zugang testen.

Das ist der praktische Beweis von Souveränität: Es gibt kein Support-Ticket, aber auch keine verschlossene Tür. Wem die Hardware gehört, der kommt immer wieder herein.

6. Feldsicherheit und Versions-Stabilität

Ein Gerät, das beim Kunden steht, soll verlässlich laufen und sich nicht unbemerkt verändern.

Feste Version: In der .env ist OC_DOCKER_TAG=6.2.0 gesetzt. Dadurch bleibt die getestete Version eingefroren und wandert nicht ungewollt auf eine neue. Updates macht man bewusst und kontrolliert, nie automatisch im Feld.
Automatischer Neustart: Die Container sind im Compose-Paket auf restart: always gesetzt. Nach Stromausfall, Transport oder Neustart kommen sie von selbst wieder hoch.
Kein Auto-Updater: Es läuft bewusst kein Dienst, der im Hintergrund neue Versionen zieht. Prüfen kann man das mit docker ps -a | grep -i watchtower (sollte leer sein) und crontab -l (kein Update-Job).
Optionale Sicherheitsupdates des Betriebssystems: Wer will, kann automatische Sicherheits-Updates (nicht Funktionsupdates) für das Host-System aktivieren (unattended-upgrades, nur Security). Das ist optional.

7. Betrieb und Wartung (für den verwaltenden Dienstleister)

Wo liegt was:

Steuerung/Compose und .env: /opt/opencloud-compose
Daten der Cloud: /opt/opencloud/data (auf der Daten-SSD)
Konfiguration: /opt/opencloud/config

Status ansehen:

cd /opt/opencloud-compose
docker compose ps
df -h /opt/opencloud/data

Logs ansehen:

cd /opt/opencloud-compose
docker compose logs --tail=100 opencloud

Dienst neu starten:

cd /opt/opencloud-compose
docker compose restart

Einen weiteren Admin-Schlüssel hinzufügen (zum Beispiel ein Gerät des Dienstleisters), angemeldet als pilot:

echo '<NEUER_PUBKEY>' >> ~/.ssh/authorized_keys

Bewirkt: Hängt einen weiteren autorisierten Schlüssel an (doppeltes >>, damit die bestehenden erhalten bleiben).

Einen Schlüssel entfernen (Rotation): Datei ~/.ssh/authorized_keys öffnen und die betreffende Zeile löschen.

Sicherung (Backup): Die Daten liegen unter /opt/opencloud/data. Ein einfaches, konsistentes Backup ist eine regelmäßige Replikation dieses Verzeichnisses auf ein zweites Gerät (zum Beispiel per rsync oder, bei einem ZFS-Ziel, per Snapshot-Replikation). Backup ist nicht Redundanz: Ein Backup schützt vor Datenverlust, nicht vor Ausfallzeit.

8. Bekannte Grenzen (ehrlich benannt)

Ein einzelnes Datenlaufwerk, kein RAID. Stirbt die SSD, sind die Daten ohne Backup verloren. Für Dauerbetrieb deshalb immer ein Backup einrichten.
Kein SMB/NFS. OpenCloud bietet Sync und Share, keine klassischen Netzlaufwerke. WebDAV ist möglich, ersetzt aber nicht das native Windows-Laufwerk-Erlebnis.
Nutzerzahl. Als registrierte Mitglieder sind mehrere Dutzend bis etwa hundert unkritisch. Der eigentliche Engpass ist die Gleichzeitigkeit, also wie viele Personen zur selben Zeit aktiv synchronisieren. Für eine typische Community ist das unkritisch, für Dauervolllast vieler paralleler Nutzer ist es das falsche Gerät.
Keine Hochverfügbarkeit. Ein einzelnes Gerät ist ein einzelner Ausfallpunkt. Echte Ausfallsicherheit braucht mehrere Knoten und replizierten Speicher, das ist die nächste Ausbaustufe, nicht dieses Kit.
Stromausfall. Optional lässt sich eine USV (unterbrechungsfreie Stromversorgung) ergänzen, die bei Stromausfall einen sauberen Shutdown auslöst und so die dateisystembasierten Metadaten schützt. Das verändert allerdings den mechanischen Aufbau und ist eine eigene Ausbauvariante.
Lokalbetrieb. Das Gerät ist für den Einsatz im lokalen Netz ausgelegt (opencloudpilot.local, selbstsigniertes Zertifikat). Ein Betrieb über das öffentliche Internet würde einen vorgelagerten Reverse Proxy mit gültigen Zertifikaten und eine bewusste Sicherheitsbetrachtung erfordern und ist hier nicht abgedeckt.

9. Übersicht aller Platzhalter

Platzhalter	Bedeutung	Wo gesetzt
`<ADMIN_PASSWORT>`	Erstes Administrator-Passwort für die Weboberfläche	`.env`, Schritt 4.6
`<DEMO_PASSWORT>`	Gemeinsames Passwort für vorzeigbare Demo-Nutzer	Weboberfläche, Schritt 10
`<PILOT_PASSWORT>`	Lokales `sudo`-Passwort des Wartungsbenutzers	Schritt 5.1
`<SSH_PUBKEY_GERAET_1>` / `<...2>`	Öffentliche SSH-Schlüssel der zwei Admin-Geräte	Schritt 5.2
`<DEINE_UUID>`	Eindeutige Kennung der Daten-SSD (aus `blkid`)	fstab, Schritt 4.4
`<ERSTBENUTZER>`	Name des beim Imager angelegten Erstkontos	Schritt 5.4

10. Anhang: Demo-Nutzer für Vorführungen

Für Vorführungen lassen sich benannte Nutzer über die Weboberfläche anlegen (Admin-Bereich, Users, „New user"). Verwende dabei ein gemeinsames, vorzeigbares Demo-Passwort <DEMO_PASSWORT> (nicht das Admin-Passwort), keine erzwungene Passwortänderung beim ersten Login, und plausible Demo-Mailadressen unter einer Domain, die dir gehört.

Datenschutz: Wenn echte Personen als Demo-Nutzer auftauchen, hole vorher ihr Einverständnis ein, oder mache die Namen in veröffentlichten Screenshots unkenntlich. Souveränität bedeutet auch, die Daten anderer zu schützen.

One device. One responsibility. One less excuse.

Pandolin — pandolin.io. Lizenziert unter EUPL-1.2.