Admin API TLS configuration¶
Since the process of the Admin API is relevant for the initial provisioning stage, it is per default made available via port 8080 and unencrypted. As soon as the setup process has finished, it is advised to switch to a TLS-based configuration.
The shipped grommunio configuration files are prepared for setting up TLS configuration with the existing configuration. To activate the TLS configuration of grommunio-admin, execute the following steps:
ln -s /etc/grommunio-common/nginx/ssl_certficate.conf /etc/grommunio-admin-common/nginx-ssl.conf
This assumes the configuration of the TLS certificates has been installed successfullly by the provisioning of grommunio Setup.
As a final step, uncomment the prepared configuration directive in the last line
of the configuration file
vhost_traffic_status_zone shared:vhost_traffic_status:8m; # If you want to disable HTTP, take note that your configuration might # need adaptation in the admin api configuration in # config.yaml -> options: -> vhosts: -> local: include /usr/share/grommunio-admin-common/nginx.conf; # Uncomment the following line to enable TLS for the admin interface. # Make sure to create /etc/grommunio-admin-common/nginx-ssl.conf # containing the certificate configuration include /usr/share/grommunio-admin-common/nginx-ssl.conf;
After a subsequent successful configuration check of the webserver configuration, nginx may be restarted, and the Admin API is available on port 8443, e.g. https://mail.example.com:8443 :
# nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful # systemctl restart nginx
Note that by restarting the webserver, existing connections are terminated.
For the operation of grommunio, the use of TLS-based security is mandatory. With TLS certificates in place, any communication with grommunio’s services are protected by state-of-the-art encryption, which is mandatory for many clients and protocols.
If following the grommunio Setup path, also see also https://docs.grommunio.com/admin/administration.html#tls-configuration. Throughout the installation process, the administrator has multiple choices for TLS-based installation. For seamless operation, it is recommended to have a basic understanding of PKI concepts and the X.509 standard for certificates. Generally, grommunio uses PEM-encoded certificates.
If certificates need to be replaced, the certificates used by grommunio can be found by default in the following locations:
/etc/grommunio-common/ssl/server-bundle.pem(certificate bundle including certificate authority)
By changing the certificates, all services using these certificates need to be restarted for the certificate to be used.
If Let’s Encrypt has been chosen for installation, the service
grommunio-certbot-renew.timer automatically runs weekly to perform any new
certificate request. The status of the timer service can be checked with:
systemctl status grommunio-certbot-renew.timer
During every installation of grommunio Appliance, it attempts to connect to the community repository of grommunio. This way, community updates are directly available to community users and can update the Appliance accordingly. Furthermore, grommunio provides the operating system repositories which provide state-of-the-art packages with latest updates available to the Linux operating system based on openSUSE Leap, a binary compatible distribution of SUSE Linux Enterprise Server.
Community repositories are delivered on a best-effort basis and are not supported. While grommunio welcomes community members to use grommunio, the software distribution available with the subscription repositories include production-relevant benefits. Subscription repositories (available only with a valid subscription) include quality-tested packages, hotfixes and extra features not available in community repositories.
For package management, the grommunio Appliances use
zypper. Zypper is the
package manager primarily used by SUSE-based distributions and is therefore
default for the grommunio Appliances. Zypper has many similarities to other
well-known package managers, such as
The default repository file,
/etc/zypp/repos.d/grommunio.repo is shipped
with the following contents:
[grommunio] enabled=1 autorefresh=1 baseurl=https://download.grommunio.com/community/packages/openSUSE_Leap_15.3/?ssl_verify=no type=rpm-md
The default configuration does not verify SSL/TLS certificates intentionally. This enables support for:
configuration-less automated proxy environments with SSL/TLS interception
repository mirroring with selected partners and customers (hosting, large installations)
The integrity of all packages is secured by signatures on all packages distributed by grommunio with the grommunio GPG key, of which the public key is available at https://download.grommunio.com/community/packages/RPM-GPG-KEY-grommunio.
Your subscription credentials are provided to you via your grommunio partner and enables the availability of production-grade grommunio packages. These packages are quality-tested and only available to subscription customers.
To update your grommunio appliance with the most recent available updates, execute the following steps:
# zypper ref Repository 'base' is up to date. Repository 'debug' is up to date. Repository 'debug-update' is up to date. Repository 'grommunio' is up to date. Repository 'update' is up to date. All repositories have been refreshed. # zypper up Loading repository data... Reading installed packages... The following package is going to be upgraded: grommunio-admin-web 1 package to upgrade. Overall download size: 1.8 MiB. Already cached: 0 B. After the operation, additional 696.0 B will be used. Continue? [y/n/v/...? shows all options] (y): Retrieving package grommunio-admin-web-188.8.131.52.6c8842f-lp153.1.1.noarch (1/1), 1.8 MiB ( 15.0 MiB unpacked) Retrieving: grommunio-admin-web-184.108.40.206.6c8842f-lp153.1.1.noarch.rpm ....................................[done] Checking for file conflicts: ............................................................................[done] (1/1) Installing: grommunio-admin-web-220.127.116.11.6c8842f-lp153.1.1.noarch ..................................[done]
After the installation/update of some packages, services are not always
restarted automatically due to the nature of the potential implications of such
a restart during a package installation. For packages that have been updated
however, a manual restart of the service is recommended. The command
-s lists such services that should be restarted at a convenient
time to have the new update in place. An example of such an operation is:
# zypper ps -s zypper ps -s The following running processes use deleted files: PID | PPID | UID | User | Command | Service -----+------+-----+------+-----------+---------- 1553 | 1 | 0 | root | saslauthd | saslauthd You may wish to restart these processes. See 'man zypper' for information about the meaning of values in the above table. No core libraries or services have been updated since the last system boot. Reboot is probably not necessary. # systemctl restart saslauthd
Backup & Disaster Recovery¶
grommunio fully supports snapshot-based backups of all modern filesystems and/or appliances. The snapshot mechanisms of the following filesystems, backup solutions or storage systems are tested and supported:
Arcserve Unified Data Protection (UDP)
Amazon EBS snapshots
Azure VM snapshots
Docker-based snapshots (docker checkpoint)
Google cloud persistent disk snapshots
Kubernetes volume snapshots
LXC-based snapshots (lxc snapshot)
With the snapshot mechanism provided by the storage provider, snapshots can be
easily used to backup and restore entire mailboxes in a matter of seconds. For
restoring mailboxes to another mailbox’s identity, it is recommended to ensure
the mailbox is not in active use (such as mobile devices, profile
After the restore operation has completed, it is advised to restart the services
gromox-midb to invalidate any existing runtime caches:
# systemctl restart gromox-http # systemctl restart gromox-midb
To backup your grommunio installation, the following backup artifacts are relevant (per default):
grommunio Groupware (gromox):
/var/lib/gromox/user: directory hierarchy for private mailboxes
/var/lib/gromox/domain: directory hierarchy for public mailboxes (public folders)
/var/lib/gromox/user/account@domain: individual mailbox container
File backup of
File backup of
/etc/nginx(if any non-standard configuration changes have been made)
File backup of
/etc/php7/fpm/php-fpm.d(if any non-standard configuration changes have been made)
File backup of
/etc/letsencrypt(if Let’s Encrypt certificates are used)
File backup of
/etc/postfix(if any non-standard configuration changes have been made)
By using grommunio-dbconf, many file-based backups are not required. This is because dbconf stores configuration directives within the main grommunio database.
Backup the grommunio databases
grofiles using standard procedures.
Most backup solutions provide MySQL database backup agents for easy integration.
For detailed backup options of your MySQL databases, refer to:
https://dev.mysql.com/doc/refman/8.0/en/backup-types.html. If in doubt, the
(https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html can create single
SQL backup files of databases. A manual MySQL backup dump can
be issued with:
mysqldump --single-transaction --routines --triggers --events --add-drop-database > grommunio-mysql-backup.sql
Since grommunio works entirely on the basis of transactions, any file-based backup is consistent at sync time, as long as it utilizes a “deltasync” based operation. It is also possible to sync files from the original operating location to a remote/mounted location for disk-to-disk backup scenarios, if so desired. With rsync, the grommunio Appliance offers a simple tool to synchronize data for this backup method. A manual file backup based on deltasync functionality by rsync can be issued with:
rsync -HPavS <from-directory> <to-directory>