Was genau ist Mailcow?

Mailcow ist eine Opensource Sammlung von Softwarepaketen (Dovecot, ClamAV, Memcached, Redis, MySQL, Unbound, PHP-FPM, Postfix, Lets Encrypt, Nginx, Rmilter, Rspamd, SOGo, Fail2ban) die zusammen mit dem mailcow UI einen sehr gut funktionierenden Mailserver darstellen. Der Entwickler nutzt diese Software selbst um damit einen Mailhosting anzubieten, was sicherlich mit ein Grund ist warum die Software an vielen Stellen wirklich praktisch und praxisnah umgesetzt wurde.

Nur noch per Docker

Seit einigen Monaten wird von mailcow nur noch als Docker Variante angeboten und weiterentwickelt.

In wenigen Minuten installiert

Dank den Installationsskript des Entwicklers ist Mailcow in weniger als 5 Minuten installiert. Jedoch muss vorher sichergestellt sein dass keine andere Mailsoftware auf dem System vorhanden ist.

Wir beginnen mit der Installation von Docker

curl -sSL https://get.docker.com/ | sh

und Docker-Compose

curl -L https://github.com/docker/compose/releases/download/$(curl -Ls https://www.servercow.de/docker-compose/latest.php)/docker-compose-$(uname -s)-$(uname -m) > /usr/local/bin/docker-compose

chmod +x /usr/local/bin/docker-compose

Als nächstes klonen wir das Mailcow Git Repo (Ich navigiere dazu immer nach /opt)

git clone https://github.com/mailcow/mailcow-dockerized && cd mailcow-dockerized

Nun noch die Konfiguration anpassen

./generate_config.sh

Und dann können wir auch schon die Docker Images pullen

docker-compose pull

Und das System starten

docker-compose up -d

Mailcow UI ist nun per HTTPS erreichbar. Für weitere Einstellungen (davon gibt es zahlreiche) empfiehlt es sich die sehr gute Doku zu lesen.

Google sind jedoch auch niedrige Ladezeiten wichtig, leider ist es jedoch so das eine HTTPS Verbindung per se mehr Rechenleistung benötigt um die Verbindung zum Browser zu verschlüsseln. Besonders aufgefallen ist mir der langsame SSL Handshake. Also der Abschnitt des Verbindungsaufbaus in dem sich Server und Browser auf eine Technologie einigen. Das lag an den zahlreichen unterstützen SSL Algorithmen. Manchmal ist halt doch weniger mehr.

Daher bietet mein nginx Webserver nun nur noch die SSL Algorithmen an die von Cloudflare empfohlen werden und somit konnte ich auch die Ladezeiten wieder verbessern:

ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers                 EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
ssl_prefer_server_ciphers   on;

In dieser Anleitung beschreibe ich wie nextCloud (der moderne nachfolger von Owncloud) auf einem frischen Debian Stretch (Debian 9) oder auch Debian Jessie (Debian 8) installiert wird. Dazu verwende ich nginx als Webserver, MySQL und php7. Warum nginx und php7? Dies Software Pakete sind auf hohe Performance ausgelegt und werden auch aktiv von den Entwicklern gepflegt. Dazu sichern wir unseren Webserver noch mit einem kostenlosen SSL Zertifikat von Lets Encrypt ab und konfigurieren nginx so dass es nur aktuelle Sicherheitseinstellungen verwendet und aktivieren zusätzlich HTTP/2. Damit haben wir ein modernes, sicheres und schnelles Setup das perfekt für nextCloud geeignet ist.

Diese Anleitung kann auch für einen Raspberry Pi verwendet werden.

Voraussetzungen
Als Basis gehe ich von einem frisch installiertem Debian 8 Jessie aus, auf das auch bereits die Domain die du verwenden möchtest zeigt.

Grundarbeiten
Bei neuen Servern kümmere ich mich zu aller erst immer um eine hübsche Prompt, da macht das arbeiten gleich mehr Spass. Das habe ich hier bereits beschrieben. Wer das nicht möchte kann diesen Schritt auch einfach überspringen.

Als nächstes kümmere ich mich darum dass das System auf den aktuellsten Stand ist

apt-get update && apt-get upgrade && apt-get dist-upgrade

Je nachdem mit welchem Texteditor man arbeiten möchte muss dieser nun installiert werden, in meinem Fall ist das vim:

apt-get install vim-nox

Nun richten wir die Paketquellen ein. Unter Debian bietet sich die Nutzung von dotdeb.org an, da dort alle benötigten Pakete in einer aktuellen Fassung vorliegen. Die Einbindung davon wird hier beschrieben, lässt sich aber auch ganz kurz so zusammenfassen:

Folgende zwei Zeilen müssen in die /etc/apt/sources.list Datei hinzugefügt werden:

deb http://packages.dotdeb.org jessie all
deb-src http://packages.dotdeb.org jessie all

Danach muss noch der Schlüssel der neuen Paketquelle in unser System eingespielt werden. Laden können wir den Schlüssel mit

