WordPress

Mail Relay für Mailcow Dockerized

Nachdem auf meinem neuen vServer ein Webserver und ein Mailserver installiert und eingerichtet waren, tauchte ein neues Problem auf. Meine Webseiten und meine Nextcloud konnten via PHP keine Mails mehr absetzen. Die Ursache hierfür liegt auch dieses Mal in der Konstellation meines Servers mit der installierten Container-Lösung Mailcow Dockerized, wo Postfix im Container seinen Dienst verrichtet und von dem Apache so nicht angesprochen werden konnte.

Was kann man tun?

Am einfachsten ist es in WordPress, Joomla! und der Nextcloud den Mailversand via SMTP einzurichten. Genau das hatte ich auch zur schnellen Lösung umgesetzt. Leider funktionierte das Ganze nicht wirklich mit Elgg.

Wie löst man das Problem zufriedenstellend?

Ganz einfach, indem man ein Mail Relay einbaut. Dazu wird ein lokaler MTA für den Docker Host eingerichtet. Das klingt aber alles komplizierter als es tatsächlich ist.

Dazu habe ich Postfix installiert.

# apt install postfix

1	# apt install postfix

Während der Installation wird man nach dem System mail name gefragt. Hier wurde der Hostname des Servers (intux) eingetragen.

Vorsicht: Nicht die Domain eingeben!

Nach Abschluss der Installation, musste noch die /etc/postfix/master.cf geändert werden. Dazu wurde der SMTP Listener mit # auskommentiert.

# nano /etc/postfix/master.cf

1	# nano /etc/postfix/master.cf

#smtp inet n - y - - smtpd

1	#smtp inet n - y - - smtpd

Danach musste noch 172.22.1.1 als Relay Host hinzu gefügt und das Docker Interface aus inet_interfaces entfernt werden.

# postconf -e 'relayhost = 172.22.1.1'
# postconf -e "mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128"
# postconf -e "inet_interfaces = loopback-only"

# postconf -e 'relayhost = 172.22.1.1'

# postconf -e "mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128"

# postconf -e "inet_interfaces = loopback-only"

Nach einem Neustart von Postfix konnten nun wieder Systemmails via PHP von WordPress und Co. versendet werden.

# /etc/init.d/postfix restart

1	# /etc/init.d/postfix restart

Alle Änderungen werden übrigens in die /etc/postfix/main.cf geschrieben. Nur falls bei der Installation von Postfix mal etwas schief geht. 😉

Weiterführende Infos und Anleitungen findet man auf der Projektseite von Mailcow-Dockerized unter: https://mailcow.github.io/mailcow-dockerized-docs/

Reverse Proxy für Mailcow-Dockerized

Mit dem Aufsetzen eines neuen Servers auf Basis von Debian 9 kamen wieder einige neue Dinge auf mich zu. Da ich mich für die Mailserver-Groupware Mailcow-Dockerized von André Peters entschieden hatte, musste ich mich erstmals mit einem Reverse Proxy auseinander setzten.

Wozu brauche ich einen Reverse Proxy?

Auf dem neuen Server sollte neben dem Webserver ein Mailserver installiert werden. Da Mailcow-Dockerized eine Container-Lösung ist und in diesem Container neben Postfix, Dovecot und Co. auch der Webserver Nginx läuft, würden aber die Ports 443 und 80 mit dem zuvor installierten Apache, auf dem eine Test-Webseite aktiv ist, kollidieren.

Um Mailcow zu installieren, musste zuerst der Apache gestoppt werden. Der Mailserver wurde dann in ein paar Minuten aufgesetzt und eingerichtet. Das Mailcow UI konnte wie gewünscht via HTTP und HTTPS erreicht werden. Im Anschluss wurde die Konfiguration nochmals geöffnet, um die Bindung an die Ports 80 und 443 entsprechend in 8080 und 8443 in der /root/mailcow.dockerized/mailcow.conf zu ändern.

HTTP_PORT=8080
HTTP_BIND=127.0.0.1

