Kurzüberblick

Getestete Basis ist die openSUSE-basierte grommunio Appliance 2026.06.1. Die Beispiele verwenden durchgehend die neutrale Appliance-Domain https://mail.example.test; Pfade wie /web/, /admin/, /auth/, /chat/, /meet/ und /files/ liegen auf derselben Appliance.Dieser Beitrag führt dich von der grommunio-Appliance bis zu einem nutzbaren System mit Admin-Login, Web-Login, erster Domain, erstem Benutzer und Testmail.

Ausgangspunkt ist die openSUSE-basierte grommunio Appliance. Alle CLI-Schritte sind entsprechend für diese Appliance beschrieben.

Getestete Umgebung

  • grommunio 2026 auf der openSUSE-basierten grommunio Appliance.

  • Alle Appliance-Befehle werden direkt auf der grommunio Appliance ausgeführt.

  • Öffentliche Beispiele verwenden durchgehend die neutrale Appliance-Domain https://mail.example.test.

Ziel dieser Anleitung

Dieser Beitrag ordnet grommunio-Plattform praktisch ein und zeigt, welche Entscheidungen für eine belastbare Umsetzung wichtig sind. Am Ende soll klar sein, was vorbereitet werden muss, woran du einen funktionierenden Stand erkennst und welcher nächste Schritt sinnvoll ist.

Voraussetzungen

Eine bestehende oder geplante grommunio-Umgebung, passende DNS-Namen, TLS, administrative Zugänge und ein klares Ziel für Mail, Collaboration oder Betrieb.

grommunio 2026.06.1 installieren: vom ISO zur nutzbaren Groupware

Dieser Artikel führt dich durch eine echte Installation von grommunio 2026.06.1 in einer isolierten KVM-Lab-VM. Ziel ist nicht nur ein gebootetes System, sondern eine nutzbare Groupware-Instanz mit Admin UI, Web Login, erster Domain, erstem Benutzer, lokaler Testmail und nachvollziehbaren Betriebschecks.

Die Installation heißt im Lab mail.example.test und verwendet example.test als synthetische Mail-Domain. Ersetze diese Namen in deiner Umgebung durch echte DNS-Namen, die du kontrollierst.

mail.example.test:8443

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

Vorbereitung: DNS, Ressourcen und Installationsmedium

Lade die Installations-ISO über die offizielle grommunio Quickstart-Dokumentation. Für produktive Tests solltest du mindestens 4 vCPU, 6 GB RAM, 32 GB Systemdisk und separaten Speicher für Maildaten einplanen. Im Lab wurden 4 vCPU, 8 GB RAM, 64 GB Systemdisk und eine zusätzliche 128-GB-Disk verwendet.

Vor der Installation brauchst du ein klares Namenskonzept. Für produktiven Mailbetrieb gehören FQDN, MX, autodiscover, TLS-Zertifikat, SPF, DKIM und DMARC zusammen. Ohne sauberes DNS kann eine Groupware zwar lokal laufen, aber nicht seriös Mails empfangen und zustellen.

bash
sha256sum grommunio.x86_64-2026.06.1-Build5.7.install.iso
# Erwarteter SHA256 aus dem Lab:
# 4a100920fb6bb661d3c09159a3a74568f1c9b56cbbdd9b55f20017d8692023b0

VM starten und Zielplatte wählen

Boote die VM von der grommunio Installations-ISO. Der Installer ist bewusst schlank: Du wählst die Zielplatte, bestätigst die destruktive Installation und lässt das Appliance-Image schreiben. Prüfe vor der Bestätigung unbedingt, dass du nicht versehentlich eine Datenplatte auswählst.

mail.example.test:8443

Screenshot: Der Installer zeigt die verfügbaren Disks und markiert die Systemdisk als Ziel.

mail.example.test:8443

Screenshot: Die Installation löscht die gewählte Zielplatte vollständig.

mail.example.test:8443

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

Nach Abschluss entfernst du das ISO beziehungsweise stellst die Boot-Reihenfolge wieder auf die virtuelle Festplatte. Danach startet das frisch installierte grommunio Appliance-System.

