# openDesk – O365-Alternative v0.3 ## Ausgangsfrage Suche nach einer Open-Source-Alternative zu Microsoft O365. openDesk (BMI/Bundesverwaltung) als Kandidat identifiziert. ## Ergebnis dieser Session Hardware-Anforderungen aus `docs/requirements.md` des openDesk-Deployment-Repos (Stand: Commit vom 10.06.2026, ci: Update deployment tooling to support Helm 4.x) ausgelesen. ### Hardware (Minimum für Evaluierungs-Deployment) | Spec | Wert | |---|---| | CPU | 12 Cores x64/x86 (ARM nicht unterstützt) | | RAM | 32 GB (mehr empfohlen) | | Disk | HDD oder SSD, >10 GB | Hinweis: Das sind reine Minimalwerte für eine Testinstanz. Für Produktivbetrieb wird mehr empfohlen (laut Doku). ### Weitere Voraussetzungen (nicht Hardware, aber relevant) - Kubernetes-Cluster ≥ v1.24, CNCF-zertifizierte Distribution (openDesk ist Kubernetes-only) - Ingress-Controller: haproxy-ingress.github.io (aktuell empfohlen) oder Ingress-nginx (deprecated) - Deployment-Tools: Helm ≥ v3.17.3 (nicht v3.18.0/v3.20.1), Helmfile ≥ v1.0.0, Helm Diff ≥ v3.11.0, yq ≥ v4.52.4 - Volume-Provisioner mit RWO-Unterstützung (teils RWX für verteilte Komponenten) - cert-manager für Zertifikatsverwaltung - Domain + DNS-Service - Zusatz Enterprise Edition: OpenKruise ≥ v1.6 ## Testinstallation (2 User, kein bestehender K8s-Cluster) – Vorgehen 1. Server/VM bereitstellen: ≥12 Cores, ≥32 GB RAM, >10 GB Disk (Minimalwerte gelten unabhängig von Nutzerzahl). 2. Single-Node Kubernetes installieren (z. B. k3s oder kubeadm, v1.24+). 3. Domain + DNS: Wildcard-Record `*.domain.tld` → Server-IP. 4. Ingress-Controller installieren: haproxy-ingress (`ingressClassName: haproxy`). 5. Volume-Provisioner (RWO; Achtung: local-path-provisioner hat kein Sticky-Bit-Support, ggf. Alternative nötig) + cert-manager installieren. 6. Deployment-Tools installieren: Helm ≥3.17.3 (nicht 3.18.0/3.20.1), Helmfile ≥1.0.0, Helm Diff ≥3.11.0, yq ≥4.52.4. 7. Repo `bmi/opendesk/deployment/opendesk` klonen, eigene `.yaml.gotmpl`-Datei in `helmfile/environments/dev/` ablegen (Vorlage: `sample.yaml.gotmpl` NICHT verändern) – siehe Config-Entwurf unten. 8. `MASTER_PASSWORD` setzen (Pflichtvariable, kein Default). 9. Deployment starten: `helmfile apply -e dev -n <NAMESPACE>`, warten bis Pods `Running`/`Succeeded`. 10. Login unter `https://domain.tld` → Redirect zu Portal. Admin-Passwort per `kubectl get secret ums-nubus-credentials ...` holen. 11. 2 Nutzerkonten anlegen: manuell im Admin-Bereich oder via User-Importer-Script (ODS-Template). Optional: nicht benötigte Apps (z. B. Jitsi, ClamAV distributed) in `opendesk_main.yaml.gotmpl` deaktivieren, um Ressourcen zu sparen – ändert aber nichts an den 12-Cores/32-GB-Minimum. ## Bestätigte Entscheidungen (v0.3) - Domain: `odtest.local` (rein interner Test, keine öffentliche DNS-Auflösung nötig) - Zertifikate: self-signed (`certificate.selfSigned: true`), kein Let's Encrypt – cert-manager muss trotzdem installiert sein (erzeugt intern das Zertifikat) - Jitsi deaktiviert (`apps.jitsi.enabled: false`) – Ressourcenersparnis für 2-User-Test - ClamAV Distributed ist bereits standardmäßig deaktiviert, keine Änderung nötig - Vorgeschlagener Namespace: `opendesk-test` (frei wählbar) ## Config-Entwurf Datei liegt hier: `20 Software/openDesk-Test/odtest.yaml.gotmpl` Enthält: `global.domain`, `cluster.service.type: NodePort`, `persistence.storageClassNames.RWO` (Platzhalter `local-path`, an eigenen Provisioner anpassen), `ingress.ingressClassName: haproxy`, `certificate.selfSigned: true`, `apps.jitsi.enabled: false`. `MASTER_PASSWORD` bewusst NICHT in der Datei – wird als Umgebungsvariable gesetzt. Reale Subdomains (aus `helmfile/environments/default/global.yaml.gotmpl`, unverändert übernommen): `id.` (Keycloak/Login), `portal.` (Nubus/Startseite), `files.` (Nextcloud), `office.` (Collabora), `pad.` (CryptPad), `chat.` (Element), `webmail.`/`dav.` (OX App Suite), `projects.` (OpenProject), `wiki.` (XWiki), `meet.` (Jitsi – deaktiviert), `objectstore.`/`objectstore-ui.` (MinIO/SeaweedFS). ## Aufteilung Cowork / Claude Code - Hier (Cowork): Recherche, Planung, Doku, Config-Entwürfe (kein Zugriff auf Proxmox/Netzwerk). - Claude Code (lokal/auf oder nahe Proxmox-Host): VM anlegen, k3s installieren, `helmfile apply`, Live-Debugging. ## Offene Punkte - Wahl der Single-Node-K8s-Distribution (k3s vs. kubeadm) noch offen - Tatsächlicher RWO-StorageClass-Name je nach gewähltem Provisioner noch anzupassen - Vergleich openDesk vs. andere O365-Alternativen (z. B. Nextcloud Hub, ownCloud Infinite Scale) noch nicht durchgeführt - Lizenz-/Support-Modell (Community vs. Enterprise Edition) noch nicht geprüft ## Nächste Schritte 1. Server/VM für Test bereitstellen. 2. Single-Node K8s installieren (Entscheidung k3s/kubeadm treffen). 3. Config-Entwurf (`odtest.yaml.gotmpl`) nach `helmfile/environments/dev/` kopieren, StorageClass anpassen. 4. Schritte 3–11 aus obigem Vorgehen abarbeiten (per Claude Code auf/nahe dem Proxmox-Host). ## Quellen - https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/-/blob/main/docs/getting-started.md - https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk/-/blob/main/docs/requirements.md