HTTPS_PORT=8443
HTTPS_BIND=127.0.0.1

HTTP_PORT=8080

HTTP_BIND=127.0.0.1

HTTPS_PORT=8443

HTTPS_BIND=127.0.0.1

Natürlich hätte man das auch während der Installation durchführen können, jedoch wollte ich zuvor die testen, ob der Mailserver ordnungsgemäß läuft.

Nach dem nochmaligen Durchlauf der Konfigurationsänderungen, konnte nun das Mailcow UI natürlich von außen nicht mehr aufgerufen werden.

Nun wurde der Apache wieder gestartet und die Test-Websites ging wieder online.

Erstellen eines neuen Virtual Host

Um nun auch den Nginx in Mailcow-Dockerized zu erreichen, musste ein Reverse Proxy eingerichtet werden. Dazu habe ich einen Virtual Host, welcher auf Port 80 und Port 443 lauscht, in einer neu erstellten /etc/apache2/sites-available/proxy.conf mit folgendem Inhalt eingerichtet. Dieser leitet die Anfragen von mail.domain.tld an den Nginx im Container weiter. Das hatte zur Folge, dass die alten Zertifikate aus Mailcow-Dockerized unbrauchbar wurden. Ich habe darauf hin mein bestehendes Zertifikat um die Subdomain https://mail.domain.tld erweitert. Der Ort, wo die Zertifikate hinterlegt sind, musste im Codeblock (siehe unten) noch eingetragen werden.

<VirtualHost *:80>
    ServerName mail.domain.tld
    RewriteEngine On
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
    ProxyPass / http://127.0.0.1:8080/
    ProxyPassReverse / http://127.0.0.1:8080/

    ProxyPreserveHost On
    ProxyAddHeaders On
</VirtualHost>
<VirtualHost *:443>
    ServerName mail.domain.tld

    ProxyPass / http://127.0.0.1:8080/
    ProxyPassReverse / http://127.0.0.1:8080/

    ProxyPreserveHost On
    ProxyAddHeaders On

    # This header does not need to be set when using http
    RequestHeader set X-Forwarded-Proto "https"

SSLCertificateFile /etc/letsencrypt/live/domain.tld/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/domain.tld/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

ServerName mail.domain.tld

RewriteEngine On

RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

ProxyPass / http://127.0.0.1:8080/

ProxyPassReverse / http://127.0.0.1:8080/

ProxyPreserveHost On

ProxyAddHeaders On

</VirtualHost>

ServerName mail.domain.tld

ProxyPass / http://127.0.0.1:8080/

ProxyPassReverse / http://127.0.0.1:8080/

ProxyPreserveHost On

ProxyAddHeaders On

# This header does not need to be set when using http

RequestHeader set X-Forwarded-Proto "https"

SSLCertificateFile /etc/letsencrypt/live/domain.tld/fullchain.pem

SSLCertificateKeyFile /etc/letsencrypt/live/domain.tld/privkey.pem

Include /etc/letsencrypt/options-ssl-apache.conf

</VirtualHost>

Nach einem erneuten Neustart des Apache2 lief alles wie gewünscht, sowohl die Test-Webseite, als auch das Mailcow UI.

Weiterführende Infos und Anleitungen findet man auf der Projektseite von Mailcow-Dockerized unter: https://mailcow.github.io/mailcow-dockerized-docs/

Nachtrag

Zu beachten gilt, dass für die Subdomain mail.domain.tld ein separates Zertifikat erstellt werden muss, da das in Mailcow-Dockerized vorhandene nicht mehr funktioniert. Zur Erstellung eines validen SSL-Zertifikats kann man auf die Anleitung „Let’s Encrypt auf dem Raspberry Pi“ zurück greifen.

Und immer wieder Servercow

Mein Umstieg auf Debian 9

Aus IT-technischer Sicht sollte man Web- und Mailserver auf getrennten Systemen laufen lassen. Da ich aber meinen Server privat betreibe und das Ganze mehr ein Hobby ist, laufen bei mir Web- und Mailserver auf einem Host.

