OPENBUREAU/content/library/software/proxmox-schritt-fuer-schritt.md

title, date, tags, summary, color, layout

title	date	tags	summary	color	layout
Proxmox, Schritt für Schritt	2026-06-02	software proxmox self-hosting anleitung lxc	Wie aus einer gebrauchten Kiste die Infrastruktur eines Architekturbüros wird — mit den Skripten, die einen Dienst in Minuten aufstellen.	kusa	text

Die Kiste aus dem ersten Teil muss man nicht streicheln können, um sie zu verstehen. Es genügt ein Bild: Proxmox macht aus einem Rechner ein Mehrfamilienhaus. Das Haus ist die Maschine, die Wohnungen sind die Container, und in jeder Wohnung lebt genau ein Dienst — die Website, die Zeiterfassung, der Dateispeicher. Niemand stört den anderen, jeder hat seine eigene Tür, und zieht eine Partei aus, bleiben die übrigen, wo sie sind.

Dieser Text zeigt, wie man das Haus baut und die erste Wohnung bezieht. Er setzt keine Erfahrung mit Servern voraus, nur die Bereitschaft, einen Befehl abzutippen und zu lesen, was er antwortet.

Das Fundament

Proxmox VE ist im Kern ein Debian-Linux mit einer Weboberfläche und der Fähigkeit, zweierlei Sorten Wohnungen zu vermieten: vollwertige virtuelle Maschinen und — das ist unser Fall — Linux-Container, sogenannte LXC. Ein Container teilt sich den Kern des Wirts und ist deshalb sparsam: Vier Gigabyte Arbeitsspeicher reichen für einen ausgewachsenen Dienst, ein Dutzend davon laufen auf gewöhnlicher Bürohardware.

Installiert wird Proxmox einmalig vom USB-Stick, so wie man ein Betriebssystem installiert. Das ist gut dokumentiert und hier nicht das Thema. Ab dem Moment, in dem die Weboberfläche unter https://<ip>:8006 erscheint, beginnt der interessante Teil.

Das Muster: ein Container, ein Dienst, ein Befehl

Wir richten keinen Dienst von Hand ein. Jeder Handgriff, den man zweimal macht, gehört in ein Skript — schon weil man ihn sonst beim Wiederaufsetzen vergisst. Unser Muster, von Dienst zu Dienst gleich, lautet:

1. einen unprivilegierten LXC anlegen (er darf weniger, also kann weniger schiefgehen),
2. ihn so einstellen, dass Docker darin läuft (nesting und keyctl),
3. den Dienst als Docker-Compose-Stack hineinstellen,
4. alle Geheimnisse automatisch erzeugen lassen, nichts von Hand eintippen,
5. ein Backup einrichten, bevor überhaupt Daten da sind.

Das ist die ganze Liturgie. Wer sie einmal in ein Skript gegossen hat, stellt den nächsten Dienst hin, indem er das Skript ruft.

Die erste Wohnung: unser CMS

Diese Website ist das Musterbeispiel. Ein einziger Befehl, abgesetzt auf dem Proxmox-Wirt als root, baut den ganzen Container — Docker, das Repository, sämtliche Schlüssel, der laufende Stack:

bash <(curl -fsSL https://git.kgva.ch/karim/OPENBUREAU/raw/branch/main/cms/proxmox/create-openbureau-lxc.sh)

Das Skript fragt nur nach Speicherort, Netzwerkbrücke und IP — Enter übernimmt je den Vorschlag — und ist nach wenigen Minuten fertig. Am Ende nennt es die Adressen: den Editor unter …:8080/admin/, die Website unter …:8080/.

Spannend ist nicht der Einzeiler, sondern was er tut. Das vollständige Skript liest sich von oben nach unten wie ein Protokoll. Den Container anlegen, mit den zwei Schaltern, die Docker erlauben:

pct create "$CTID" "$TEMPLATE_REF" \
  --hostname openbureau \
  --cores 2 --memory 4096 --swap 1024 \
  --rootfs "local-lvm:20" \
  --net0 "name=eth0,bridge=vmbr0,ip=dhcp" \
  --unprivileged 1 \
  --features "nesting=1,keyctl=1" \
  --onboot 1

Dann, im Container, Docker installieren, das Repository ziehen und — der Teil, der einem die durchwachte Nacht erspart — die Geheimnisse erzeugen, statt sie von Hand zu setzen:

curl -fsSL https://get.docker.com | sh
systemctl enable --now docker
git clone https://git.kgva.ch/karim/OPENBUREAU.git /opt/openbureau

cd /opt/openbureau/cms
cp .env.example .env
sed -i "s|^POSTGRES_PASSWORD=.*|POSTGRES_PASSWORD=$(openssl rand -hex 32)|" .env
sed -i "s|^JWT_SECRET=.*|JWT_SECRET=$(openssl rand -hex 32)|"             .env
docker compose up -d --build

Und schliesslich, noch bevor der erste Beitrag geschrieben ist, das tägliche Backup — denn das Forum lebt allein in der Datenbank, nicht im Git:

printf '15 3 * * * root cd /opt/openbureau/cms && bash scripts/backup-db.sh\n' \
  > /etc/cron.d/openbureau-backup

Kein Schritt davon ist klug; jeder ist nur aufgeschrieben. Das ist der ganze Trick.

Ein Menü statt Handarbeit

Weil das Muster sich von Dienst zu Dienst wiederholt, haben wir es ein einziges Mal in ein Installationsskript gegossen. Es ruft sich genauso wie das CMS-Skript — ein Einzeiler auf dem Proxmox-Wirt, als root —, nur legt es kein bestimmtes Programm fest, sondern fragt, was man haben will:

bash <(curl -fsSL https://git.kgva.ch/karim/OPENBUREAU/raw/branch/main/proxmox/install.sh)

Zuerst fragt es nicht nach Technik, sondern nach dem Vorhaben: ein ganzes Büro einrichten, bloss Office 365 und die Synology ersetzen, nur die öffentliche Website — oder, für jene, die genau wissen, was sie wollen, einzeln auswählen. Aus der Antwort leitet das Skript ab, welche Container es braucht, und baut sie der Reihe nach. Jeder bekommt seine eigene Wohnung; für jede erledigt das Skript dasselbe, was oben Schritt für Schritt stand: Template holen, unprivilegierten Container anlegen, Docker hineinlegen, den Dienst starten.

Wer das Menü überspringen will, hängt den gewünschten Dienst direkt an:

… install.sh nextcloud                      # nur Nextcloud
… install.sh empty dateien 200 8192         # leerer Docker-LXC, 200 GB / 8 GB RAM
… install.sh git git.kgva.ch/karim/RAPPORT-SERVER.git rapport

Hinter dem Menü steckt keine grosse Maschine, sondern ein Bündel kleiner, eigenständiger Skripte — eines pro Dienst. Die Suite ist nur der Dialog, der sie der Reihe nach aufruft. Wer das Menü gar nicht braucht, lädt das einzelne Skript direkt:

bash <(curl -fsSL …/proxmox/nextcloud-lxc.sh)        # 500 GB / 8 GB RAM
bash <(curl -fsSL …/proxmox/empty-lxc.sh) dateien 200 8192
bash <(curl -fsSL …/proxmox/git-compose-lxc.sh) git.kgva.ch/karim/RAPPORT-SERVER.git rapport

Jedes dieser Skripte ist in sich geschlossen und tut, was oben Schritt für Schritt stand: Template holen, unprivilegierten Container anlegen, Docker hineinlegen, den Dienst starten. Genau diese Wiederholbarkeit ist der Sinn der Übung — ein Dienst, den man nicht mit einem Befehl neu aufsetzen kann, ist ein Dienst, vor dem man sich beim nächsten Mal fürchtet.

Office 365 und die Synology ersetzen: Nextcloud

Der grösste Brocken verdient einen eigenen Blick, weil er am meisten ersetzt. Nextcloud übernimmt in einem Aufwasch, wofür sonst zwei Abos und eine NAS herhalten: die Dateiablage mit Synchronisation auf alle Geräte — das OneDrive- und Synology-Drive-Erbe —, gemeinsame Kalender und Kontakte, dazu über das eingebaute Office das Bearbeiten von Dokumenten und Tabellen im Browser, zu zweit am selben Text.

Im Menü ist es ein Haken, von Hand der Befehl oben. Was dann läuft, ist die offizielle All-in-One-Variante: ein verwalteter Container, der die übrigen selbst aufsetzt. Den Rest erledigt die Weboberfläche unter Port 8080 — sie vergibt das Admin-Passwort, fragt die Domain ab und startet die eigentlichen Dienste. Ohne eigene Domain erreicht man das Ganze vorerst im lokalen Netz; für den Zugriff von aussen kommt später ein Reverse-Proxy davor, dasselbe Prinzip, das auch unser CMS hinter TLS bringt.

Damit ist die Rechnung geschlossen: Mail, Kalender, Kontakte, Dateien, gemeinsame Dokumente — alles, wofür das Büro bisher Monat für Monat pro Kopf bezahlt hat, läuft im Schrank. Und unsere eigenen Werkzeuge, RAPPORT und DOSSIER, ziehen über denselben Git-Eintrag im Menü nach, weil sie demselben Muster folgen wie alles andere.

Das Backup ist kein Anhang

Ein Satz zum Schluss, der eigentlich an den Anfang gehört. Selbst zu hosten heisst, selbst für die Sicherung geradezustehen. Zweierlei greift bei uns ineinander. Innerhalb jedes Dienstes sichert ein nächtlicher cron-Lauf die Datenbank weg — bei dieser Website das Forum, bei Nextcloud die Metadaten. Und für die Container als Ganzes nimmt der Proxmox Backup Server allabendlich einen Schnappschuss, aus dem sich eine ganze Wohnung in Minuten wiederherstellen lässt, sollte sie einmal abbrennen.

Ein Backup, das man nie zurückgespielt hat, ist eine Hoffnung, kein Backup. Darum gehört der erste Wiederherstellungs-Versuch an den Tag, an dem der Dienst aufgesetzt wird — nicht an den Tag, an dem man ihn braucht.