Schlagwort: Docker

Mailserver mit Postfix und Dovecot – Vorwort

Der Mailserver für die Domains customieze.de und customieze.com läuft jetzt seit ein paar Wochen, und ich will das Prozedere natürlich auch hier nochmal dokumentieren.

Das sollte der Mailserver alles können:

  • E-Mails für Empfänger in den Domains customieze.de und customieze.com per SMTP von anonymen Clients (z.B. von anderen Mailservern) annehmen
  • E-Mails für beliebige Empfänger von authentifizierten Clients per SMTP annehmen und ebenfalls per SMTP an den Mailserver des Empfängers weitergeben
  • Abruf der empfangenen E-Mails per IMAP
  • TLS mit Zertifikaten von Let’s Encrypt
  • Tags für E-Mail-Adressen, damit man mit Adressen wie ich+dubioseseite@customieze.de einfacher herausfinden kann, wer die E-Mail-Adresse verkauft hat

Das ganze Konstrukt soll auf Postfix und Dovecot basieren und natürlich – wie der ganze Rest auch – in Docker-Containern laufen. Einen Spamfilter gibt es erstmal nicht, der sollte sich aber bei Bedarf nachrüsten lassen.

Rückblickend kann ich nur sagen: E-Mail ist kein Ponyhof!

Den Weg zum aktuellen Zustand werde ich in den nächsten Blog-Beiträgen detaillierter beschreiben.

IPv6: Jetzt erst recht!

IPv4, IPv6, SSL und Docker – sehr viel verrückter wird es nicht!

Momentan sieht’s so aus: Die Ports 80 (http) und 443 (https) werden über den sogenannten „Userland Proxy“ von Docker auf allen Netzwerk-Interfaces des Servers veröffentlicht. Die SSL-Terminierung übernimmt Nginx. Für IPv4-Clients ist alles super, für IPv6-Clients wird der jeweilige Container intern aber per IPv4 kontaktiert. Das ist im Log des Reverse Proxy zu sehen:

Weiterlesen „IPv6: Jetzt erst recht!“ →

Gigantische Uploads

Die aktuelle Standard-Konfiguration von WordPress lässt nur eine Upload-Größe von 2 MiB zu. Das ist natürlich (!) zu wenig, wenn Dana mit ihren riesigen Fotos ankommt.

Die richtige Einstellung dafür ist gar nicht so leicht zu finden. Im Quellcode von WordPress finde ich schließlich, dass das Minimum der PHP-Einstellungen upload_max_filesize und post_max_size entscheidend ist. Das dort aufgerufene apply_filters wird dazu verwendet, den Wert in Multisite-Installationen von WordPress zu modifizieren, bei einem einfachen WordPress tut es gar nichts.

Ein Aufruf von docker-compose exec blog-wordpress php --ini verrät, dass der Docker-Container alle PHP-Konfigurationsdateien lädt, die auf das Muster /usr/local/etc/php/conf.d/*.ini passen.

Mit diesen Erkenntnissen lege ich – per COPY im Dockerfile – im WordPress-Container eine Datei /usr/local/etc/php/conf.d/large-upload.ini mit folgendem Inhalt an:

upload_max_filesize = 20M
post_max_size = 24M

Hinweis am Rande: In der Standardkonfiguration ist upload_max_filesize = 2M und post_max_size = 8M.

Damit die Änderung greift, aktualisiere ich den WordPress-Container, wobei das Docker-Image wegen der Änderungen am Dockerfile mit --build neu gebaut werden muss:

docker-compose up -d --build blog-wordpress
--> Restarting hex_blog-wordpress_1 ... done

Ein kurzer Blick in den Upload-Dialog verrät: Jetzt sind Uploads bis zu 20 MiB möglich!

MariaDB: MySQL, aber besser™!

Damit mir die Arbeit nicht ausgeht, stelle ich heute von MySQL auf die freie Variante namens MariaDB um. Hintergrund der Aktion: Ich wollte MariaDB schon immer mal ausprobieren, hatte aber noch keine Gelegenheit. Die wäre eigentlich schon vor ein paar Tagen da gewesen, aber… Vergessen. Dann halt jetzt!

Damit bei der Umstellung kein neu hinzugefügter Content verloren geht, stoppe ich erstmal den WordPress-Container:

Weiterlesen „MariaDB: MySQL, aber besser™!“ →

Verbessertes Backup

Das Backup-Skript sichert momentan zwar schon die Docker-Volumes, allerdings muss dort bei einer MySQL-Datenbank wie der von WordPress nicht unbedingt der aktuelle Stand stehen. Deshalb baue ich vor dem Aufruf des eigentlichen Backups noch den folgenden Aufruf ein:

/bin/docker exec hex_blog-wordpress-mysql_1 /bin/bash -c 'MYSQL_PWD=${MYSQL_ROOT_PASSWORD} /usr/bin/mysqldump -B wordpress --add-drop-database --single-transaction > /var/lib/mysql/wordpress-dump.sql' 2>/dev/null || true

Der Befehl lässt sich in zwei Teile zerlegen. Der äußere Teil wird direkt auf dem Server ausgeführt:

Weiterlesen „Verbessertes Backup“ →

Heute schon gebloggt?!

Bis jetzt gibt’s auf dem Server nur einen praktisch leeren Web-Server und ein paar Redirects. So soll’s bleiben… NICHT!

Damit Dana und ich endlich den gesammelten Content irgendwo abwerfen können, lege ich die Subdomain blog.customieze.de an und starte einen Docker-Container für WordPress und einen mit der dazu passenden MySQL-Datenbank. Ein paar Zeilen Konfiguration später laufen beide und reden sogar miteinander!

Wie immer muss natürlich auch noch blog.customieze.com angelegt und mit einem passend konfigurierten Redirect-Container hinterlegt werden.

Container? Sicher!

Momentan läuft auf dem Server noch nichts wirklich sinnvolles. Damit das nicht so bleibt, installiere ich Docker Community Edition. Der Plan ist, den Großteil der Server-Software in Form von Docker-Containern laufen zu lassen.

Als nächstes starte ich jeweils einen Docker-Container auf Basis der Images jwilder/nginx-proxy und jrcs/letsencrypt-nginx-proxy-companion. Unverschlüsselte HTTP-Verbindungen liefern ausschließlich Weiterleitungen auf die entsprechenden HTTPS-Äquivalente, die durch das Zusammenspiel der beiden Docker-Container mit Zertifikaten von Let’s Encrypt abgesichert sind.

Hinter der „Master-URL“ https://www.customieze.de läuft vorerst ein blanker Apache Web Server, der einfach nur „It works!“ behauptet. Stimmt ja auch.

Um sämtliche Kombinationen aus „www.“, „.de“ und „.com“ letztlich auf die Master-URL umzulenken, sind noch ein paar Weiterleitungen notwendig. Dafür benutze ich das Docker-Image schmunk42/nginx-redirect. Über den vorher aufgesetzten Mechanismus bekommen auch die daraus erstellten Redirect-Container vollwertige SSL-Zertifikate.

Beim Test der der Redirect-Container fiel mir allerdings noch auf, dass sie sich nicht sauber stoppen lassen. Die Lösung dafür spiele ich mit einem Pull-Request an den Autor zurück.