vServer, Servercow — Übersicht der laufenden Prozesse mit htop

Angefangen hatte ich mit Debian 8 auf dem bisher meine Seite intux.de lief. Parallel dazu hatte ich einen Mailserver mit Mailcow 0.14 aufgesetzt. Beides arbeitete bisher ohne Probleme und es gab eigentlich keinerlei Bedarf hieran irgendetwas zu ändern, da Debian 8 als LTS noch bis Ende April 2020 unterstützt wird.

Da ich aber mein System auf die aktuelle Version Debian 9 Stretch anheben wollte, musste ich mir Gedanken machen, wie das am besten zu realisieren ist. Da es momentan kein Upgrade für Mailcow 0.14 gibt und diese Version nicht auf dem aktuellen Debian Stretch läuft, kam für mich nur die Container-Variante Mailcow Dockerized in Frage.

Ein Upgrade auf Debian 9 wäre natürlich möglich gewesen, jedoch habe ich mich dazu entschlossen Stretch auf einem separaten Server zu installieren und alle Dienste nacheinander rüber zu holen. Dieses Vorhaben konnte ich ohne Zeitdruck auf Servercow realisieren. Der grandiose Support von André Peters war hierbei mehr als hilfreich. Bei einigen Problemen hatte ich so einen kompetenten Ansprechpartner, der sehr schnell auf Anfragen reagierte.

Da Mailcow Dockerized autonom und aus dem System herausgelöst in einer eigenen Virtualisierung arbeitet, wär mein Apache 2 mit dem Webserver Nginx in Dockerized kollidiert. Hierzu war es notwendig einen Reverse Proxy auf dem Apache, wo mein Blog läuft, einzurichten. Des Weiteren konnten von meinem frischen System keine Mails über PHP abgesetzt werden. Auch hier musste ich mich in eine für mich neue Thematik, einen Local MTA, einarbeiten, welcher dann u.a. Systemnachrichten an Mailcow Dockerized zum Versenden übergibt.

Fazit

Den Server parallel einzurichten und alle Dienste nach und nach umzuziehen stellte sich aus der Situation als die richtige Entscheidung heraus. Ich war so nicht gezwungen alles am Stück wieder zum Laufen zu bringen. Mailcow Dockerized ist leicht zu installieren und ohne ewige Konfiguration sofort einsatzbereit. Trotz zwei nun nebeneinander arbeitender Webserver läuft das gesamte System performanter als vorher.

Ich habe mich zur Verwirklichung meiner kleinen Projekte vor fast 10 Monaten bewusst und aufgrund guter Kritiken für Servercow entschieden. Bei Problemen am Server und speziell mit Mailcow steht ein kompetenter Ansprechpartner zur Seite. Diesen Schritt habe ich zu keinem Zeitpunkt bereut. Sicher hat man mit einem eigenen Server einiges an Arbeit und Verantwortung auf dem Schirm, aber man ist dafür wesentlich flexibler. Dafür bietet Servercow ein gutes Zuhause.

Uberspace 7 – Public Beta

Der erste Eindruck

Shell, SSH, Uberspace — Übersicht der laufenden Prozesse mit htop

Uberspace, der nerdige Hoster von Jonas Pasche aus Mainz, hat nun erstmals Uberspace 7 (U7) der Allgemeinheit vorgestellt. Nach einem Test der Closed Beta mit 50 Usern, ging nun die Public Beta an den Start. Zeit sich das Ganze mal etwas näher anzusehen. Da ich selbst eine ganze Weile meine Seite auf Uberspace betrieben habe, war die Einrichtung nicht ganz so schwer. Die neue Doku unter https://manual.uberspace.de soll dem U7-Neuling beim ersten Umgang etwas unter die Arme greifen. Leider ist die Dokumentation noch sehr übersichtlich gehalten und auch nur in englischer Sprache verfügbar. Trotz alledem sind die notwendigsten Schritte zum Aufsetzen einer eigenen Webseite auf Uberspace 7 recht gut erklärt. Anfänger, denen der Umgang mit der Shell nicht so vertraut ist, werden es jedoch auch mit U7 weiterhin recht schwer haben. Da Uberspace aus meiner Sicht hauptsächlich durch Mund-zu-Mund-Propaganda wächst, steht hier aber meist ein erfahrener Uberspace-User helfend zu Seite.