Erster Boot: CUI, Root-Passwort, Hostname und Netzwerk

Beim ersten Start landest du in der grommunio Console User Interface. Das initiale Root-Passwort ist nicht gesetzt. Setze zuerst ein Root-Passwort, prüfe Hostname, IP-Konfiguration, Gateway, DNS und Zeit. Für produktive Systeme muss der Hostname als vollständiger FQDN zurückkommen.

mail.example.test:8443

Screenshot: Erster CUI-Start nach der Image-Installation: Setup ist noch nicht ausgeführt.

mail.example.test:8443

Screenshot: Das Root-Passwort wurde im Lab gesetzt; in produktiven Umgebungen nutzt du starke, verwaltete Credentials.

mail.example.test:8443

Screenshot: Die CUI zeigt Host-, Netzwerk- und Dienststatus vor dem eigentlichen grommunio Setup.

bash
hostnamectl hostname mail.example.test
hostname -f
ip address show
ip route
getent hosts download.grommunio.com
timedatectl

Im Lab war nach dem ersten Start zwar eine IP-Adresse vorhanden, aber die Namensauflösung musste korrigiert werden. Prüfe Resolver also vor dem Setup. Wenn Repository-Downloads scheitern, ist häufig DNS die Ursache.

grommunio-setup ausführen

Starte den Setup-Assistenten aus der CUI. Core ist die zentrale Groupware-Rolle. Chat, Meet, Files, Office und Archive sind optionale Komponenten und sollten erst aktiviert werden, wenn Ressourcen, DNS, TLS und Betriebsmodell dafür geplant sind.

mail.example.test:8443

Screenshot: Start des geführten grommunio Setup-Assistenten.

mail.example.test:8443

Screenshot: Core bleibt Pflicht; zusätzliche Rollen werden bewusst ausgewählt.

Bei den Repository-Zugangsdaten kannst du im Lab leere Werte verwenden, wenn du die Community-Repositories nutzt. Für produktive Umgebungen prüfst du vorher Subscription, Updatekanal und Wartungsmodell.

mail.example.test:8443

Screenshot: Repository-Konfiguration: im Lab ohne kommerzielle Zugangsdaten.

Für kleine und mittlere Einzelinstanzen ist die lokale Datenbank der einfache Startpunkt. Externe Datenbanken sind ein Architekturthema und gehören erst geplant, wenn Hochverfügbarkeit, Backup, Rollenmodell und Betriebsteam dazu passen.

mail.example.test:8443

Screenshot: Lokale Datenbank als Standardauswahl für die Lab-Installation.

FQDN, Domain, Relayhost und TLS

Der FQDN ist der technische Name des Mailservers, zum Beispiel mail.example.test. Die primäre Mail-Domain ist die Domain der Postfächer, zum Beispiel example.test. Diese beiden Werte dürfen bewusst unterschiedlich sein.

mail.example.test:8443

Screenshot: FQDN des Servers im Setup.

https://mail.example.test/admin/

Screenshot: Primäre Mail-Domain für die ersten Postfächer.

Einen Relayhost trägst du nur ein, wenn ausgehende Mails über einen Smarthost laufen sollen. Für direkte Zustellung brauchst du stattdessen saubere Reverse-DNS-, SPF-, DKIM- und DMARC-Konfiguration und einen IP-Ruf, der Mailzustellung erlaubt.

mail.example.test:8443

Screenshot: Relayhost bleibt im isolierten Lab leer.

Für das Lab reicht ein selbstsigniertes Zertifikat. Produktiv nimmst du Let’s Encrypt oder ein eigenes Zertifikat mit passenden Subject Alternative Names, typischerweise für mail und autodiscover. Port 80 muss für Let’s Encrypt erreichbar sein.

mail.example.test:8443

Screenshot: TLS-Auswahl: Self-Signed ist nur für Lab und Test sinnvoll.

mail.example.test:8443

Screenshot: Der Setup-Assistent installiert und konfiguriert die ausgewählten Komponenten.

Nach dem Setup: Services, Repositories und Ports prüfen

