grommunio 2026.06.1 installieren: Vom ISO zur lauffähigen Groupware

grommunio 2026.06.1 installieren: vom ISO zur nutzbaren Groupware

Der Beitrag wurde mit grommunio 2026.06.1 auf einer isolierten KVM-Installation praktisch nachvollzogen und führt dich von einer leeren VM bis zu einem nutzbaren Basissystem mit Admin UI, grommunio Web, Organisation, Domain, Benutzer, Mailbox, Alias, TLS-Grundlage und lokaler Testmail. Grundlage sind die offiziellen grommunio Release Notes, die Quickstart-Anleitung und die Guided Installation.

Die Beispielwerte bleiben synthetisch: Server-FQDN mail.example.test, Maildomain example.test und Benutzer alex@example.test. Für Produktion ersetzt du sie durch echte Namen, öffentliche DNS-Zonen und eine erreichbare IP-Adresse.

Was ist grommunio 2026.06.1?

grommunio 2026.06.1 ist ein Major Release der Groupware-Plattform. Für die Appliance ist besonders wichtig: Die geführte Installation basiert auf openSUSE Leap 16.0 beziehungsweise der SLES-16-Plattformfamilie, und die Appliance verwendet systemd-networkd für die Netzwerkkonfiguration. Dadurch fühlt sich die Basis moderner und näher an aktuellen Enterprise-Linux-Komponenten an.

Was wir bauen

Wir bauen eine grommunio-Core-Installation auf der neuen openSUSE-Leap-16-basierten Appliance. Core deckt Mail und Groupware, Admin API, Admin Web, grommunio Web, Postfix, gromox-Dienste, MariaDB, Redis und die Antispam-Basis ab. Keycloak, Meet, Chat, Files, Archive, Backup/DR und Monitoring werden nur eingeordnet und gehören in eigene Folgebeiträge.

• Appliance laden und ISO prüfen.

• VM mit Systemdisk und optionaler Datendisk vorbereiten.

• Installer booten, Zielplatte wählen, Installation bestätigen und von Disk starten.

• CUI nutzen, Root-Passwort setzen, Hostname, Netzwerk, DNS und Zeit prüfen.

• grommunio-setup vollständig durchlaufen.

• Organisation, Domain, Benutzer, Mailbox, Alias und Quota-Grundlagen verstehen.

• Admin UI, grommunio Web, lokale Zustellung, Queue, Logs, TLS und DNS-Basics prüfen.

Architektur, Namen und DNS-Konzept

Lege Namen und DNS fest, bevor du installierst. So vermeidest du spätere Zertifikats-, Autodiscover- und Zustellprobleme.

Server-FQDN: mail.example.com
Maildomain:   example.com
User:         alice@example.com

• `mail.example.com` ist der Hostname/FQDN des Servers.

• `example.com` ist die Maildomain, für die Postfächer angelegt werden.

• `alice@example.com` ist eine konkrete Benutzeradresse.

• Der Server-FQDN gehört in Zertifikate, PTR, HELO/EHLO und die Hostkonfiguration.

• Die Maildomain gehört in MX, SPF, DKIM, DMARC, Domains und Benutzeradressen.

Appliance herunterladen und prüfen

Lade die Installations-ISO aus der offiziellen grommunio-Quelle und prüfe die bereitgestellte Prüfsumme, bevor du sie bootest. Ein beschädigtes oder falsches Image führt später zu schwer nachvollziehbaren Installer- und Repository-Fehlern.

sha256sum grommunio.x86_64-2026.06.1-Build5.7.install.iso

# Erwartet: Die berechnete Prüfsumme entspricht der veröffentlichten SHA256-Summe.
# Wenn sie nicht passt: ISO löschen, erneut laden und nicht installieren.

Screenshot: Das Boot-Menü der geprüften grommunio-2026.06.1-Installations-ISO.

Voraussetzungen und Dimensionierung

Die Hersteller-Mindestanforderung für die Appliance liegt bei 4 CPU-Cores, 6 GB RAM und 32 GB Systemdisk. Im praktischen Test wurden 4 vCPU, 8 GB RAM, eine 64-GB-Systemdisk und eine zusätzliche 128-GB-Datendisk verwendet. Die Datendisk wurde in der Basisinstallation noch nicht produktiv eingebunden; sie zeigt nur, wie du Maildaten später getrennt planen kannst.

