Open the ``.env`` file and review the following variable settings:
- Change ``ROOT`` if you have your setup directory in a different location then ``/mailu``.
- Check ``VERSION`` to reflect the version you picked. (``master`` or ``1.5``).
Make sure to read the comments in the file and instructions from the :ref:`common_cfg` section.
TLS certificates
TLS certificates
````````````````
````````````````
Set the ``TLS_FLAVOR`` to one of the following
Sets the ``TLS_FLAVOR`` to one of the following
values:
values:
- ``cert`` is the default and requires certificates to be setup manually;
- ``cert`` is the default and requires certificates to be setup manually;
@ -59,7 +47,7 @@ values:
Bind address
Bind address
````````````
````````````
Modify ``BIND_ADDRESS4`` and ``BIND_ADDRESS6`` to match the public IP addresses assigned to your server. For IPv6 you will need the ``<global>`` scope address.
The bind addresses need to match the public IP addresses assigned to your server. For IPv6 you will need the ``<global>`` scope address.
You can find those addresses by running the following:
You can find those addresses by running the following:
@ -81,56 +69,17 @@ you would simply like the server to listen on all interfaces, use ``0.0.0.0`` an
Some of Mailu features are not used by every user and are thus not enabled in a
After downloading the files, open ``mailu.env`` and review the variable settings.
default configuration.
Make sure to read the comments in the file and instructions from the :ref:`common_cfg` page.
A Webmail is a Web interface exposing an email client. Mailu webmails are
bound to the internal IMAP and SMTP server for users to access their mailbox through
the Web. By exposing a complex application such as a Webmail, you should be aware of
the security implications caused by such an increase of attack surface. The ``WEBMAIL``
configuration option must be one of the following:
- ``none`` is the default value, no Webmail service will be exposed;
- ``roundcube`` will run the popular Roundcube Webmail;
- ``rainloop`` will run the popular Rainloop Webmail.
The administration interface is not exposed on the public address by default,
you will need to set the ``ADMIN`` variable accordingly:
- ``true`` will expose the admin interface in ``/admin``;
- ``false`` (or any other value) will disable this behaviour.
A Webdav server exposes a Dav interface over HTTP so that clients can store
contacts or calendars using the mail account. This can be enabled using the `WEBDAV`
setting. The configuration option must be one of the following:
- ``none`` is the default value, no webdav service will be exposed;
- ``radicale`` exposes the radicale Webdav service.
An antivirus server helps fighting large scale virus spreading campaigns
that leverage e-mail for initial infection. This can be setup using the ``ANTIVIRUS``
setting. The configuration option must be one of the following:
- ``none`` disables antivirus checks;
- ``clamav`` is the default values, the popular ClamAV antivirus is enabled.
Make sure that you have at least 1GB of memory for ClamAV to load its signature
database.
If you run Mailu behind a reverse proxy you can use ``REAL_IP_HEADER`` and
``REAL_IP_FROM`` to set the values of respective the Nginx directives
``real_ip_header`` and ``set_real_ip_from``. The ``REAL_IP_FROM`` configuration
option is a comma-separated list of IPs (or CIDRs) of which for each a
``set_real_ip_from`` directive is added in the Nginx configuration file.
Finish setting up TLS
Finish setting up TLS
---------------------
---------------------
Mailu relies heavily on TLS and must have a key pair and a certificate
Mailu relies heavily on TLS and must have a key pair and a certificate
available, at least for the hostname configured in the ``.env`` file.
available, at least for the hostname configured in the ``mailu.env`` file.
If you set ``TLS_FLAVOR`` to ``cert`` or ``mail`` then you must create a ``certs`` directory
If you set ``TLS_FLAVOR`` to ``cert`` or ``mail`` then you must create a ``certs`` directory
in your root path and setup a key-certificate pair there:
in your root path and setup a key-certificate pair there:
@ -154,3 +103,5 @@ Finally, you must create the initial admin user account:
docker-compose exec admin flask mailu admin me example.net password
docker-compose exec admin flask mailu admin me example.net password
This will create a user named ``me@example.net`` with password ``password`` and administration privileges. Connect to the Web admin interface and change the password to a strong one.
This will create a user named ``me@example.net`` with password ``password`` and administration privileges. Connect to the Web admin interface and change the password to a strong one.
..note:: It is vitally important that either a user with the same email as ``POSTMASTER`` in your ``mailu.env`` exists, or you remember to create an alias with this name after you log in. All kinds of strange errors will occur as a result of not doing so!
Docker swarm enables replication and fail-over scenarios. As a feature, if a node dies or goes away, Docker will re-schedule it's containers on the remaining nodes.
In order to take this decisions, docker swarm works on a consensus between managers regarding the state of nodes. Therefore it recommends to always have an uneven amount of manager nodes. This will always give a majority on either halve of a potential network split.
### Storage
On top of this some of Mailu's containers heavily rely on disk storage. As noted below, every host will need the same dataset on every host where related containers are run. So Dovecot IMAP needs `/mailu/mail` replicated to every node it *may* be scheduled to run. There are various solutions for this like NFS and GlusterFS.
### When disaster strikes
So imagine 3 swarm nodes and 3 GlusterFS endpoints:
```
node-A -> gluster-A --|
node-B -> gluster-B --|--> Single file system
node-C -> gluster-C --|
```
Each node has a connection to the shared file system and maintains connections between the other nodes. Let's say Dovecot is running on `node-A`. Now a network error / outage occurs on the route between `node-A` and the remaining nodes, but stays connected to the `gluster-A` endpoint. `node-B` and `node-C` conclude that `node-A` is down. They reschedule Dovecot to start on either one of them. Dovecot starts reading and writing its indexes to the **shared** filesystem. However, it is possible the Dovecot on `node-A` is still up and handling some client requests. I've seen cases where this situations resulted in:
- Retained locks
- Corrupted indexes
- Users no longer able to read any of mail
- Lost mail
### It gets funkier
Our original deployment also included `main.db` on the GlusterFS. Due to the above we corrupted it once and we decided to move it to local storage and restirct the `admin` container to that host only. This inspired us to put some legwork is supporting different database back-ends like MySQL and PostgreSQL. We highly recommend to use either of them, in favor of sqlite.
### Conclusion
Although the above situation is less-likely to occur on a stable (local) network, it does indicate a failure case where there is a probability of data-loss or downtime. It may help to create redundant networks, but the effort might be too much for the actual results. We will need to look into better and safer methods of replicating mail data. For now, we regret to have to inform you that Docker swarm deployment is **unstable** and should be avoided in production environments.
-- @muhlemmer, 17th of January 2019.
## Prequisites
## Prequisites
### Swarm
### Swarm
@ -250,3 +288,44 @@ Run the follwoing command:
```bash
```bash
core@coreos-01 ~ $ docker stack rm mailu
core@coreos-01 ~ $ docker stack rm mailu
```
```
## Notes on unbound resolver
In Docker compose flavor we currently have the option to include the unbound DNS resolver. This does not work in Docker Swarm, as it in not possible to configure any static IP addresses. There is an [open issue](https://github.com/moby/moby/issues/24170) for this at Docker. However, this doesn't seem to move anywhere since some time now. For that reasons we've chosen not to include the unbound resolver in the stack flavor.
If you still want to benefit from Unbound as a system resolver, you can install it system-wide. The following procedure was done on a Fedora 28 system and might needs some adjustments for your system. Note that this will need to be done on every swarm node. In this example we will make use of `dnssec-trigger`, which is used to configure unbound. When installing this and running the service, unbound is pulled in as dependency and does not need to be installed, configured or run separately.
Install required packages(unbound will be installed as dependency):
<p>The unbound resolver enables Mailu to do DNSsec verification, DNS root lookups and caching. This also helps the antispam service not to get blocked by the public or ISP DNS servers.</p>
Tim Möhlmann
6 years ago