Nach dem Wizard prüfst du nicht nur, ob die Weboberfläche lädt. Ein Mailserver besteht aus mehreren Diensten, Ports, Queues, Datenbanken und Zustellpfaden. Der erste Betriebscheck gehört direkt nach der Installation dazu.

bash
systemctl --failed
systemctl --type=service --state=running | egrep 'grom|postfix|nginx|mariadb|redis|rspamd|saslauthd'
ss -tulpn
zypper lr -u
zypper refresh
zypper list-patches
firewall-cmd --list-all

Im geprüften Lab liefen unter anderem grommunio-admin-api, grommunio-antispam, mehrere gromox-Dienste, MariaDB, nginx, Postfix, Redis und saslauthd. Die Appliance basiert auf openSUSE Leap 16.0 und nutzt systemd-networkd. Die Root-Partition wurde im Lab als XFS eingerichtet.

https://mail.example.test/admin/

Screenshot: Das Admin Dashboard zeigt laufende Dienste und Systemzustand.

Domain und Benutzer anlegen

Lege nach dem Setup eine Domain und mindestens einen Testbenutzer an. Das kannst du über die Admin UI oder über die CLI tun. Die CLI ist hilfreich, weil sie reproduzierbar dokumentierbar ist und sich später automatisieren lässt.

bash
grommunio-admin domain create example.test -u 25 --title "Example Test"
grommunio-admin user create alex@example.test \
--domain example.test \
--lang de_DE \
--pop3-imap true \
--privWeb true \
--smtp true
grommunio-admin passwd alex@example.test
grommunio-admin user query username maildir pop3_imap smtp privWeb status
https://mail.example.test/admin/

Screenshot: Die Lab-Domain example.test ist in der Admin UI sichtbar.

https://mail.example.test/admin/

Screenshot: Der Benutzer alex@example.test wurde im Lab angelegt.

Web Login und lokale Testmail

Melde dich mit dem Testbenutzer in grommunio Web an. Danach sendest du lokal auf dem Server eine Testmail an das Postfach und prüfst, ob sie im Webclient ankommt. Damit testest du noch keine externe Zustellung, aber du prüfst den lokalen Annahme- und Zustellpfad.

https://mail.example.test/web/

Screenshot: grommunio Web Login der frisch installierten Lab-Instanz.

bash
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
journalctl -u postfix -u gromox-delivery -u gromox-delivery-queue --since "10 minutes ago"
https://mail.example.test/web/

Screenshot: Die lokal erzeugte Testmail ist im grommunio Web Posteingang sichtbar.

DNS, DKIM, SPF, DMARC und externe Zustellung

grommunio 2026.06.1 bringt laut Release Notes Verbesserungen rund um Admin Web, DKIM und DNS-Prüfungen mit. Für echte Zustellung brauchst du trotzdem eine bewusst geplante Mail-Domain.

  • MX zeigt auf den Mailhost.

  • A/AAAA für mail und autodiscover passen zur Umgebung.

  • PTR/Reverse DNS passt zum sendenden Hostnamen.

  • SPF beschreibt erlaubte Sender.

  • DKIM wird pro Domain eingerichtet und veröffentlicht.

  • DMARC definiert Policy und Reporting.

  • Ein Open-Relay-Test muss von außerhalb vertrauenswürdiger Netze erfolgen.

DKIM-Keypair in der Admin UI erzeugen

Öffne in der grommunio Admin UI die Domain, gehe in den DNS-Health-Bereich und öffne DKIM. Der erste Dialog zeigt den aktuellen DNS-Status. In einer neuen Umgebung ist der externe DKIM-Eintrag erwartbar noch nicht auflösbar.

https://mail.example.test/admin/

Screenshot: Die Domain-Detailansicht zeigt DNS Health für SPF, SRV, Autodiscover und DKIM.

https://mail.example.test/admin/

Screenshot: Der DKIM-DNS-Check zeigt vor der Schlüsselerstellung noch einen Platzhalter für den Public Key.