• CPU/RAM: ausreichend für Setup, Webzugriff und erste Tests; produktive Größen hängen von Benutzerzahl, Mailvolumen, Suche, Retention und Zusatzrollen ab.

• Systemdisk: Betriebssystem, Pakete, Basiskonfiguration und Logs.

• Wachsende Datenbereiche: Mailbox-Daten, MariaDB, Such-/Indexdaten, Logs, spätere Archive/Files.

• Netzwerk: feste IP für Produktion, funktionierender Gateway, DNS-Resolver und erreichbare Paket-Repositories.

• DNS: FQDN, MX, PTR, Autodiscover, SPF, DKIM und DMARC vor dem Go-live planen.

VM erstellen

Das folgende Beispiel zeigt eine bereinigte KVM/QEMU-Basis ohne interne Pfade. Für libvirt oder Proxmox überträgst du dieselben Prinzipien: virtio-Disks, virtio-Netzwerk, genug RAM, CPU-Host-Passthrough wo sinnvoll und Boot von der ISO.

qemu-img create -f qcow2 grommunio-system.qcow2 64G
qemu-img create -f qcow2 grommunio-data.qcow2 128G

qemu-system-x86_64 \
  -machine q35 \
  -m 8192 \
  -smp 4 \
  -enable-kvm \
  -cpu host \
  -drive file=grommunio-system.qcow2,if=virtio,format=qcow2 \
  -drive file=grommunio-data.qcow2,if=virtio,format=qcow2 \
  -cdrom grommunio.x86_64-2026.06.1-Build5.7.install.iso \
  -boot d \
  -device virtio-net-pci,netdev=net0 \
  -netdev user,id=net0,hostfwd=tcp:127.0.0.1:8443-:8443,hostfwd=tcp:127.0.0.1:443-:443

Für eine öffentlich erreichbare Installation verwendest du kein QEMU-User-NAT, sondern eine echte Bridge, VLAN-Anbindung oder Hypervisor-Netzwerkkarte mit routbarer Adresse.

Storage und Datenpfade verstehen

Die geprüfte Appliance legt eine kleine EFI-Partition und ein XFS-Root-Dateisystem an. Die zusätzliche Datendisk bleibt ohne manuelle Einbindung ungenutzt. Prüfe deshalb direkt nach dem ersten Boot, wo das System wirklich schreibt.

lsblk -f
findmnt -R / /boot /boot/efi
df -hT
du -sh /var/lib/gromox /var/lib/mysql /var/log 2>/dev/null

Beobachtetes Basisschema:

/dev/vda2  vfat  /boot/efi
/dev/vda3  xfs   /
/dev/vdb         zusätzliche Disk, nicht automatisch eingebunden

• Kleine Installation: Eine ausreichend große Systemdisk kann für einen ersten produktionsnahen Single-Server reichen, wenn Benutzerzahl, Mailvolumen, Retention und Backup-Konzept überschaubar sind.

• Produktive Installation: Plane Mailstore, Datenbank, Logs, Such-/Indexdaten und spätere Archive/Files getrennt, wenn Wachstum, Backupfenster, Restore-Zeit oder I/O-Last relevant werden.

• Ändere Mountpoints nicht blind nachträglich. Prüfe zuerst grommunio-Datenpfade, Service-Abhängigkeiten, Backup/Restore und Wartungsfenster.

Appliance installieren

Boote die VM vom ISO, wähle die Installationsoption und danach die Zielplatte. Die Installation löscht die gewählte Disk vollständig. Kontrolliere deshalb Disk-Größe und Gerätenamen, bevor du bestätigst.

Screenshot: Zielplatte für die Appliance-Installation auswählen.

Screenshot: Die Datenlöschung muss bewusst bestätigt werden.

Screenshot: Das Appliance-Image wird auf die Systemdisk geschrieben.

Nach dem Schreibvorgang beendest du den Installer, entfernst das ISO aus dem virtuellen Laufwerk und bootest von der installierten Systemdisk. Wenn das ISO eingelegt bleibt, landet die VM sonst erneut im Installer.

Erster Start in der CUI

Der erste Start führt in die grommunio Console User Interface. Setze zuerst das Root-Passwort. Danach prüfst du Hostname, Netzwerk, Gateway, DNS und Zeit, bevor du den Setup-Assistenten startest.

Screenshot: Erster CUI-Start: Das Setup ist noch nicht ausgeführt.

