Unsere regionale Free and Open Source Software Community geht nun langsam ins zweite Jahr. Ich habe heute die Domain hality.org um ein weiteres Jahr verlängert.
hality.org
Kategorie: Projekte
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.
|
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.
|
1 |
# nano /etc/postfix/master.cf |
|
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.
|
1 2 3 |
# 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.
|
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/
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.
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.
intux.de wird werbefrei
Ich habe mich dazu entschlossen künftig auf Bannerwerbung auf intux.de zu verzichten.
Viel Spaß!
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ß!
Webadmin von ZNC nachträglich über SSL erreichbar machen
Als ich ZNC auf meinem Debian-Server installiert habe, hielt ich mich bei der Konfiguration an meine damalige Uberspace-Installation. Dort hatte ich die Standard-Abfrage
|
1 |
Listen using SSL (yes/no) [no]: |
einfach nur bestätigt. Dies stellte nun kein gravierendes Problem dar. Im nachhinein war ich aber über den unverschlüsselten Zugang zum Webinterface via http://IP:Port nicht glücklich. Der Zugang über domain.tld:Port wurde logischerweise verwehrt.
Nun bin ich der Sache auf den Grund gegangen, warum ich das Webinterface nicht über domain.tld:Port erreiche. Hier verhinderte eine Kombination von dem Erzwingen von https und HSTS (HTTP Strict Transport Security) den Zugang zum Webinterface über intux.de.
Der Entwickler rät davon ab die znc.conf im Editor zu bearbeiten. Stattdessen sollte hier das Webinterface zur weiteren Konfiguration genutzt werden. Dieses konnte ich ja, wie oben beschrieben, über http://IP:Port nutzen. Hier musste ich dann einen neuen Eintrag (anderer Port) in Listen Port(s) mit dem Häkchen SSL versehen. Über diesen Port ist dann nach dem Einpflegen von Let’s Encrypt das Webinterface via https erreichbar.
|
1 |
cat /etc/letsencrypt/live/intux.de/{privkey,cert,chain}.pem > /home/znc/.znc/znc.pem |
Ich verbinde mich nun mit mit dem ZNC-Bouncer via SSL mit:
|
1 |
/connect intux.de/Port -ssl |
vServer auf Servercow
Am 30.12.2016 mietete ich mir spontan einen vServer. Nach einigen Tagen der Einrichtung setzte ich einen Mailserver auf. Als alles zufriedenstellend lief, wurde schlussendlich mein Blog vom bisherigen Hoster mit rüber geholt.
Bevor jedoch meine Unternehmung bzw. mein Projekt vServer startete, machte ich mir Gedanken, wo ich diesen mieten sollte. Da ich inzwischen einiges und nur positives über Servercow u.a. im OSBN gelesen hatte, war klar, dort werde ich es versuchen. Ein wirklicher Dauerbetrieb stand eigentlich nicht wirklich zur Debatte, sondern eher ein dreimonatiger Testlauf, um weitere Erfahrungen zu sammeln bzw. auszubauen. Da alles bisher so gut lief, werde ich jedoch den Server weiter betreiben.
Zu allererst wurde ein XMPP-Server, eine Nextcloud und ein IRC-Bouncer eingerichtet. Als das alles über eine eigens für dieses Unterfangen eingerichtete neue Domain lief, wagte ich mich an den aus meiner Sicht schwierigsten Part, den Mailserver.
Auch hier stellte sich heraus, dass Servercow die richtige Wahl für meine Bedürfnisse war. Der Betreiber und Tech-Blogger André Peters stellt mit Mailcow eine Mailserver-Suite, basierend auf Dovecot, Postfix, einem vorkonfigurierten Spamfilter sowie Virenschutz und weiterer Open-Source-Software, wie Roundcube und STARTTLS and SMTPS Support zur Verfügung. Ein sehr ansprechendes Web UI übernimmt nach dem Einrichten die User- und Server-Administration. Mailcow lässt sich ohne weiteres schnell, sicher und vor allem einfach aufsetzen. Die Mailcow-Mailserver-Suite ist für Debian 8 (Jessie) optimiert, unterstützt aber auch Ubuntu LTS 14.04 (Trusty Tahr) and Ubuntu LTS 16.04 (Xenial Xerus). Das kam mir sehr zu Gute, da ich mich ohnehin für Debian 8 als Server-Betriebssystem entschieden hatte. Zur Auswahl auf Servercow stehen nicht nur große Betriebssystemvorlagen wie CentOS, Ubuntu, Fedora, FreeBSD, NetBSD sondern auch kleinere wie Alpine Linux oder Elastix. Andere Betriebssystem-ISOs sind auf Anfrage lt. Webseite problemlos einbindbar.
Das Aufsetzen des Webservers Apache und der Umzug meiner Seite inkl. PIWIK waren zum Schluss nur noch Formsache.
Bei ein paar Kleinigkeiten musste ich jedoch den Support bemühen. Hierbei viel sofort positiv auf, wie schnell man sich kompetent und höflich den Problemen der Kunden annimmt.
Als Bonus zu meinem Paket M und allen weiteren Konfigurationen stehen im Übrigen 150GB via FTP sowie Samba zur Verfügung.
Um einen kleinen optischen Eindruck zu gewinnen, habe ich ein paar Screenshots angehängt.
Screenshots – Servercow
Screenshots – Mailcow
Fazit
Mit Servercow habe ich einen sehr guten und fairen Server-Hoster gefunden, den ich bedenkenlos weiterempfehlen kann. Die 1 Gigabit-Anbindung sorgt für ordentlich Geschwindigkeit. Für Backups können drei Snapshots angelegt werden, bei Bedarf auch automatisch im wöchentlichen Intervall.
Prosody – Migrator
Vor ein paar Tagen habe ich nachträglich Prosody auf meinem Server an eine MySQL-Datenbank angebunden. Diese Funktion hat einige Vorteile gegenüber der herkömmlichen Speicherung der Daten im Datenverzeichnis.
Die Anbindung an MySQL ist relativ einfach. Deshalb möchte ich hierauf nicht weiter eingehen.
Mit dem Prosody Migrator kann man nun den Altbestand der User in die Datenbank übernehmen. Der Pfad des Datenverzeichnisses ist in meinem Fall /etc/prosody/data. Zu beachten wäre, dass alle schon vorhandenen User-Daten dabei überschrieben werden.
Um mit der Migration zu beginnen, wechselt man in das Verzeichnis in dem der Ordner „data“ liegt.
|
1 |
# cd /etc/prosody |
Von der Beispiel-Konfiguration sollte man vorhe eine Sicherung anlegen.
|
1 |
# cp migrator.cfg.lua migrator.cfg.lua_bak |
Nun öffnet man die Config und bearbeitet diese folgendermaßen:
|
1 |
# nano migrator.cfg.lua |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
local data_path = '/etc/prosody/data'; input { type = "prosody_files"; path = data_path; } mydatabase { type = "prosody_sql"; driver = "MySQL"; database = "Name der Datenbank"; username = "Benutzername der Datenbank"; password = "Passwort der Datenbank"; host = "localhost"; } --[[ input { type = "prosody_files"; path = data_path; } output { type = "prosody_sql"; driver = "SQLite3"; database = data_path.."/prosody.sqlite"; } ]] |
Hierbei ist der Pfad (falls data woanders liegt) sowie die Zugangsdaten zur MySQL-Datenbank anzupassen. Das Ganze speichert man mit Ctrl + o und verlässt den Editor mit Ctrl + x. Nun migriert man mit
|
1 |
# prosody-migrator input mydatabase |
alle bestehenden Accounts. Erscheint
Migrating…
Done!
war die Migration erfolgreich.
Viel Spaß!
Und wie macht sich der Kleine so?
Vor über einem Monat habe ich einen Test gestartet, wobei nun alle Kontakte, Termine und Dateien meines Smartphones mit einem Raspberry Pi synchronisiert werden. Dazu wurde die Standard-Synchronisation dieser Dienste zu Google deaktiviert.
Auf dem Raspberry Pi läuft ein aktuelles Raspbian Jessie. Die Ports 21, 22, 80 und 443 wurden zu diesem Zweck (FTP, SSH, HTTP und HTTPS) am heimischen Router geöffnet. Um nun von außen einen Zugang zu bekommen, nutze ich den Dienst NoIP. So kann ich mit einer festen Internetadresse über die sich ständig ändernde öffentliche IP auf meinem Raspberry Pi zugreifen. Der RasPi gleicht diese IP mit dem installierten ddclient ab. Weiterhin sind der Webserver Apache2 und eine ownCloud installiert. Letztere dient der Speicherung der zuvor erwähnten Daten. Das Ganze wurde mit einem Let’s Encrypt Zertifikat verschlüsselt.
Um diese Daten dann mit der Cloud zu synchronisieren, nutze ich mit dem Smartphone die drei kostenpflichtigen Apps CardDAV-Sync, CalDAV-Sync und FolderSync. Am PC synchronisiert Debian 8 die Daten mit dem ownCloud Client. Kontakte und Termine werden im Mail-Programm Evolution abgegriffen.
Wie läuft das alles nun rückblickend?
Eigentlich erstaunlich gut und ohne Probleme meinerseits. Ein zwischenzeitlicher Ausfall, hatte mich aber kurzzeitig hierbei aus der Bahn geworfen. Mein Internet-Provider stellte ohne Ankündigung meinen Anschluss auf Port and Address Translation (PAT). Dabei war es nicht mehr möglich über die öffentliche IP auf mein Heimnetz zuzugreifen. Erst nach Rücksetzung durch den Support auf Network Address Translation (NAT) konnte ich meine Cloud wieder erreichen.
Fazit
Ja, es geht auch ohne Google, wenn man die Daten des Smartphones sichern möchte. Mit dieser Heim-Lösung bin ich im Moment sehr zufrieden. Die Anschaffungs- und Stromkosten eines Raspberry Pi inkl. Zubehör halten sich in Grenzen. Zudem nutze ich eine 64GB MicroSD, die wirklich sehr viel Spielraum zur Datensicherung bietet.
Übrigens gibt es CardDAV-Sync, CalDAV-Sync und FolderSync auch in kostenlosen Light-Versionen. Diese verfügen aber nicht über den vollständigen Funktionsumfang.
Ich habe hier anhand dieses Beispiels eine Einkaufsliste der eingesetzten Hardware zusammen gestellt.
- Raspberry Pi 3 (Affiliate Link)
- Gehäuse + Netzteil (Affliate Link)
- MicroSD 64GB (Affiliate Link)
Flightradar
Wer mich kennt, weiß, dass ich nicht gerade ein Freund der Fliegerei bin. Jetzt hat mich aber eine Geschichte der ganzen Sache etwas näher gebracht. Hierbei handelt es sich um Flightradar24. Dieser Dienst zeigt die Bewegung sämtlicher Flugzeuge am Himmel.
Flightradar24 finanziert sich zu einem Großteil durch Werbung. Diesen störenden Nebeneffekt kann man aber mit ein wenig technischem Aufwand umgehen.
Bei der Suche nach einem weiteren spannenden Projekt für den Raspberry Pi, habe ich nun entdeckt, dass man sich an Flightradar24 beteiligen und so in den Genuss eines werbefreien Premium-Business-Accounts kommen kann.
Was wird hierzu benötigt?
Zu allererst sollte man grundsätzlich bereit sein, Funksignale der sich im näherem Luftraum befindlichen Flugzeuge über den Raspberry Pi zu empfangen und diese an Flightradar24 zu übermitteln.
Viel technischen Schnick-Schnack braucht man dazu nicht. Es reicht ein Raspberry Pi, mit einer entsprechenden MicroSD die genug Platz für das OS Raspbian bietet. Ich verwende hier eine Speicherkarte mit 8GB. Diese verfügt über genug Reserven. Des Weiteren wird ein DVB-T Stick mit einem RTL2832U/R820T-Chip angeschlossen, welcher ADS-B Signale (Automatic Dependent Surveillance – Broadcast) empfangen kann. Eine Verbindung des Einplatinencomputers zum Internet ist Voraussetzung.
Ist Raspbian installiert, wird folgender Befehl ausgeführt:
|
1 |
sudo bash -c "$(wget -O - http://repo.feed.flightradar24.com/install_fr24_rpi.sh)" |
Hierbei wird das kleine Programm dump1090 installiert und konfiguriert. Es werden dabei Daten wie eMail-Adresse, Standort (Lat, Lon, Hight) sowie der verwendete Empfänger (z.B. Receiver selection – 1) abgefragt. Um die Daten dann auch entsprechend darstellen zu können, muss die Multilateration (MLAT) hier aktiviert werden. Nach Abschluss der Konfiguration erhält man von Flightradar24 eine eMail mit dem Sharing Key und dem Code der neu angelegten Empfangsstation.
Den Business-Account kann man nun mit der bei Flightradar24 während der Konfiguration hinterlegten eMail-Adresse anlegen und aktivieren.
Die lokale Hauptseite der Empfangsstation erreicht man über http://IP:8754. In meinem Fall ist das http://192.168.1.60:8754. Von dort gelangt man zur Liste der getrackten Flugzeuge und auch zu den Einstellungen. Des Weiteren besteht die Möglichkeit von hieraus dump1090 zu beenden.
Um nun die von der Station getrackten Flugzeuge sichtbar zu machen, gibt man in den Einstellungen http://IP:8754/settings.html unter „Process arguments“ folgende Zeile ein.
|
1 |
--net --net-http-port 8080 |
Nun werden alle empfangenen Flugzeuge über http://IP:8080 in Google Maps oder OpenStreetMap dargestellt.
Nach jedem Neustart des Raspberry Pi wird auch dump1090 automatisch ausgeführt. Hat man jedoch den Dienst beendet, so lässt sich dieser über
|
1 |
sudo service fr24feed restart |
wieder aktivieren.
Wenn dump1090 längere Zeit (48h) keine Daten übermittelt, wird der Account stufenweise herunter gefahren bis der Raspberry Pi wieder an Flightradar24 Signale sendet. Nach 7 Tagen ohne Signal steht der Account auf Basic. Hierzu findet man Folgendes:
If You Are Sharing Data with Flightradar24
We’ve upgraded your existing Premium account to our new Business subscription! In addition to the detailed live flight information included as part of our Gold subscription, our Business subscription also includes access to a full year of historical data and the ability to download individual flights in KML or CSV format. You also have access to our new Airport and Fleet views. You can learn more about our Business subscription in our introductory blog postor by visiting our Premium page.
Your Business subscription will remain active as long as you are sharing data with Flightradar24. If you stop sharing data, your subscription will be downgraded to Gold after 48 hours. If we have not received data from you for 7 days, your subscription level will return to Basic.