Klicke im DKIM-Dialog auf Generate DKIM keypair. Im zweiten Dialog bleiben Type rsa und Output mode dns für den üblichen TXT-Record passend. Den Selector kannst du leer lassen, dann verwendet grommunio den Standardselector dkim.

https://mail.example.test/admin/

Screenshot: Der Keypair-Dialog erzeugt den DKIM-Schlüssel für die ausgewählte Domain.

Nach Generate zeigt die Admin UI den Public Key für DNS und die notwendigen Nacharbeiten auf dem Server. Der private Schlüssel wurde im geprüften System unter /var/lib/grommunio-admin-api/example.test.dkim.key erzeugt. Veröffentliche nur den TXT-Record im DNS; der private Schlüssel bleibt auf dem Server.

https://mail.example.test/admin/

Screenshot: Nach der Erzeugung zeigt die Admin UI den DKIM-TXT-Record und die serverseitigen Nacharbeiten.

Für die Signatur muss grommunio-antispam den privaten Schlüssel lesen können. Die Admin UI zeigt dafür die passenden Befehle an. In der geprüften grommunio-2026.06.1-Appliance läuft grommunio-antispam als groas mit Gruppe grommunio.

bash
postconf -e 'non_smtpd_milters = $smtpd_milters'
mkdir -m 0700 /var/lib/grommunio-antispam/dkim
cp /var/lib/grommunio-admin-api/example.test.dkim.key /var/lib/grommunio-antispam/dkim/
chown -Rf groas:grommunio /var/lib/grommunio-antispam/dkim
chmod 600 /var/lib/grommunio-antispam/dkim/example.test.dkim.key
systemctl restart postfix

Ersetze example.test durch deine echte Mail-Domain. Danach prüfst du die DNS-Veröffentlichung und eine ausgehende Testmail über einen externen Empfänger oder Mail-Testdienst, weil lokale Zustellung die externe DKIM-Signatur nicht vollständig bewertet.

Im isolierten Lab wurde keine echte externe Zustellung bewertet. Das ist Absicht: Ein lokaler NAT-Test sagt nichts darüber aus, ob ein Server aus dem Internet offen relayt oder ob große Provider die Zustellung akzeptieren.

Updates, Backup und Betrieb

Plane Updates wie bei einem produktiven Linux- und Mailserver: Repository-Refresh, Patchliste, Wartungsfenster, Backup, Snapshot, Dienstprüfung und Rollback-Plan. grommunio dokumentiert den Update-Rhythmus separat in der Update-Cycle-Dokumentation.

bash
zypper refresh
zypper list-patches
zypper patch
systemctl --failed
gromox-mailq
  • Sichere Konfigurationen, Zertifikate, Datenbank und Maildaten konsistent.

  • Teste Restore nicht nur theoretisch, sondern mit einem echten Rücksicherungsablauf.

  • Überwache Postfix, gromox-Dienste, Queue, Speicherplatz, Zertifikatslaufzeiten und Mailzustellung.

  • Halte Admin UI, Webzugriff und externe Ports bewusst getrennt und firewallseitig nachvollziehbar.

Abschlusscheck

  • ISO verifiziert und auf isolierter VM gebootet.

  • Zielplatte bewusst gewählt und Installation bestätigt.

  • Root-Passwort, Hostname, DNS, Gateway und Zeit geprüft.

  • grommunio-setup vollständig durchlaufen.

  • FQDN, primäre Mail-Domain, TLS-Modus und optionale Rollen bewusst gesetzt.

  • Services, Ports, Repositories und Firewall geprüft.

  • Domain und Benutzer angelegt.

  • grommunio Admin und grommunio Web erfolgreich geöffnet.

  • Lokale Testmail zugestellt und Queue geprüft.

  • Offene Punkte für Produktion: echte DNS-Zone, Zertifikat, externe Zustellung, Backup, Monitoring und Updateprozess.

Mailbox-Wartung mit gromox-cleaner