Screenshot: Root-Passwort in der CUI setzen.

Screenshot: CUI-Übersicht mit Host-, Netzwerk- und Setup-Status.

hostnamectl hostname mail.example.test
hostname -f
ip address show
ip route
dig A download.grommunio.com
timedatectl

Netzwerk vollständig konfigurieren

Die 2026.06.1-Appliance verwendet systemd-networkd. Identifiziere zuerst das echte Interface, prüfe ob DHCP aktiv ist, stelle dann auf eine persistente statische Adresse um und teste den Zustand vor und nach einem Reboot.

systemctl status systemd-networkd
networkctl list
ip -br link
ip -br addr
ip route

Das Interface erkennst du an `UP`, Typ `ether`, der erwarteten MAC-Adresse und der Adresse aus deinem Netz. Namen wie `enp0s2`, `ens3` oder `eth0` sind umgebungsabhängig. Verwende im Rest der Anleitung immer den Namen deines eigenen Interfaces.

networkctl status enp0s2
ip addr show enp0s2
ip route

Wenn die Route `proto dhcp` zeigt und `networkctl status` DHCP-Adressen meldet, läuft die Appliance dynamisch. Für Tests ist das praktisch; für einen öffentlich betriebenen Mailserver brauchst du eine planbare Adresse, konsistente Firewallregeln und einen PTR, der zur sendenden IP passt.

Ein verifizierter persistenter Weg ist eine eigene systemd-networkd-Datei in `/etc/systemd/network/`. Ersetze Interface, Adresse, Prefix, Gateway und DNS-Server durch deine Werte. Bei Remote-Systemen nur mit Console- oder Out-of-Band-Zugriff ändern, weil eine falsche Adresse SSH sofort unterbrechen kann.

[Match]
Name=enp0s2

[Network]
Address=203.0.113.10/24
Gateway=203.0.113.1
DNS=1.1.1.1
DNS=9.9.9.9
Domains=example.com

install -m 0644 10-enp0s2.network /etc/systemd/network/10-enp0s2.network
systemctl restart systemd-networkd

ip -br addr show enp0s2
ip route
ping -c 3 203.0.113.1
networkctl status enp0s2

DNS-Resolver konfigurieren und testen

Auf der geprüften Appliance waren `resolvectl` und `systemd-resolve` nicht vorhanden. `/etc/resolv.conf` war eine reguläre Datei. Verwende deshalb nicht blind generische systemd-resolved-Anleitungen, sondern prüfe den tatsächlichen Zustand deiner Appliance.

ls -l /etc/resolv.conf
cat /etc/resolv.conf
networkctl status enp0s2
grep -R "^DNS=" /etc/systemd/network /etc/sysconfig/network 2>/dev/null || true

Wenn du DNS-Server in der `.network`-Datei setzt, müssen sie danach in `networkctl status` und in `/etc/resolv.conf` sichtbar sein. In Unternehmensnetzen können interne Resolver sinnvoller sein als öffentliche Resolver. Wichtig ist, dass Repository-Domains, deine Maildomain und externe Empfänger-Domains auflösbar sind.

cat /etc/resolv.conf
getent hosts download.grommunio.com
dig download.grommunio.com
zypper refresh

Erwartetes Ergebnis: Resolver sind eingetragen, `getent` und `dig` liefern Adressen, und `zypper refresh` erreicht die grommunio- und openSUSE-Repositories. Wenn nur IP-Verkehr funktioniert, aber Hostnamen nicht, liegt das Problem fast immer bei Resolver, DNS-Firewall oder Proxy.

reboot

# Nach dem Reboot erneut prüfen:
ip -br addr show enp0s2
ip route
cat /etc/resolv.conf
dig download.grommunio.com
networkctl status enp0s2
zypper refresh

• Keine IP: Interface-Name, Match-Regel und Link-Status prüfen.

• Keine Default Route: Gateway, Prefix und Netz prüfen.

• IP und Route funktionieren, aber DNS nicht: `/etc/resolv.conf`, DNS-Server, Firewall oder Proxy prüfen.

• DNS funktioniert, Repository nicht: Repository-URL, HTTPS-Inspection, Proxy, Firewall oder Updatekanal prüfen.

Hostname, FQDN und Zeit prüfen

Setze den FQDN des Servers bewusst. Er muss zu DNS, Zertifikat, HELO/EHLO und PTR passen.