wget https://www.dotdeb.org/dotdeb.gpg

Und einspielen mit

apt-key add dotdeb.gpg

Lets Encrypt
Nun kümmern wir uns um das kostenlose SSL Zertifikat. Das lässt sich am einfachsten mit dem **certbot** beantragen, jedoch müssen wir dazu die Backports in unseren Paketquellen aktivieren. Hierzu müssen wir noch einmal die /etc/apt/sources.list Datei um folgende Zeile erweitern:

deb http://ftp.debian.org/debian jessie-backports main

Jetzt müssen wir die Paketquellen neu auslesen

apt-get update

Und dann kann certbot installiert werden

apt-get install certbot -t jessie-backports

Für den nächsten Schritt ist es zwingend nötig das bereits eine Domain auf den Server zeigt. Denn nun beantragen wir das SSL Zertifikat von Let’s Encrypt:

certbot certonly

Dieser Befehl leitet durch die Zertifikatsbeantragung. Es muss eine Mailadresse und die entsprechende Domain eingetragen werden. Hat alles funktioniert, beendet sich certbot mit einer Erfolgsmeldung.

PHP7

PHP7 kann recht schnell installiert werden. Dazu führen wir einfach folgenden Befehl aus:

apt-get install php7.0-fpm php7.0-gd php7.0-mysql php7.0-curl php7.0-xml php7.0-zip php7.0-intl php7.0-mcrypt php7.0-mbstring php7.0-bz2

Dadurch wird php7 mit allen erforderlichen Erweiterungen installiert.

NGINX

Die Installation von nginx wird mit folgendem Befehl angestoßen:

apt-get install nginx

Als nächstes müssen wir nginx konfigurieren. Wir legen Wert darauf dass unser Webserver nur aktuelle Sicherheitsalgorythmen verwendet, daher müssen wir vorher noch kurz einen Diffie-Hellman Schlüssel erzeugen:

mkdir -p /etc/ssl/private
chmod 710 /etc/ssl/private
cd /etc/ssl/private
openssl dhparam -out dhparams.pem 2048
chmod 600 dhparams.pem

Nun zur eigentlichen Konfiguration des nginx. Dazu öffnen wir folgende Datei und ersetzen den Inhalt komplett: /etc/nginx/sites-enabled/default
Der neue Dateiinhalt: Link (dabei muss „deine.cloud“ durch deine Domain ersetzt werden)

Hat man die Datei entsprechend angepasst, kann nginx neu gestartet werden:

/etc/init.d/nginx restart

Unter deiner Domain sollte nextcloud nun bereits erreichbar sein. Jedoch müssen wir erst noch MySQL installieren, da wir für nextcloud eine Datenbank benötigen.

MYSQL

Installiert wird MySQL mit folgendem Befehl. Während der Installation wird man nach dem root Passwort gefragt welches man sich unbedingt merken/notieren sollte!

apt-get install mysql-server mysql-client

Als nächstes sichern wir die MySQL Installation ab

mysql_secure_installation

Nun brauchen wir noch einen eigenen Datenbank Benutzer und Datenbank für unsere Nextcloud Installation

Dazu loggen wir uns als root mit dem bei der Installation vergebenem Passwort ein:

mysql -u root -p

Zum Erstellen einer eigenen Datenbank namens „nextclouddb“ nutzen wir folgenden Befehl

create database nextclouddb;

Dann erstellen wir einen Benutzer den wir „nextclouduser“ nennen. Wichtig! „password“ müssen wir durch ein neues Passwort ersetzen.

create user 'nextclouduser'@'localhost' identified by 'password';

Zu letzt braucht der gerade erstellte Benutzer noch Berechtigungen auf die gerade erstellte Datenbank. Auch hier müssen wir das Passwort ersetzen.

grant all on nextclouddb.* to 'nextclouduser' identified by 'password';

Nun haben wir die Datenbank eingerichtet und können den MySQL Client schließen.

exit

Jetzt die eigentliche Nextcloud Installation

Wir sind fast fertig. Es muss nur noch nextcloud installiert werden, dazu laden wir uns die aktuelle Version von Nextcloud in unser Webserververzeichnis.

wget https://download.nextcloud.com/server/releases/nextcloud-13.0.0.zip

unzip nextcloud-13.0.0-zip

Die Dateien noch ins Webverzeichnis kopieren und wir können die Installation im Webbrowser starten.

Wer es noch nicht getan hat, kann über diese Seite Gitlab installieren. Vorraussetzung für die weiteren Schritte ist dass Gitlab isntalliert wurde und über Port 80 erreichbar ist.

Als nächstes installieren wir git, da wir das benötigen um den Lets Encrypt Client zu nutzen

cd /root  
git clone https://github.com/letsencrypt/letsencrypt

Bevor wir das Zertifikat beantragen können, wird noch eine Lets Encrypt Konfiguration erstellt in der wir alle wichtigen Daten definieren.

