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.
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.
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.
Screenshot: Der Installer zeigt die verfügbaren Disks und markiert die Systemdisk als Ziel.
Screenshot: Die Installation löscht die gewählte Zielplatte vollständig.
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.
Screenshot: Erster CUI-Start nach der Image-Installation: Setup ist noch nicht ausgeführt.
Screenshot: Das Root-Passwort wurde im Lab gesetzt; in produktiven Umgebungen nutzt du starke, verwaltete Credentials.
Screenshot: Die CUI zeigt Host-, Netzwerk- und Dienststatus vor dem eigentlichen grommunio Setup.
hostnamectl hostname mail.example.testhostname -fip address showip routegetent hosts download.grommunio.comtimedatectl
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.
Screenshot: Start des geführten grommunio Setup-Assistenten.
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.
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.
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.
Screenshot: FQDN des Servers im Setup.
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.
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.
Screenshot: TLS-Auswahl: Self-Signed ist nur für Lab und Test sinnvoll.
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.
systemctl --failedsystemctl --type=service --state=running | egrep 'grom|postfix|nginx|mariadb|redis|rspamd|saslauthd'ss -tulpnzypper lr -uzypper refreshzypper list-patchesfirewall-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.
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.
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 truegrommunio-admin passwd alex@example.testgrommunio-admin user query username maildir pop3_imap smtp privWeb status
Screenshot: Die Lab-Domain example.test ist in der Admin UI sichtbar.
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.
Screenshot: grommunio Web Login der frisch installierten Lab-Instanz.
printf "From: admin@example.test\nTo: alex@example.test\nSubject: grommunio Lab Testmail\n\nDiese Testmail wurde lokal erzeugt.\n" \| sendmail -v alex@example.testgromox-mailqjournalctl -u postfix -u gromox-delivery -u gromox-delivery-queue --since "10 minutes ago"
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.
Screenshot: Die Domain-Detailansicht zeigt DNS Health für SPF, SRV, Autodiscover und DKIM.
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.
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.
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.
postconf -e 'non_smtpd_milters = $smtpd_milters'mkdir -m 0700 /var/lib/grommunio-antispam/dkimcp /var/lib/grommunio-admin-api/example.test.dkim.key /var/lib/grommunio-antispam/dkim/chown -Rf groas:grommunio /var/lib/grommunio-antispam/dkimchmod 600 /var/lib/grommunio-antispam/dkim/example.test.dkim.keysystemctl 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.
zypper refreshzypper list-patcheszypper patchsystemctl --failedgromox-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.
systemctl cat gromox-cleaner.servicesystemctl cat gromox-cleaner.timersystemctl status gromox-cleaner.timersystemctl 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.
systemctl enable --now gromox-cleaner.timersystemctl start gromox-cleaner.servicejournalctl -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
| Prüfbereich | Prüfung | Erwartetes Ergebnis | Status |
|---|---|---|---|
| Installation | Pakete und Komponenten prüfen | Der Baustein ist vollständig installiert | PASS |
| Dienste | systemd-Services prüfen | Die notwendigen Dienste sind aktiv | PASS |
| Netzwerk | Ports und URLs prüfen | Der Baustein ist über die vorgesehenen Pfade erreichbar | PASS |
| Grundfunktion | Standalone-Test ausführen | Die Kernfunktion funktioniert vor der tieferen Integration | PASS |
| Authentifizierung | SSO/Login testen | Der Login funktioniert über den vorgesehenen Weg oder ist bewusst nicht erforderlich | PASS oder N/A |
| grommunio Web | Integration aus Web prüfen | Der Baustein ist aus grommunio Web erreichbar oder nutzbar | PASS oder N/A |
| End-to-End | Realen Benutzerworkflow testen | Der vollständige Workflow ist nachvollziehbar erfolgreich | PASS |
| Neustart | Dienste neu starten | Die Funktion bleibt nach einem Neustart erhalten | PASS |
| Logs | Relevante Logs kontrollieren | Keine blockierenden Fehler im geprüften Ablauf | PASS |
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.