hostnamectl set-hostname mail.example.com
hostnamectl
hostname -f
getent hosts mail.example.com
timedatectl

Zeit ist für TLS, Authentifizierung und Mailzustellung wichtig. Erwartet sind korrekte Zeitzone und synchronisierte Uhr. Wenn `timedatectl` keine Synchronisierung zeigt, richte den vorgesehenen NTP-/Chrony-Weg deiner Umgebung ein, bevor du die Instanz produktiv nutzt.

Öffentliche DNS-Basis vorbereiten

Der Server-FQDN und die Maildomain sind zwei verschiedene Dinge. Der FQDN benennt den Host, zum Beispiel mail.example.com. Die Maildomain ist der Adressteil nach dem @, zum Beispiel example.com.

mail.example.com.  A      203.0.113.10
example.com.       MX 10  mail.example.com.

203.0.113.10 -> mail.example.com

dig A mail.example.com
dig MX example.com
dig -x 203.0.113.10

• Forward DNS: Der Hostname zeigt auf die richtige IP.

• PTR: Die IP zeigt wieder auf den sendenden Hostnamen.

• MX: Die Maildomain verweist auf den Mailhost.

• HELO/EHLO: Der Mailserver meldet sich mit einem konsistenten Namen.

• Reputation: Neue oder schlecht konfigurierte IPs werden von Empfängern vorsichtig bewertet.

grommunio-setup Schritt für Schritt

Starte `grommunio-setup` aus der CUI. Jeder Dialog entscheidet über spätere Bedienbarkeit.

Screenshot: Start des geführten Setup-Assistenten.

Role Selection: Core ist Pflicht. Zusätzliche Rollen wie Chat, Meet, Files, Office oder Archive aktivierst du erst, wenn Ressourcen und Betrieb dafür geplant sind.

Screenshot: Rollen und optionale Komponenten auswählen.

Repository configuration: Leere Zugangsdaten sind für Community-Repositories im Lab möglich. Für Produktion klärst du Subscription, Support und Updatekanal vorher.

Screenshot: Repository-Konfiguration im Setup.

Database selection: Die lokale Datenbank ist der Standard für eine einzelne Basisinstanz. Eine externe Datenbank ist ein Architekturthema für größere oder hochverfügbare Umgebungen.

Screenshot: Lokale Datenbank auswählen.

FQDN: Trage den Servernamen ein, nicht die Maildomain. Beispiel: mail.example.test.

Screenshot: FQDN des Servers eintragen.

Primary mail domain: Trage die Domain für Postfächer ein. Beispiel: example.test für alex@example.test.

Screenshot: Primäre Maildomain eintragen.

Relayhost: Leer lassen, wenn der Server direkt zustellen soll. Einen Smarthost trägst du ein, wenn ausgehende Mails über ein Gateway, Security-Appliance oder Provider-Relay laufen.

Screenshot: Relayhost-Dialog im Setup.

TLS mode: Self-signed ist nur für Lab und Test sinnvoll. Produktiv verwendest du Let’s Encrypt oder eine vertrauenswürdige Unternehmens-PKI mit passender Chain und passenden SANs.

Screenshot: TLS-Modus wählen.

Screenshot: Setup installiert und konfiguriert die gewählten Komponenten.

Status, Version und Ports prüfen

Nach dem Setup prüfst du Version, Dienste, Ports, Repositories und Firewall. Ein grüner Login alleine reicht nicht.

grommunio-admin version
rpm -qa | grep -Ei 'grommunio-release|grommunio-admin-api|grommunio-web|gromox' | sort
systemctl --failed
systemctl status nginx postfix mariadb redis@grommunio grommunio-admin-api grommunio-antispam
systemctl status gromox-http gromox-imap gromox-delivery gromox-delivery-queue
ss -tulpn
zypper lr -u
zypper refresh
firewall-cmd --list-all

In der geprüften Installation liefen nginx, Postfix, MariaDB, Redis, grommunio-admin-api, grommunio-antispam und die zentralen gromox-Dienste. Admin Web liegt auf 8443, grommunio Web auf 443, SMTP auf 25 und Submission auf 587.

mail.example.test:8443

Screenshot: Admin Dashboard mit Dienst- und Systemstatus.

TLS produktionsnah konfigurieren

