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.

Postfix, Debian
Postfix Konfiguration

Postfix, Debian
Postfix Konfiguration – Internet Site
Postfix, Debian
Postfix Konfiguration – System mail name
Postfix, Debian
Postfix Konfiguration – System mail name – intux

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.

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

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

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. 

Mailcow, Servercow
Mailcow UI

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. 

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.

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/

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.

Angriff auf Joomla!-Installation

Vor ein paar Tagen wurde eine auf meinem vServer laufende Joomla!-Instanz massiv angegriffen. Der Inhaber dieser Seite bekam in ca. einer Stunde über 600 Mails vom Nachrichtensystem. So etwas ist bedauerlich und nicht gerade schön mit anzusehen.

Was war passiert?

Die Analyse des Logs /var/log/mail.log zeigte, dass Mails im 5-6 Sekunden-Takt vom Server an den Administrator gesendet wurden. 

Was wurde kurzfristig unternommen?

Zu allererst wurde der Versand der Systemmails der Joomla!-Installation deaktiviert. Damit konnte die Spam-Welle vorerst gestoppt werden. Bei der weiteren Analyse stellte sich heraus, dass die User-Registrierung aktiv war und sich über 600 User registriert hatten. Die dazu verwendeten eMail-Adressen hatten alle die Domain-Endung .ru. Im nächsten Schritt wurde die Registrierung ebenfalls deaktiviert. Warum diese aktiv war, kann ich leider nicht mehr nachvollziehen. Alle verdächtigen registrierten User der Seite wurden gelöscht.

Wie ging es weiter?

Da ich zu dem Zeitpunkt immer noch nicht genau wusste was genau passiert war, habe ich ein älteres Backup der Datenbank eingespielt (zum Glück werden Backups der Datenbanken, wie im Artikel „MySQL- Sicherung ohne Passwort im Script“ beschrieben, täglich automatisch angelegt). Nach dem Einspielen stellte sich heraus, dass hier nur die bekannten Administratoren als Benutzer in der Joomla!-Installation gespeichert waren. Die Registrierung wurde wieder deaktiviert und so die Sicherheitslücke geschlossen. Abschließend habe ich nachgeschaut, ob Dateien oder Verzeichnisse der Joomla!-Installation in den letzten Tagen verändert wurden. Dazu wechselte ich in das entsprechende Verzeichnis

und suchte die Änderungen der Dateien der letzten fünf Tage

Ausgabe:

sowie den Änderungen der Verzeichnisse

Ausgabe:

Die Dateien und Verzeichnisse wurden dann meinerseits überprüft. Da es hier keinerlei Auffälligkeiten gab, konnte auf das Einspielen eines Backups der kompletten Installation verzichtet werden.

Was war nun tatsächlich passiert?

Es konnten sich von außen User registrieren. Die so erstellten Accounts wurden aber nicht aktiviert, da die angegeben eMail-Adressen wahrscheinlich nicht valide waren. Das System verschickte jedoch bei jeder neuen Registrierung eine entsprechende eMail an den Superadministrator. So kam es zu einer massiven Welle von Registrierungsbestätigungen. Da die registrierten Accounts nicht aktiviert werden konnten, hatten die Aktionen keine Auswirkungen auf das System.

Kann das nochmal vorkommen?

Durch die deaktivierte Registrierung kann es zu dieser Art von Angriffen nun nicht mehr kommen.

MySQL- Sicherung ohne Passwort im Script

Nach dem ich nun nieder geschrieben hatte, wie ich meine SQL-Datenbanken automatisch sichere, kamen einige gute Anregungen in den Kommentaren. Darauf hin habe ich das System etwas umgestellt. Dazu wurde zu allererst der Storage vom root auf einen User übertragen. Somit konnte ich auch den Cronjob für den User einrichten. Der Eintrag, wie im ersten Artikel „MySQL-Sicherung“ in /etc/crontab wurde wieder entfernt. und der Cron neu gestartet.

Als eingeloggter User habe ich dem selbigen mit

folgenden Befehl eingetragen.

Dann wurde eine ~/.my.cnf

mit entsprechendem Inhalt erstellt. Diese enthält das MySQL root Passwort.