Nach der Grundinstallation solltest du die automatische Mailbox-Wartung bewusst prüfen. In der geprüften grommunio-2026.06.1-Appliance liefert Gromox den Timer gromox-cleaner.timer und den One-Shot-Service gromox-cleaner.service mit. Der Cleaner entfernt soft-gelöschte Nachrichten nach der konfigurierten Retention und räumt verwaiste Attachment-Dateien auf. Er ersetzt kein Archiv und kein Backup. Er ist auch nicht einfach ein Papierkorb-Leerer, sondern arbeitet auf der Gromox-Mailbox- und Attachment-Ebene.

Soft Delete bedeutet: Eine Nachricht ist gelöscht markiert und bleibt innerhalb der Retention wiederherstellbar. Hard Delete entfernt sie endgültig aus dem wiederherstellbaren Mailboxbestand. In der installierten Version nutzt der Service die Directive softdelete_purgetime aus /etc/gromox/gromox.cfg; wenn dort nichts gesetzt ist, verwendet die Unit 30d als Fallback.

bash
systemctl cat gromox-cleaner.service
systemctl cat gromox-cleaner.timer
systemctl status gromox-cleaner.timer
systemctl list-timers --all | grep gromox-cleaner

Wenn Retention, Backup, Restore und Archive-Konzept geklärt sind, kannst du den Timer aktivieren und einen manuellen Lauf prüfen. Im validierten Lab lief der Service erfolgreich und meldete keine zu löschenden Testobjekte.

bash
systemctl enable --now gromox-cleaner.timer
systemctl start gromox-cleaner.service
journalctl -u gromox-cleaner.service --since "10 minutes ago"
systemctl list-timers gromox-cleaner.timer

End-to-End-Test im Benutzerworkflow

Der End-to-End-Test der Basisinstallation besteht aus Login in die Admin-Oberfläche, Domain- und Benutzeranlage, Login in grommunio Web, Versand einer lokalen Testmail und Prüfung, dass Mailbox, Dienste, DNS-Grundlagen und DKIM-Erzeugung nachvollziehbar funktionieren.

Ergebniskontrolle / Technische Abnahme

Installation

Prüfung
Pakete und Komponenten prüfen
Erwartetes Ergebnis
Der Baustein ist vollständig installiert
Status
PASS

Dienste

Prüfung
systemd-Services prüfen
Erwartetes Ergebnis
Die notwendigen Dienste sind aktiv
Status
PASS

Netzwerk

Prüfung
Ports und URLs prüfen
Erwartetes Ergebnis
Der Baustein ist über die vorgesehenen Pfade erreichbar
Status
PASS

Grundfunktion

Prüfung
Standalone-Test ausführen
Erwartetes Ergebnis
Die Kernfunktion funktioniert vor der tieferen Integration
Status
PASS

Authentifizierung

Prüfung
SSO/Login testen
Erwartetes Ergebnis
Der Login funktioniert über den vorgesehenen Weg oder ist bewusst nicht erforderlich
Status
PASS oder N/A

grommunio Web

Prüfung
Integration aus Web prüfen
Erwartetes Ergebnis
Der Baustein ist aus grommunio Web erreichbar oder nutzbar
Status
PASS oder N/A

End-to-End

Prüfung
Realen Benutzerworkflow testen
Erwartetes Ergebnis
Der vollständige Workflow ist nachvollziehbar erfolgreich
Status
PASS

Neustart

Prüfung
Dienste neu starten
Erwartetes Ergebnis
Die Funktion bleibt nach einem Neustart erhalten
Status
PASS

Logs

Prüfung
Relevante Logs kontrollieren
Erwartetes Ergebnis
Keine blockierenden Fehler im geprüften Ablauf
Status
PASS

Typische Fehler & Troubleshooting

Wenn der geprüfte Ablauf nicht funktioniert, arbeite immer vom Symptom zur Ursache: Dienststatus prüfen, relevante Logs lesen, URL und Redirects kontrollieren, danach erst Konfiguration ändern und den Benutzerworkflow erneut testen.

Fazit & Ausblick

Damit ist dieser Baustein der grommunio-2026-Serie fachlich abgeschlossen und in den Gesamtpfad der Appliance eingeordnet. Der nächste Beitrag der Reihe baut auf dieser geprüften Basis auf.