mkdir letsencrypt-config  
vi letsencrypt-config/gitlab.ini

Der Inhalt der Datei:

# Lets Encrypt Config für gitlab

# wir wollen den webroot Authenticator nutzen. 
authenticator = webroot
webroot-path = /var/www/letsencrypt

# die Domain unter der Gitlab aufrufbar ist
domains = gitlab.yourdomain.de

# die eigene Mailadresse mit der das Zertifikat beantragt wird
email = your@email.de

# wir wollen einen 4096 bit RSA key anstatt eines 2048 keys
rsa-key-size = 4096

Nun müssen wir noch das Verzeichnis anlegen dass für die webroot Authentifizierung verwendet wird

mkdir -p /var/www/letsencrypt

Als nächstes passen wir die gitlab Konfiguration an, damit diese unsere neuen Zertifikate nutzt. Dazu öffnen wir die Datei **/etc/gitlab/gitlab.rb** und ändern folgende Werte. Dabei muss auch darauf geachtet werden dass die entsprechenden Zeilen nicht auskommentiert sind.

nginx['enable'] = true
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate']= "/etc/letsencrypt/live/gitlab.yourdomain.de/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/gitlab.yourdomain.de/privkey.pem"

Folgende Zeile muss neu eingefügt werden

nginx['custom_gitlab_server_config']="location ^~ /.well-known {\n alias /var/www/letsencrypt/.well-known;\n}\n"

Damit die SSL Beantragung funktioniert muss Gitlab nun erstmal rekonfiguriert werden.

gitlab-ctl reconfigure

Als nächstes nutzen wir die vorhin angelegte Lets Encrypt Konfiguration um das SSL Zertfikat zu erstellen

/root/letsencrypt/letsencrypt-auto certonly -c /root/letsencrypt-config/gitlab.ini

Beim ersten Aufruf werden vor der eigentlichen SSL Beantragung noch evtl. fehlende Abhänigkeiten installiert.

Nun können wir wieder die gitlab Konfiguration unter /etc/gitlab/gitlab.rb öffnen und die URL auf https ändern.

external_url 'https://gitlab.yourdomain.de'

Das war es auch schon. Gitlab muss abschließen noch rekonfiguriert werden:

gitlab-ctl reconfigure

Ab nun ist die Gitlab Installation unter https erreichbar.

Lets Encrypt Zertifikate sind immer nur 90 Tage gültig. Damit das Zertifikat jeden Monat automatisch erneuert wird, richten wir einen Cronjob ein der sich darum kümmert:

0 0 1 * * /root/.local/share/letsencrypt/bin/letsencrypt certonly -c /root/letsencrypt-config/gitlab.ini --renew-by-default

Vorraussetzung ist ein vom Internet erreichbarer Port 80 eueres Webservers sowie ein installiertes git. Letzteres kann per „**apt-get install git**“ einfach nachinstalliert werden.

Ist das erledigt wechseln wir in das root Verzeichnis

cd /root/

und clonen das acme Repository

git clone https://github.com/Neilpang/acme.sh.git acme-master

nun erstellen wir das Verzeichnis in dem die Konfiguration abgelegt wird und wechseln in das gerade geclonte Verzeichnis

mkdir /etc/pve/.le
cd /root/acme-master

Mit folgendem Befehl legen wir unsere Konfiguration an. Hierbei müssen wir unsere E-Mail Adresse angeben über die wir zukünftig benachrichtigt werden wenn das Zertifikat abläuft

./acme.sh --install --accountconf /etc/pve/.le/account.conf --accountkey /etc/pve/.le/account.key --accountemail "meine@email.com"

Nun können wir testweise versuchen das Zertifikat zu beantragen. Da es ein wöchentliches Limit gibt wie häufig ein Zertifikat beantragt werden darf, empiehlt es sich zuerst nur einen Testantrag zu machen. Hier muss die von dir verwendete Domain eingesetzt werden:

./acme.sh --issue --standalone --keypath /etc/pve/local/pveproxy-ssl.key --fullchainpath /etc/pve/local/pveproxy-ssl.pem --reloadcmd "systemctl restart pveproxy" -d $DOMAIN --test

Sollte das funktioniert haben können wir den gleichen Befehl nochmal abschicken, diesmal aber statt mit dem –test Flag mit einem –force Flag. So wird sichergestellt dass das gerade testweise Zertifikat durch das neue richtige Zertifikat ersetzt wird, obowhl es noch nicht abgelaufen ist:

./acme.sh --issue --standalone --keypath /etc/pve/local/pveproxy-ssl.key --fullchainpath /etc/pve/local/pveproxy-ssl.pem --reloadcmd "systemctl restart pveproxy" -d $DOMAIN --force

Das war es auch schon. Die Weboberfläche von Proxmox ist nun mit einem gültigem Zertifikat abgesichert. Außerdem wurde ein Cronjob angelegt der das Zertifikat zukünftig automatisch erneuert:

0 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null