„meinpasswort“ musste hier natürlich angepasst werden. Nach dem Abspeichern wurden der Datei die Rechte 600 vergeben.

Im Anschluss habe ich ein neues Script mit dem Inhalt

erstellt und dieses mit

ausführbar gemacht. Um die Datenbanken besser auseinander halten zu können, bekamen alle Datenbanken dieses Mal ein separates Verzeichnis.

Nun werden die Datenbank-Sicherungen jeden Morgen 2:00 Uhr in von einander getrennten Verzeichnissen komprimiert abgelegt.

Der Servercow-Storage wurde mit der Nextcloud-App „External Storage“ in die Cloud eingebunden und die Sicherungen landen so regelmäßig auf meinem Notebook.

MySQL-Sicherung

Inspiriert durch den Artikel „Backup oder Datensicherung eines root-Servers / vServers / VPS„von Bitblokes habe ich mir Gedanken gemacht, wie ich meine MySQL-Datenbanken vernünftig und regelmäßig sichern kann. Die Snapshots von Servercow sind schon sehr gut, um ein Backup des ganzen Servers zu erstellen. Jedoch ist man hin und wieder auf eine einzelne Datenbank angewiesen.

Da ich bei Servercow einen zusätzlichen RAID5 HDD-Netzwerkspeicher von 150 GB und diesen in meine Nextcloud eingebunden habe, kann ich dort bequem meine Datenbanksicherungen ablegen. Bei jeder Synchronisation zu Hause, landen dann die Sicherungen auf meinem Notebook. 

Da ich bisher meine Datenbanken manuell mit mysqldump durchgeführt habe, wollte ich das Ganze nun automatisieren.

Dazu wurde das Script MySQLscript.sh

mit folgendem Inhalt erstellt.

Dabei ist „in**********“ der Name meiner ersten Datenbank. Der Eintrag „meinpasswort“ im Script muss natürlich durch das MySQL root Passwort ersetzt werden. 

Im Anschluss wird das Script ausführbar gemacht

und der Befehl mit 

in den crontab eingetragen.

So wird nach dem Neustart von Cron jeden Tag um 2:00 Uhr eine Sicherung jeder einzelnen Datenbank im Verzeichnis /samba_share/backup abgelegt.

Nextcloud auf dem Raspberry Pi

Seit ca. vier Jahren habe ich auf meinen Raspberry Pi eine eigene Cloud installiert. Anfangs war es mehr oder weniger eine reine Testumgebung. Mittlerweile möchte ich aber auf die Möglichkeit, Daten zu Hause in der eigenen Wolke zu speichern, nicht mehr verzichten.  Inzwischen läuft eine Nextcloud 11.0.2 auf einem Raspberry Pi 3 Modell B.

Vor einem halben Jahr bin ich dann noch einen Schritt weiter gegangen. Meine Kontakte, Kalender und Aufgaben werden ebenfalls über die Nextcloud mit meinem Smartphone und Notebook synchronisiert. Der Vorteil hierbei: Google bleibt außen vor. Zur Synchronisation setze ich mittlerweile DAVdroid in Verbindung mit der App Calendar Color ein. Des Weiteren werden Aufgaben mit der App Open Tasks bearbeitet. Natürlich kommt auch die eigentliche Applikation Nextcloud zum Einsatz. Diese Apps sind alle kostenlos auf F-Droid erhältlich. Wer den Entwicklern etwas Geld zukommen lassen will, kann dies natürlich direkt tun.

Mit ein wenig Willen und Lust zum Basteln ist die eigene Cloud schnell installiert und einsatzbereit. Hier kurz eine Liste der von mir eingesetzten Komponenten:

Von Außen erreiche ich die Nextcloud über eine auf INWX eingerichtete DynDNS-Adresse. Um den Zugang aus dem Internet etwas zu härten, verwende ich seit Kurzem eine Zwei-Faktor-Authentifizierung über den Google Authenticator.

Vorsicht: Bei der Einrichtung sind die Backup-Codes unbedingt zu sichern! Hier besteht die Gefahr, dass man sich ungewollt aussperrt.

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.

Die Einträge

wurden in

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