Self-signed TLS ist für die erste Inbetriebnahme in Ordnung, aber kein produktiver Endzustand. Produktiv brauchst du ein Zertifikat für den Server-FQDN, den passenden privaten Schlüssel, eine vollständige Chain und einen planbaren Renewal-Prozess.

• Öffentliche CA/ACME: sinnvoll, wenn die Instanz öffentliche Namen und ACME-Erreichbarkeit hat.

• Enterprise PKI: sinnvoll, wenn Clients zentral verwaltete Unternehmens-Truststores nutzen.

• Prüfung: Hostname, SAN, Chain, Ablaufdatum und Protokoll-Aushandlung kontrollieren.

• Betrieb: Zertifikatswechsel und Reloads dokumentieren, bevor ein Zertifikat abläuft.

openssl s_client -connect mail.example.com:443 -servername mail.example.com
openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com

Erwartet: Das Zertifikat passt zum Server-FQDN, die Chain ist vollständig, und STARTTLS auf Submission verhandelt TLS ohne Zertifikatswarnungen. Wenn der Browser oder Mailclient warnt, prüfst du zuerst SAN, Chain und falsche alte Zertifikate.

Firewall und Ports

Öffne nur die Ports, die für die jeweilige Rolle gebraucht werden. Die Basisinstallation braucht keine öffentlich erreichbare Datenbank und keinen öffentlich erreichbaren Redis.

Dienst        Port   Protokoll   Öffentlich?              Zweck
SMTP          25     TCP         ja, falls direkte Annahme  eingehende Mail
Submission    587    TCP         ja, für Clients            authentifiziertes Senden
HTTPS         443    TCP         ja                          Web, EAS, EWS, MAPI/HTTP
IMAPS         993    TCP         optional                    IMAP-Clients
POP3S         995    TCP         optional                    POP3-Clients
Admin Web     8443   TCP         Management/VPN             Administration
SSH           22     TCP         Management/VPN             Betrieb
MariaDB       3306   TCP         nein                        lokal/intern
Redis         6379   TCP         nein                        lokal/intern
Rspamd UI     11334  TCP         nein                        lokal/intern

firewall-cmd --list-all
ss -tulpn

Erwartet: SMTP/HTTPS/Submission sind nur geöffnet, wenn sie wirklich gebraucht werden. Admin und SSH liegen hinter Management-Netz, VPN oder IP-Restriktion. Datenbank, Redis und Rspamd-Backend bleiben intern.

grommunio Admin benutzen

Öffne die Admin-Oberfläche unter `https://mail.example.com:8443/`. Nach dem Login findest du globale Verwaltung links unter Admin sowie den Domain-Bereich unter Domains.

• Dashboard: Dienste, Systemzustand und Mailfilter-Statistiken.

• Organizations: Mandanten/Organisationen.

• Domains: Maildomains, DNS Health, Standardwerte und Domainobjekte.

• Users: Benutzer, Mailboxen, Quotas, Features und Aliase.

• Mail queue und Logs: erste Diagnosepunkte bei Zustellproblemen.

Organisationen verstehen und anlegen

Eine Organisation gruppiert Domains zu einem Mandanten. Jede Domain kann höchstens einer Organisation zugeordnet sein. Rollen wie OrgAdmin können dadurch Zugriff auf mehrere Domains innerhalb dieser Organisation bekommen.

Organisation
  +-- Domain example.com
  |     +-- User / Mailbox alice@example.com
  |     +-- Alias info@example.com
  +-- Domain example.org

In der Admin UI öffnest du Admin -> Organizations, wählst NEW ORGANIZATION, trägst Name und Beschreibung ein, ordnest bei Bedarf Domains zu und speicherst. Per CLI wurde die Organisation im Test so angelegt:

grommunio-admin org create "Example Organization" \
  --description "Synthetic lab tenant" \
  --domain 1

grommunio-admin org list
grommunio-admin org show 1

mail.example.test:8443

Screenshot: Organisationen in der Admin UI.

Domains verstehen und anlegen

Die Domain ist die Maildomain, nicht der Server-FQDN. `mail.example.com` ist der Server, `example.com` ist die Maildomain, `alice@example.com` ist die Benutzeradresse.

In der Admin UI öffnest du Domains, klickst NEW DOMAIN und setzt Domainname, Organisation, Maximum users, Titel und bei Bedarf weitere Kontaktdaten. Die Detailansicht zeigt außerdem DNS Health und Standardwerte für neue Benutzer.

