Overview
The validated baseline is the openSUSE-based grommunio appliance 2026.06.1. The examples consistently use the neutral appliance domain https://mail.example.test; paths such as /web/, /admin/, /auth/, /chat/, /meet/ and /files/ live on the same appliance.This article takes you from the grommunio appliance to a usable system with admin login, web login, first domain, first user and test mail.
The starting point is the openSUSE-based grommunio appliance. All CLI steps are written for that appliance unless a separate system is explicitly named.
Tested environment
grommunio 2026 on the openSUSE-based grommunio appliance.
All appliance commands are run directly on the grommunio appliance.
Public examples consistently use the neutral appliance domain https://mail.example.test.
Goal of this guide
This article puts grommunio platform into a practical context and explains the decisions that matter for a reliable implementation. By the end, you should know what to prepare, how to recognize a working state and what the next useful step is.
Prerequisites
An existing or planned grommunio environment, matching DNS names, TLS, administrative access and a clear target for mail, collaboration or operations.
Install grommunio 2026.06.1: from ISO to usable groupware
This article walks through a real installation ofgrommunio 2026.06.1in an isolated KVM lab VM. The goal is not just a booted system, but a usable groupware instance with Admin UI, Web login, first domain, first user, local test mail and reproducible operational checks.
The lab system is called mail.example.test and uses example.test as a synthetic mail domain. Replace these names with real DNS names you control in your own environment.
Screenshot: The grommunio boot menu of the verified 2026.06.1 installation ISO.
Boot the VM and select the target disk
Boot the VM from the grommunio installation ISO. The installer is intentionally compact: select the target disk, confirm the destructive installation and let the appliance image be written. Before confirming, make absolutely sure you are not selecting a data disk.
Screenshot: The installer shows the available disks and marks the system disk as target.
Screenshot: The installation deletes the selected target disk completely.
Screenshot: The appliance image is written to the target disk.
After completion, remove the ISO or switch the boot order back to the virtual disk. The freshly installed grommunio appliance then starts for the first time.
First boot: CUI, root password, hostname and network
On first boot, you land in the grommunio console user interface. The initial root password is unset. First set a root password, then verify hostname, IP configuration, gateway, DNS and time. On production systems, the hostname must return a complete FQDN.
Screenshot: First CUI start after image installation: setup has not been run yet.
Screenshot: The root password was set in the lab; production environments should use strong managed credentials.
Screenshot: The CUI shows host, network and service status before the actual grommunio setup.
hostnamectl hostname mail.example.testhostname -fip address showip routegetent hosts download.grommunio.comtimedatectl
In the lab, the appliance had an IP address after first boot, but DNS resolution had to be corrected before setup. Always verify the resolver before setup. If repository downloads fail, DNS is a common cause.
Run grommunio-setup
Start the setup wizard from the CUI. Core is the central groupware role. Chat, Meet, Files, Office and Archive are optional components and should only be enabled after resources, DNS, TLS and the operating model are clear.
Screenshot: Start of the guided grommunio setup wizard.
Screenshot: Core is mandatory; additional roles are selected deliberately.
For repository credentials, a lab can use empty values when community repositories are intended. Production environments should clarify subscription, update channel and maintenance model before setup.
Screenshot: Repository configuration: lab run without commercial credentials.
For small and medium single-node systems, the local database is the straightforward start. External databases are an architecture decision and should be planned together with high availability, backup, roles and operations.
Screenshot: Local database as the default selection for the lab installation.
FQDN, domain, relay host and TLS
The FQDN is the technical name of the mail server, for example mail.example.test. The primary mail domain is the domain of the mailboxes, for example example.test. These values can deliberately be different.
Screenshot: Server FQDN in setup.
Screenshot: Primary mail domain for the first mailboxes.
Configure a relay host only when outbound mail should go through a smart host. For direct delivery you need correct reverse DNS, SPF, DKIM, DMARC and sender reputation instead.
Screenshot: Relay host remains empty in the isolated lab.
A self-signed certificate is fine for the lab. In production, use Let’s Encrypt or your own certificate with matching Subject Alternative Names, typically for mail and autodiscover. Port 80 must be reachable for Let’s Encrypt.
Screenshot: TLS selection: self-signed is suitable only for labs and tests.
Screenshot: The setup wizard installs and configures the selected components.
After setup: check services, repositories and ports
After the wizard, do not only check whether the web interface loads. A mail server consists of services, ports, queues, databases and delivery paths. The first operational check belongs directly after installation.
systemctl --failedsystemctl --type=service --state=running | egrep 'grom|postfix|nginx|mariadb|redis|rspamd|saslauthd'ss -tulpnzypper lr -uzypper refreshzypper list-patchesfirewall-cmd --list-all
In the validated lab, grommunio-admin-api, grommunio-antispam, several gromox services, MariaDB, nginx, Postfix, Redis and saslauthd were running. The appliance is based on openSUSE Leap 16.0 and uses systemd-networkd. In this lab, the root filesystem was XFS.
Screenshot: The admin dashboard shows running services and system state.
Create domain and user
After setup, create a domain and at least one test user. You can do this in the Admin UI or through the CLI. The CLI is useful because it is reproducible and can later become part of automation.
grommunio-admin domain create example.test -u 25 --title "Example Test"grommunio-admin user create alex@example.test \--domain example.test \--lang en_US \--pop3-imap true \--privWeb true \--smtp truegrommunio-admin passwd alex@example.testgrommunio-admin user query username maildir pop3_imap smtp privWeb status
Screenshot: The lab domain example.test is visible in the admin UI.
Screenshot: The user alex@example.test was created in the lab.
Web login and local test mail
Log into grommunio Web with the test user. Then send a local test mail on the server and verify that it arrives in the mailbox. This does not test external delivery yet, but it validates the local acceptance and delivery path.
Screenshot: grommunio Web login of the freshly installed lab instance.
printf "From: admin@example.test\nTo: alex@example.test\nSubject: grommunio lab test mail\n\nThis test mail was generated locally.\n" \| sendmail -v alex@example.testgromox-mailqjournalctl -u postfix -u gromox-delivery -u gromox-delivery-queue --since "10 minutes ago"
Screenshot: The locally generated test mail is visible in the grommunio Web inbox.
DNS, DKIM, SPF, DMARC and external delivery
According to therelease notes, grommunio 2026.06.1 includes improvements around Admin Web, DKIM and DNS checks. For real delivery, you still need a deliberately planned mail domain.
MX points to the mail host.
A/AAAA records for mail and autodiscover match the environment.
PTR/reverse DNS matches the sending hostname.
SPF describes authorized senders.
DKIM is configured per domain and published in DNS.
DMARC defines policy and reporting.
An open relay test must be performed from outside trusted networks.
Generate the DKIM keypair in the Admin UI
Open the domain in the grommunio Admin UI, go to DNS health and open DKIM. The first dialog shows the current DNS state. On a new system, the external DKIM record is expected to be unresolved until you publish it.
Screenshot: The domain detail view shows DNS health for SPF, SRV, autodiscover and DKIM.
Screenshot: Before key generation, the DKIM DNS check still shows a public-key placeholder.
Click Generate DKIM keypair in the DKIM dialog. In the second dialog, Type rsa and Output mode dns are the usual choices for a TXT record. You can leave the selector empty; grommunio then uses the default selector dkim.
Screenshot: The keypair dialog generates the DKIM key for the selected domain.
After Generate, the Admin UI shows the public key for DNS and the required server-side follow-up steps. On the validated system, the private key was created as /var/lib/grommunio-admin-api/example.test.dkim.key. Publish only the TXT record in DNS; the private key stays on the server.
Screenshot: After generation, the Admin UI shows the DKIM TXT record and the server-side follow-up steps.
For signing, grommunio-antispam must be able to read the private key. The Admin UI shows the matching commands. In the validated grommunio 2026.06.1 appliance, grommunio-antispam runs as groas with group 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
Replace example.test with your real mail domain. Then verify DNS publication and an outbound test mail through an external recipient or mail testing service, because local delivery does not fully validate external DKIM signing.
The isolated lab did not evaluate real external delivery. That is intentional: a local NAT test says nothing about whether a server relays from the Internet or whether major providers accept mail from it.
Updates, backup and operations
Plan updates like you would for a production Linux and mail server: repository refresh, patch list, maintenance window, backup, snapshot, service check and rollback plan. grommunio documents its cadence separately in theupdate cycle documentation.
zypper refreshzypper list-patcheszypper patchsystemctl --failedgromox-mailq
Back up configuration, certificates, database and mail data consistently.
Test restore with a real procedure, not just on paper.
Monitor Postfix, gromox services, queue, disk space, certificate validity and mail delivery.
Keep Admin UI, web access and external ports deliberately separated and firewall rules understandable.
Final checklist
ISO verified and booted in an isolated VM.
Target disk selected deliberately and installation confirmed.
Root password, hostname, DNS, gateway and time checked.
grommunio-setup completed.
FQDN, primary mail domain, TLS mode and optional roles set deliberately.
Services, ports, repositories and firewall checked.
Domain and user created.
grommunio Admin and grommunio Web opened successfully.
Local test mail delivered and queue checked.
Open production tasks: real DNS zone, certificate, external delivery, backup, monitoring and update process.
Mailbox maintenance with gromox-cleaner
After the base installation, validate mailbox maintenance deliberately. The tested grommunio 2026.06.1 appliance ships gromox-cleaner.timer and the one-shot service gromox-cleaner.service. The cleaner purges soft-deleted messages after the configured retention and reclaims orphaned attachment files. It does not replace archiving or backup. It is also not merely an automatic trash-emptying task; it operates on Gromox mailbox and attachment data.
Soft delete means that a message is marked as deleted and remains recoverable within the retention window. Hard delete removes it from the recoverable mailbox data. In the installed version, the service uses the softdelete_purgetime directive from /etc/gromox/gromox.cfg; if it is not set, the unit falls back to 30d.
systemctl cat gromox-cleaner.servicesystemctl cat gromox-cleaner.timersystemctl status gromox-cleaner.timersystemctl list-timers --all | grep gromox-cleaner
Once retention, backup, restore and archive design are clear, enable the timer and run a manual validation. In the validated lab, the service completed successfully and reported no test objects to purge.
systemctl enable --now gromox-cleaner.timersystemctl start gromox-cleaner.servicejournalctl -u gromox-cleaner.service --since "10 minutes ago"systemctl list-timers gromox-cleaner.timer
Result Validation / Technical Acceptance
| Test area | Check | Expected result | Status |
|---|---|---|---|
| Installation | Check packages and components | The component is fully installed | PASS |
| Services | Check systemd services | The required services are active | PASS |
| Network | Check ports and URLs | The component is reachable through the intended paths | PASS |
| Core function | Run standalone test | The core function works before deeper integration | PASS |
| Authentication | Test SSO/login | Login works through the intended path or is intentionally not required | PASS or N/A |
| grommunio Web | Check integration from Web | The component is reachable or usable from grommunio Web | PASS or N/A |
| End-to-end | Test real user workflow | The full workflow is reproducibly successful | PASS |
| Restart | Restart services | The function remains available after service restart | PASS |
| Logs | Check relevant logs | No blocking errors in the validated flow | PASS |
Installation
- Check
- Check packages and components
- Expected result
- The component is fully installed
- Status
- PASS
Services
- Check
- Check systemd services
- Expected result
- The required services are active
- Status
- PASS
Network
- Check
- Check ports and URLs
- Expected result
- The component is reachable through the intended paths
- Status
- PASS
Core function
- Check
- Run standalone test
- Expected result
- The core function works before deeper integration
- Status
- PASS
Authentication
- Check
- Test SSO/login
- Expected result
- Login works through the intended path or is intentionally not required
- Status
- PASS or N/A
grommunio Web
- Check
- Check integration from Web
- Expected result
- The component is reachable or usable from grommunio Web
- Status
- PASS or N/A
End-to-end
- Check
- Test real user workflow
- Expected result
- The full workflow is reproducibly successful
- Status
- PASS
Restart
- Check
- Restart services
- Expected result
- The function remains available after service restart
- Status
- PASS
Logs
- Check
- Check relevant logs
- Expected result
- No blocking errors in the validated flow
- Status
- PASS