Kurz und knapp gesagt bzw. geschrieben, ist es kein Hexenwerk eine Domain aufzuschalten und eine Webseite bzw. eine eMail-Adresse in der Public Beta einzurichten. Noch fehlen zwar einige Dinge, wie Spamfilter, Webmail, phpMyAdmin, Adminer oder die Möglichkeit virtuelle Mailuser anzulegen. Dafür muss man sich aber in Zukunft keine Gedanken mehr um SSL-Zertifikate und deren Verlängerung auf dem neuen Uberspace machen. Let’s Encrypt ist Standard. Weiterhin wird von Haus aus von HTTP auf HTTPS umgeleitet. Als Datenbank-Verwaltungs-System wird nun MariaDB, welches kompatibel zu MySQL ist, verwendet.

Wo bekommt man das alles?

Hierzu verweise ich erst einmal auf den Blog, der über alle News rund um Uberpace informiert. https://blog.uberspace.de

Zur Registrierung eines U7-Account geht’s hier: https://uberspace.de/register?u7=1

Fazit

Mit ein wenig Bastelei konnte ich in kürzester Zeit eine Testseite sowie eine eMail-Adresse im neuen Uberspace 7 migrieren. Das Aufschalten der für den Test verwendeten Domain lief ebenfalls völlig unspektakulär. Zwar fehlen noch einige Features im neuen System, dennoch öffnet Uberspace mit der U7 Public Beta eine neue Tür.

Der Preis zum Hosting, kann nach wie vor selbst bestimmt werden. Man bekommt einen kompetenten Hoster mit super Support zu einem fairen Preis.

PHP 7

Ich habe mal schnell meinen vServer auf PHP 7 geswitcht. Nun besteht keine Eile sofort auf Debian 9 Stretch zu springen.

hality.org

Heute möchte ich ein wenig Werbung für die regionale Open Source Community von Halle (Saale) machen. Ende Januar 2016 hatten Andreas und ich die Idee eine Online-Community für Gleichgesinnte zu gründen. Im Vordergrund sollte der Gedankenaustausch rund um freie und quelloffene Software stehen.

Hierzu haben wir am 10.02.2017 den Grundstein gelegt. Es wurde damit begonnen ein kleines soziales Netzwerk unter hality.org aufzubauen. Daran teilnehmen kann natürlich jeder! Hierbei spielt keine Rolle ob ihr Hallenser seid oder aus einer anderen Ecke der Republik kommt.

Um die Community etwas lebhafter zu gestalten, möchten wir natürlich auch Treffen organisieren. Dabei soll der Fokus auf freier Software liegen. Installationshilfen sowie Workshops sind geplant.

Unter XMPP und IRC stehen entsprechende Chaträume bereit.

XMPP: hality@conference.intux.de
IRC: #intux

Viel Spaß!

Fehlgeschlagener Upload eines WordPress-Themes

Neulich musste ich feststellen, dass ich ein neues WordPress-Theme nicht installieren konnte, weil es zu groß war. Durch das Hochsetzen der Standard-Werte für upload_max_filesize und post_max_size in der /etc/php5/apache2/php.ini würde das kleine Problem behoben.

# nano /etc/php5/apache2/php.ini

1	# nano /etc/php5/apache2/php.ini

Die Einträge

upload_max_filesize = 2M
post_max_size = 8M

1 2	upload_max_filesize = 2M post_max_size = 8M

wurden in

upload_max_filesize = 2G
post_max_size = 2G

1 2	upload_max_filesize = 2G post_max_size = 2G

geändert. Nach dem Neustart des Webservers konnte das Theme problemlos hochgeladen werden.