grommunio-admin domain create example.test \
  -u 25 \
  --title "Example Test" \
  --orgID 1

grommunio-admin domain list
grommunio-admin domain show example.test
grommunio-admin domain modify example.test -u 50 --title "Example Test Production"

mail.example.test:8443

Screenshot: Domain-Detailansicht mit DNS Health und Standard-User-Parametern.

DNS Health im grommunio Admin

Die DNS-Health-Ansicht findest du in der Admin UI unter Domains, Domain auswählen, Domain overview. Dort zeigt grommunio, welche Records schon passen und welche Records für zuverlässige Zustellung, Autodiscover und Clientzugriff noch fehlen.

Anzeige              Bedeutung                         Maßnahme
Grün / OK            Check erfolgreich                 Record beibehalten und extern gegenprüfen
Rot / Required       Pflichtcheck fehlt oder falsch     Vor Produktivbetrieb korrigieren
Orange / Recommended empfohlener Record fehlt/unklar    Einrichten, wenn die Funktion genutzt wird
Blau / Optional      optionaler Record/Funktion         nur setzen, wenn fachlich benötigt

Im sichtbaren 2026.06.1-Status waren Reachability grün, MX rot, Autodiscover, Autodiscover SRV, Autoconfig, SPF, DKIM und DMARC orange sowie DAV/CalDAV/CardDAV/IMAP/POP3/Submission blau. Die Legende der UI erklärt diese Klassen direkt als OK, Required, Recommended und Optional.

Sichtbarer Check       Statusklasse   Bedeutung                         Was tun?
Reachability           OK             Domain/Server ist erreichbar       beibehalten
MX Records             Required       MX fehlt oder passt nicht           MX beim DNS-Provider setzen
Autodiscover           Recommended    Autodiscover fehlt/unklar           für Clients einrichten
Autodiscover SRV       Recommended    SRV-Autodiscover fehlt/unklar       setzen, wenn Clients es nutzen
Autoconfig             Recommended    Autoconfig fehlt/unklar             Thunderbird/Clients berücksichtigen
SPF Records            Recommended    SPF fehlt/unklar                    legitime Sender definieren
DKIM                   Recommended    DKIM fehlt/unklar                   Public Key veröffentlichen
DMARC                  Recommended    DMARC fehlt/unklar                  Monitoring-Policy starten
DAV/CalDAV/CardDAV     Optional       optionale Client-Records            nach Clientbedarf setzen
IMAP/POP3/Submission   Optional       optionale Protokoll-Records         nach Clientbedarf setzen

DNS Records beim Provider setzen

Arbeite DNS recordweise: Sollwert in grommunio öffnen, beim DNS-Provider eintragen, extern mit `dig` prüfen, DNS-Propagation abwarten und anschließend DNS Health neu laden.

Record Type: A
Name:        mail
Value:       203.0.113.10
TTL:         300-3600

Record Type: MX
Name:        @
Priority:    10
Value:       mail.example.com.
TTL:         300-3600

PTR:
Setzt normalerweise der Server-/IP-Provider:
203.0.113.10 -> mail.example.com

dig A mail.example.com
dig AAAA mail.example.com
dig MX example.com
dig -x 203.0.113.10

AAAA veröffentlichst du nur, wenn IPv6 für eingehenden und ausgehenden Mailflow wirklich korrekt geroutet, gefiltert und reputationsseitig vorbereitet ist. Ein halb konfiguriertes IPv6 ist für Mail oft schlechter als kein IPv6.

User, Mailbox, Alias und Quota

Ein grommunio User ist die Login-Identity und besitzt normalerweise direkt eine private Mailbox. Wenn du `--no-maildir` nicht setzt, wird der Mailstore beim Anlegen des Benutzers erzeugt. Quotas werden auf User/Mailbox-Ebene in der User-Detailansicht gepflegt; Domain `maxUser` begrenzt die Anzahl der Benutzer dieser Domain.

In der Admin UI öffnest du die Domain, dann Users, dann NEW USER. Trage Username, Passwort, Display Name, Storage quota limit und die gewünschten Features ein. Danach prüfst du die Detailansicht.

grommunio-admin user create alex@example.test \
  --domain example.test \
  --lang de_DE \
  --pop3-imap true \
  --privWeb true \
  --smtp true \
  --alias support@example.test

