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

Die Kiste aus dem [ersten Teil](/archiv/software/server-im-eigenen-haus/) 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
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](https://git.kgva.ch/karim/OPENBUREAU/src/branch/main/cms/proxmox/create-openbureau-lxc.sh) liest sich von oben nach unten wie ein Protokoll. Den Container anlegen, mit den zwei Schaltern, die Docker erlauben:

```bash
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:

```bash
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:

```bash
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
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:

```bash
… 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
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](https://nextcloud.com) ü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.
