|
|
.. _kubernetes:
|
|
|
|
|
|
Kubernetes setup
|
|
|
================
|
|
|
|
|
|
Prequisites
|
|
|
-----------
|
|
|
|
|
|
Structure
|
|
|
~~~~~~~~~
|
|
|
|
|
|
There’s chosen to have a double NGINX stack for Mailu, this way the main
|
|
|
ingress can still be used to access other websites/domains on your
|
|
|
cluster. This is the current structure:
|
|
|
|
|
|
- ``NGINX Ingress controller``: Listens to the nodes ports 80 & 443. We have chosen to have a double NGINX stack for Mailu.
|
|
|
- ``Cert manager``: Creates automatic Lets Encrypt certificates based on an ``Ingress``-objects domain name.
|
|
|
- ``Mailu NGINX Front daemonset``: This daemonset runs in parallel with the Nginx Ingress Controller and only listens on all E-mail specific ports (25, 110, 143, 587,...). It also listens on 80 and delegates the various http endpoints to the correct services.
|
|
|
- ``Mailu components``: All Mailu components (imap, smtp, security, webmail,...) are split into separate files to make them more handy to use, you can find the ``YAML`` files in this directory
|
|
|
|
|
|
What you need
|
|
|
~~~~~~~~~~~~~
|
|
|
|
|
|
- A working Kubernetes cluster (tested with 1.10.5)
|
|
|
- A working `cert-manager`_ installation
|
|
|
- A working nginx-ingress controller needed for the lets-encrypt
|
|
|
certificates. You can find those files in the ``nginx`` subfolder.
|
|
|
Other ingress controllers that support cert-manager (e.g. traefik)
|
|
|
should also work.
|
|
|
|
|
|
Cert manager
|
|
|
^^^^^^^^^^^^
|
|
|
|
|
|
The ``Cert-manager`` is quite easy to deploy using Helm when reading the
|
|
|
`docs`_. After booting the ``Cert-manager`` you’ll need a
|
|
|
``ClusterIssuer`` which takes care of all required certificates through
|
|
|
``Ingress`` items. We chose to provide a ``clusterIssuer`` so you can provide SSL certificates
|
|
|
for other namespaces (different websites/services), if you don't need this option, you can easily change this by
|
|
|
changing ``clusterIssuer`` to ``Issuer`` and adding the ``namespace: mailu-mailserver`` to the metadata.
|
|
|
An example of a production and a staging ``clusterIssuer``:
|
|
|
|
|
|
.. code:: yaml
|
|
|
|
|
|
# This clusterIssuer example uses the staging environment for testing first
|
|
|
apiVersion: certmanager.k8s.io/v1alpha1
|
|
|
kind: ClusterIssuer
|
|
|
metadata:
|
|
|
name: letsencrypt-stage
|
|
|
spec:
|
|
|
acme:
|
|
|
email: something@example.com
|
|
|
http01: {}
|
|
|
privateKeySecretRef:
|
|
|
name: letsencrypt-stage
|
|
|
server: https://acme-staging-v02.api.letsencrypt.org/directory
|
|
|
|
|
|
.. code:: yaml
|
|
|
|
|
|
# This clusterIssuer example uses the production environment
|
|
|
apiVersion: certmanager.k8s.io/v1alpha1
|
|
|
kind: ClusterIssuer
|
|
|
metadata:
|
|
|
name: letsencrypt-prod
|
|
|
spec:
|
|
|
acme:
|
|
|
email: something@example.com
|
|
|
http01: {}
|
|
|
privateKeySecretRef:
|
|
|
name: letsencrypt-prod
|
|
|
server: https://acme-v02.api.letsencrypt.org/directory
|
|
|
|
|
|
**IMPORTANT**: ``ingress.yaml`` uses the ``letsencrypt-stage`` ``clusterIssuer``. If you are ready for production,
|
|
|
change this field in ``ingress.yaml`` file to ``letsencrypt-prod`` or whatever name you chose for the production.
|
|
|
If you choose for ``Issuer`` instead of ``clusterIssuer`` you also need to change the annotation to ``certmanager.k8s.io/issuer`` instead of ``certmanager.k8s.io/cluster-issuer``
|
|
|
|
|
|
Deploying Mailu
|
|
|
---------------
|
|
|
|
|
|
All manifests can be found in the ``mailu`` subdirectory. All commands
|
|
|
below need to be run from this subdirectory
|
|
|
|
|
|
Personalization
|
|
|
~~~~~~~~~~~~~~~
|
|
|
|
|
|
- All services run in the same namespace, currently ``mailu-mailserver``. So if you want to use a different one, change the ``namespace`` value in **every** file
|
|
|
- Check the ``storage-class`` field in the ``pvc.yaml`` file, you can also change the sizes to your liking. Note that you need ``RWX`` (read-write-many) and ``RWO`` (read-write-once) storageclasses.
|
|
|
- Check the ``configmap.yaml`` and adapt it to your needs. Be sure to check the kubernetes DNS values at the end (if you use a different namespace)
|
|
|
- Check the ``ingress.yaml`` file and change it to the domain you want (this is for the kubernetes ingress controller to handle the admin, webmail, webdav and auth connections)
|
|
|
|
|
|
Installation
|
|
|
------------
|
|
|
|
|
|
Boot the Mailu components
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
To start Mailu, run the following commands from the ``docs/kubernetes/mailu`` directory
|
|
|
|
|
|
.. code-block:: bash
|
|
|
|
|
|
kubectl create -f rbac.yaml
|
|
|
kubectl create -f configmap.yaml
|
|
|
kubectl create -f pvc.yaml
|
|
|
kubectl create -f redis.yaml
|
|
|
kubectl create -f front.yaml
|
|
|
kubectl create -f webmail.yaml
|
|
|
kubectl create -f imap.yaml
|
|
|
kubectl create -f security.yaml
|
|
|
kubectl create -f smtp.yaml
|
|
|
kubectl create -f fetchmail.yaml
|
|
|
kubectl create -f admin.yaml
|
|
|
kubectl create -f webdav.yaml
|
|
|
kubectl create -f ingress.yaml
|
|
|
|
|
|
|
|
|
Create the first admin account
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
When the cluster is online you need to create you master user to access https://mail.example.com/admin
|
|
|
|
|
|
You can create it now manually, or have the system create it automatically.
|
|
|
|
|
|
If you want the system to create the admin user account automatically, see :ref:`admin_account`
|
|
|
about the environment variables needed (``INITIAL_ADMIN_*``).
|
|
|
Also, important, taking into consideration that a pod in Kubernetes can be stopped/rescheduled at
|
|
|
any time, you should set ``INITIAL_ADMIN_MODE`` to either ``update`` or ``ifmissing`` - depending on what you
|
|
|
want to happen to its password.
|
|
|
|
|
|
|
|
|
To create the admin user account manually, enter the main ``admin`` pod:
|
|
|
|
|
|
.. code-block:: bash
|
|
|
|
|
|
kubectl -n mailu-mailserver get po
|
|
|
kubectl -n mailu-mailserver exec -it mailu-admin-.... /bin/sh
|
|
|
|
|
|
And in the pod run the following command. The command uses following entries:
|
|
|
|
|
|
.. code-block:: bash
|
|
|
|
|
|
flask mailu admin root example.com password
|
|
|
|
|
|
- ``admin`` Make it an admin user
|
|
|
- ``root`` The first part of the e-mail address (ROOT@example.com)
|
|
|
- ``example.com`` the domain appendix
|
|
|
- ``password`` the chosen password for the user
|
|
|
|
|
|
|
|
|
Now you should be able to login on the mail account: https://mail.example.com/admin
|
|
|
|
|
|
|
|
|
Adaptations
|
|
|
-----------
|
|
|
|
|
|
Dovecot
|
|
|
~~~~~~~
|
|
|
|
|
|
- If you are using Dovecot on a shared file system (Glusterfs, NFS,...), you need to create a special override otherwise a lot of indexing errors will occur on your Dovecot pod.
|
|
|
- I also higher the number of max connections per IP. Now it's limited to 10.
|
|
|
|
|
|
Enter the dovecot pod:
|
|
|
|
|
|
.. code:: bash
|
|
|
|
|
|
kubectl -n mailu-mailserver get po
|
|
|
kubectl -n mailu-mailserver exec -it mailu-imap-.... /bin/sh
|
|
|
|
|
|
Create the file ``overrides/dovecot.conf``
|
|
|
|
|
|
.. code:: bash
|
|
|
|
|
|
vi /overrides/dovecot.conf
|
|
|
|
|
|
And enter following contents:
|
|
|
|
|
|
.. code:: bash
|
|
|
|
|
|
mail_nfs_index = yes
|
|
|
mail_nfs_storage = yes
|
|
|
mail_fsync = always
|
|
|
mmap_disable = yes
|
|
|
mail_max_userip_connections=100
|
|
|
|
|
|
Save and close the file and delete the imap pod to get it recreated.
|
|
|
|
|
|
.. code:: bash
|
|
|
|
|
|
kubectl -n mailu-mailserver delete po/mailu-imap-....
|
|
|
|
|
|
Wait for the pod to recreate and you're online!
|
|
|
Happy mailing!
|
|
|
|
|
|
.. _here: https://github.com/hacor/Mailu/blob/master/core/postfix/conf/main.cf#L35
|
|
|
.. _cert-manager: https://github.com/jetstack/cert-manager
|
|
|
.. _docs: https://cert-manager.readthedocs.io/en/latest/getting-started/2-installing.html
|
|
|
|
|
|
Imap login fix
|
|
|
~~~~~~~~~~~~~~
|
|
|
|
|
|
If it seems you're not able to login using IMAP on your Mailu accounts, check the logs of the imap container to see whether it's a permissions problem on the database.
|
|
|
This problem can be easily fixed by running following commands:
|
|
|
|
|
|
.. code:: bash
|
|
|
|
|
|
kubectl -n mailu-mailserver exec -it mailu-imap-... /bin/sh
|
|
|
chmod 777 /data/main.db
|
|
|
|
|
|
If the login problem still persists, or more specific, happens now and then and you see some Auth problems on your webmail or mail client, try following steps:
|
|
|
|
|
|
- Add ``auth_debug=yes`` to the ``/overrides/dovecot.conf`` file and delete the pod in order to start a new one, which loads the configuration
|
|
|
- Depending on your network configuration you could still see some ``allow_nets check failed`` results in the logs. This means that the IP is not allowed a login
|
|
|
- If this is happening your network plugin has troubles with the Nginx Ingress Controller using the ``hostNetwork: true`` option. Known cases: Flannel and Calico.
|
|
|
- You should uncomment ``POD_ADDRESS_RANGE`` in the ``configmap.yaml`` file and add the IP range of your pod network bridge (the range that sadly has failed the ``allowed_nets`` test)
|
|
|
- Delete the Admin pod and wait for it to restart
|
|
|
|
|
|
.. code:: bash
|
|
|
|
|
|
kubectl -n mailu-mailserver get po
|
|
|
kubectl -n mailu-mailserver delete po/mailu-admin...
|
|
|
|
|
|
Happy mailing!
|