# /etc/init.d/apache2 restart

1	# /etc/init.d/apache2 restart

Angriffe auf WordPress

Es nervt! Seit 24 Stunden über 250 Angriffe.

CeBIT 2017

Am Montag habe ich die CeBIT 2017 besucht. Wie geplant konnte ich mich dort mit Jurist und Tech-Blogger Didi von DIDIS BLOGAZO treffen, mit dem ich dann die gesamte Zeit auf der Messe verbrachte.

2017 ist Japan das Partnerland der diesjährigen CeBIT. Trotz vieler neuen Innovationen war mein persönlicher Eindruck davon geprägt, dass die Präsenz von Hooverboards, VR-Brillen, 3D-Druckern und sogar den beliebten Drohnen ihren Höhepunkt wohl überschritten haben. Dieser subjektive Eindruck aber nur am Rande.

Da wir rechtzeitig auf dem Messegelände waren, konnten wir den ersten Vortrag im Open Source Forum „Enterprise-Zwei-Faktor-Authentifizierung für ownCloud und Nextcloud“ von Cornelius Kölbel lauschen. Ich persönlich finde die Idee dahinter nicht schlecht, da Angriffe auf solche Systeme nicht nur häufiger, sondern auch immer raffinierter ausgeführt werden. Praxisnah habe ich nun begonnen, diese WordPress-Installation sowie meine Nextcloud mit einer TOTP-Zweifaktorauthentifizierung (Time-based One-Time Password algorithm) auszustatten.

Zwischendurch suchten wir den Stand von KNOPPIX auf. Hier wurden u.a. unter Knoppix erstellte 3D-Modelle gedruckt. Desweiteren konnte man praxisnah und verständlich erfahren, wozu diese Live-Distribution im Stande ist.

Zurück im Open Source Park unterhielt ich mich mit einem Mitarbeiter von TUXEDO über die neuesten Modelle. Hier fiel sofort das neue 13″ InfinityBook ins Auge. Dieses wirkt auf den ersten Blick noch gelungener als das Vorgängermodell. Vielleicht werde ich dieses Modell einmal antesten und etwas genauer vorstellen.

Danach ging es zum Vortrag „Knoppix 8.0 – die CeBIT Edition“. Hier erfuhren wir, welche Neuerungen Klaus Knopper und sein Team dieser besonderen Version spendiert haben. Sehr interessant war, dass es möglich ist ein bestehendes Knoppix-Live-System so zu vervielfältigen, dass Systemänderungen mit übernommen werden. Diesen Aspekt finde ich besonders bemerkenswert, wenn im Fokus des Einsatzgebietes z.B. ein Schulprojekt steht. So können speziell angepasste und völlig identische Systeme auf Live-Sticks den Anwendern zur Verfügung gestellt werden.

Zum Schluss habe ich Didi in meine Arbeitswelt, den Straßenbau, entführt. Es ging zum Stand vom Komatsu, wo ein GPS-gesteuerter Kettenbagger der neuesten Generation vorgestellt wurde, der PC210LCi-11. Nachdem Didi im Gerät Platz genommen hatte, war er kaum wieder raus zu bekommen.

MySQL Bilder-Pfade anpassen

Vor ein paar Tagen fiel mir auf, dass einige Bilder-Pfade meiner Seite noch mit www. begannen und somit falsch verlinkt waren. Diese wurden, da noch kein ServerAlias (mit www.) in der Config des Virtual Host auf dem Server eingetragen war, nicht mehr im Browser dargestellt.
Ein kleiner Eingriff in die MySQL-Datenbank machte die Bilder aber wieder sichtbar.

UPDATE wp_posts SET post_content = REPLACE(post_content, 'https://www.intux.de/wp-content/uploads/', 'https://intux.de/wp-content/uploads/');

1	UPDATE wp_posts SET post_content = REPLACE(post_content, 'https://www.intux.de/wp-content/uploads/', 'https://intux.de/wp-content/uploads/');