grommunio-admin passwd alex@example.test
grommunio-admin user query username aliases maildir pop3_imap smtp privWeb status
grommunio-admin user show alex@example.test
du -sh /var/lib/gromox/user/example.test/alex

In der geprüften CLI konnte ein Alias beim Anlegen gesetzt werden. Nachträgliche Alias-Änderungen per CLI wurden in dieser Lab-Version nicht als belastbarer Copy/Paste-Pfad übernommen; nutze dafür die Admin UI oder prüfe die aktuelle Subcommand-Hilfe deiner installierten Version.

mail.example.test:8443

Screenshot: User-Liste innerhalb der Domain.

mail.example.test:8443

Screenshot: User-Detailansicht mit Mailbox-Quota, Speicherverbrauch und Feature-Rechten.

grommunio Web und lokale Testmail

grommunio Web erreichst du unter `https://mail.example.com/web/`. Melde dich mit dem Testbenutzer an. Danach sendest du auf dem Server eine lokale Testmail und prüfst sie im Posteingang.

mail.example.test/web/

Screenshot: grommunio Web Login.

printf "From: admin@example.test\nTo: alex@example.test\nSubject: grommunio Lab Testmail\n\nDiese Testmail wurde lokal erzeugt.\n" \
  | sendmail -v alex@example.test

gromox-mailq

mail.example.test/web/

Screenshot: Die lokal zugestellte Testmail ist im Posteingang sichtbar.

SMTP, TLS, Queue und Logs prüfen

Lokale Zustellung prüft nur den internen Weg. Für SMTP Submission testest du später von einem Client gegen Port 587 mit Authentifizierung und STARTTLS. `swaks` war in der geprüften Appliance nicht vorinstalliert; installiere es nur bewusst oder nutze ein externes Testsystem.

swaks --server mail.example.com \
  --port 587 \
  --auth LOGIN \
  --auth-user alex@example.com \
  --from alex@example.com \
  --to alice@example.net \
  --tls

openssl s_client -starttls smtp \
  -connect mail.example.com:587 \
  -servername mail.example.com

gromox-mailq
journalctl -u postfix -u gromox-delivery -u gromox-delivery-queue --since "30 minutes ago"
journalctl -u nginx -u grommunio-admin-api --since "30 minutes ago"
journalctl -u gromox-http -u gromox-imap --since "30 minutes ago"

Eine leere Queue ist nach einer zugestellten Testmail normal. Wenn Mails hängen bleiben, prüfst du zuerst Empfänger, DNS, TLS, Authentifizierung, Queue und die genannten Journals.

SPF, DKIM und DMARC als Basis

SPF, DKIM und DMARC gehören zur Produktionsbasis. Die Admin-UI zeigt in der Domain-Detailansicht DNS Health und DKIM. DKIM-Private-Keys gehören nie in Screenshots, Tickets oder Dokumentation.

DKIM: Öffne die Domain in der Admin UI, wechsle zum DKIM-/DNS-Bereich, erzeuge oder öffne den Public Key, notiere Selector, Name und TXT-Wert, veröffentliche nur den öffentlichen TXT-Record und prüfe danach mit `dig`. Den privaten Schlüssel kopierst du nie in Dokumente, Tickets oder Screenshots.

dig MX example.com
dig TXT example.com
dig TXT selector._domainkey.example.com
dig TXT _dmarc.example.com

• SPF: Bestimme zuerst alle legitimen Sender. Baue erst dann den TXT-Record, veröffentliche ihn und prüfe Mail-Header.

• DKIM: Erzeuge den Schlüssel in der Domain-Verwaltung, veröffentliche nur den Public TXT Record, warte DNS-Propagation ab und prüfe danach erneut.

• DMARC: Starte mit Monitoring, zum Beispiel `p=none`, und verschärfe erst nach vollständiger Senderanalyse auf quarantine oder reject.

• Autodiscover/Autoconfig: Setze nur Records, die zu deinen Clients passen, und prüfe danach die DNS-Health-Ansicht erneut.

Externer Mailflow und Open-Relay-Check

Eine lokale Testmail beweist den internen Weg, aber noch keinen produktiven Mailbetrieb. Für den Go-live testest du zusätzlich von außen: eingehende SMTP-Zustellung, Submission mit Authentifizierung, TLS, DKIM/SPF/DMARC-Auswertung und dass der Server kein Open Relay ist.

