# OPENBUREAU — Proxmox-Selbsthosting-Set Skripte, um die Dienste eines Architekturbüros auf einem Proxmox-VE-Host aufzusetzen — jeder Dienst in seinem eigenen, unprivilegierten, Docker-tauglichen LXC. Alle Skripte werden **auf dem Proxmox-Host als `root`** ausgeführt. ## Zwei Wege **1. Suite mit Dialog** — fragt, was man will, und installiert einen LXC nach dem anderen: ```bash bash <(curl -fsSL https://git.kgva.ch/karim/OPENBUREAU/raw/branch/main/proxmox/install.sh) ``` **2. Einzelskripte** (für Fortgeschrittene) — direkt, ohne Menü. Jedes ist in sich geschlossen: ```bash # Website + CMS (eigenes Skript, erzeugt alle Supabase-Secrets) bash <(curl -fsSL …/cms/proxmox/create-openbureau-lxc.sh) # Nextcloud (Dateien/Kalender/Kontakte/Office — ersetzt 365 + Synology) bash <(curl -fsSL …/proxmox/nextcloud-lxc.sh) [disk_gb] [ram_mb] # Leerer Docker-LXC als Gerüst bash <(curl -fsSL …/proxmox/empty-lxc.sh) [name] [disk_gb] [ram_mb] # Beliebiger Dienst aus einem Git-Repo mit docker-compose (RAPPORT, DOSSIER …) bash <(curl -fsSL …/proxmox/git-compose-lxc.sh) [name] [disk_gb] [ram_mb] ``` `install.sh` akzeptiert dieselben Dienste auch direkt als Argument (`install.sh nextcloud`, `install.sh git …`). ## Gemeinsames Muster Jedes Skript macht dasselbe: aktuelles Debian-12-Template sicherstellen, unprivilegierten LXC mit `nesting=1,keyctl=1` anlegen (damit Docker darin läuft), Docker installieren, den Dienst als Container/Compose-Stack starten. Storage, Netz und SSH-Key lassen sich per Umgebungsvariable überschreiben: | Variable | Default | |--------------------|--------------------------| | `ROOTFS_STORAGE` | `local-lvm` | | `TEMPLATE_STORAGE` | `local` | | `BRIDGE` | `vmbr0` | | `SSH_PUBKEY_FILE` | `~/.ssh/id_ed25519.pub` | ## Domain & HTTPS hinter einem Reverse-Proxy Für eine öffentliche Adresse (statt LAN-IP:Port) kennt `cms/proxmox/create-openbureau-lxc.sh` die Variable **`SITE_DOMAIN`**. Ist sie gesetzt, werden `SITE_URL` und `API_EXTERNAL_URL` auf `https://` gelegt (Same-Origin) — der Browser ruft `/auth/*` + `/rest/*` auf derselben Domain auf, der Reverse-Proxy routet sie ans Supabase-Gateway (`:8000`), alles andere an die Site (`:8080`). `BIND_ADDR` bleibt `0.0.0.0`, damit der Proxy drankommt. So wurde **dev.openbureau.ch** aufgesetzt (LXC auf einem ZFS-Host, statische IP): ```bash ROOTFS_STORAGE=local-zfs HOSTNAME=openbureau-dev CTID=134 \ IP=192.168.1.134/24 GATEWAY=192.168.1.1 SITE_DOMAIN=dev.openbureau.ch \ bash <(curl -fsSL https://git.kgva.ch/karim/OPENBUREAU/raw/branch/main/cms/proxmox/create-openbureau-lxc.sh) ``` Den passenden Reverse-Proxy-Eintrag gibt das Skript am Ende selbst aus. Für **Caddy** (Pfad-Routing, ein Zertifikat): ```caddy dev.openbureau.ch { # Nur /auth/* muss public ans Supabase-Gateway (Browser-Login). Alle Daten # laufen über /api/* (Node spricht kong intern an). /rest, /storage, # /realtime bewusst NICHT exponieren — sonst gibt /rest/v1/ die ganze # DB-Schema-Beschreibung preis (PostgREST-OpenAPI). @auth path /auth/* reverse_proxy @auth 192.168.1.134:8000 reverse_proxy 192.168.1.134:8080 } ``` Den Caddy-Block in die jeweilige Proxy-Config eintragen, validieren und neu laden (`caddy reload`). Caddy holt das Let's-Encrypt-Zertifikat beim ersten Aufruf selbst. Login-User danach über die Admin-API anlegen (Self-Signup ist aus): ```bash pct enter ; cd /opt/openbureau/cms; source .env curl -s -X POST "http://localhost:8000/auth/v1/admin/users" \ -H "apikey: $SERVICE_ROLE_KEY" -H "Authorization: Bearer $SERVICE_ROLE_KEY" \ -H "Content-Type: application/json" \ -d '{"email":"du@example.ch","password":"…","email_confirm":true}' ``` ## Hintergrund Warum und wie — die zwei Artikel in der Bibliothek: [Server im eigenen Haus](https://openbureau.ch/library/software/server-im-eigenen-haus/) und [Proxmox, Schritt für Schritt](https://openbureau.ch/library/software/proxmox-schritt-fuer-schritt/).