# Von einem externen Testsystem:
dig MX example.com
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com
openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com

# Defensive Prüfung: fremde Absender/Empfänger dürfen ohne Authentifizierung
# nicht frei über deinen Server relayed werden.

Erwartet: Eingehende Mail für eigene Domains wird angenommen, Submission verlangt Authentifizierung, fremde Relay-Versuche werden ohne Authentifizierung abgelehnt, und gesendete Mails zeigen gültige DNS-/Auth-Header.

Hardening für produktive Systeme

• DEFAULT: Datenbank, Redis und interne Backend-Ports nicht öffentlich freigeben.

• DEFAULT: Submission nur mit Authentifizierung und TLS betreiben.

• EMPFOHLEN: SSH auf Management-Netze oder VPN beschränken und Schlüssel bevorzugen.

• EMPFOHLEN: Admin UI auf Management-Netze, VPN oder IP-Restriktion begrenzen.

• EMPFOHLEN: Zertifikate, DKIM, SPF, DMARC, PTR und MX überwachen.

• EMPFOHLEN: Updates, Backups und Restore-Tests in ein Wartungskonzept aufnehmen.

• UMGEBUNGSABHÄNGIG: Root-Login, Passwort-Login, Fail2ban/SIEM-Integration und zentrale Identity-Anbindung passend zur Organisation festlegen.

Updates, Backup und Monitoring

Updates sind Teil des Betriebs, nicht der Abschluss der Installation. Prüfe Repositories, Patchliste, Wartungsfenster, Backup und Rollback-Plan. Der Hersteller beschreibt den Rhythmus in der Update-Cycle-Dokumentation.

zypper refresh
zypper list-patches
zypper patch
systemctl --failed
gromox-mailq

• Backup: Konfiguration, Zertifikate, Datenbank und Maildaten konsistent sichern.

• Snapshot ist kein Backup; Restore muss praktisch getestet werden.

• Monitoring: HTTPS, SMTP, Queue, Zertifikate, Disk/Inodes, MariaDB, Redis, Rspamd, gromox, CPU/RAM, Backup-Alter, DNS und verfügbare Updates überwachen.

Abschlusscheck

[ ] FQDN korrekt
[ ] statische IP persistent
[ ] Gateway erreichbar
[ ] DNS-Resolver funktionieren
[ ] Reboot-Test bestanden
[ ] Zeit/NTP geprüft
[ ] A/AAAA bewusst gesetzt
[ ] MX gesetzt
[ ] PTR beim Provider gesetzt
[ ] TLS-Zertifikat passt
[ ] Firewall geprüft
[ ] Organisation angelegt
[ ] Domain angelegt
[ ] User angelegt
[ ] Mailbox vorhanden
[ ] Alias geprüft
[ ] Quota geprüft
[ ] Web Login erfolgreich
[ ] lokale Zustellung erfolgreich
[ ] SMTP Submission getestet
[ ] externe Zustellung getestet
[ ] kein Open Relay
[ ] DKIM veröffentlicht und geprüft
[ ] SPF veröffentlicht und geprüft
[ ] DMARC veröffentlicht und geprüft
[ ] Queue leer oder verstanden
[ ] Logs geprüft
[ ] Updates geplant/getestet
[ ] Backup geplant
[ ] Restore-Test geplant
[ ] Monitoring geplant

Was später eigene Beiträge bekommt

• Keycloak / SSO: LDAP, FreeIPA, AD, MFA, OIDC/SAML und Break-Glass-Zugriff.

• grommunio Antispam 2026: Rspamd, SPF, DKIM, DMARC, DNSBL, Bayes, Quarantine und Tuning.

• grommunio Meet: STUN/TURN, NAT, Firewall und SSO.

• grommunio Chat: Setup, SSO, Berechtigungen und Betrieb.

• Backup/DR und Monitoring: Restore-Tests, RPO/RTO, Alerting und Runbooks.

Lizenzen und Teststellungen

Wenn du grommunio evaluieren möchtest oder Lizenzen für eine produktive Umgebung benötigst, kann ForgeOne auch bei der Lizenzierung unterstützen. Als grommunio Gold Partner helfen wir bei der Auswahl des passenden Lizenzmodells und klären gemeinsam Test- beziehungsweise Evaluierungsmöglichkeiten für geplante Umgebungen.