Nextcloud Auto-Update via cli

Nextcloud Auto-Update via cli

Nextcloud

Ich habe einige Nextcloud Instanzen am laufen (https://nextcloud.com/). Und es erscheinen ebenso regelmäßig irgendwelche Updates. Das ist ja auch gut so weil zum einen Sicherheitslücken geschlossen werden, zum anderen zum Teils richtig nette Funktionen mit dazu kommen. Sobald in der Testumgebung alles geklappt hat und richtig läuft kommt die Fleißarbeit: Die ganzen Nextcloud Instanzen von Hand updaten. Hier hört der Spaß allerdings ganz schnell auf – bei mir zumindest. (mehr …)

by Aug 21, 2019 Keine Kommentare
fail2ban und dynamische IP-Adressen

fail2ban und dynamische IP-Adressen

Linux

fail2ban ist ein sehr, sehr praktisches Werkzeug (http://www.fail2ban.org). Und jeder, der fail2ban regelmäßig nutzt hat sich selbst schon einmal ausgesperrt. Gut dem, der eine statische IP hat und diese via ignoreip auf die Whitelist gesetzt hat (http://www.fail2ban.org/wiki/index.php/Whitelist). Pech hingegen für mich, der bei der deutschen Tel… unter Vertrag ist, privat einen DSL Anschluss hat und nicht bereit ist die extrem hohen Kosten für einen Vertrag mit statischer IP zu zahlen.

Dynamische IP-Adresse

Das Problem dabei ist, dass dynamische IP-Adressen sich so dann und wann ändern. Nur was trägt man in einer Witelist ein die statischer Natur ist? So wie von fail2ban verwendet?

Was ich hingegen habe ist einen passenden Eintrag ins DNS der auf meine wechselnde IP zeigt (DynDNS oder wie auch immer ihr das Kind nennen wollt). Also fix ein Skript erstellt welches im tmp-Verzeichnis die dazugehörige IP puffert. Sobald sich diese ändert wird eine passende fail2ban local Config erstellt und die komplette Config neu eingelesen. Da ich ebenfalls auf eine Leitung mit statischer IP-Adresse zugriff habe wird ignoreip eben mit diesem statischen Teil befüllt und anschließend um den dynamischen Teil erweitert.

#!/bin/bash

#
# Whitelisted eine dynamische IP in Fail2ban
#


IGNALWAYS="127.0.0.1/8 ::1 193.nn.mm.0/24"
IGNDYN="dyn.gehirn-mag.net"
IGNFILE="/etc/fail2ban/jail.d/ignoreip.local"
TMPFILE="/tmp/fail2ban-dynip"


# Suche nach aktueller IP sowie gepufferter IP
CURIP=$($(which dig) +short $IGNDYN)
[ -f $TMPFILE ] && OLDIP=$(cat $TMPFILE) || OLDIP="--unknown--"
echo "aktuelle IP: $CURIP gepufferte IP: $OLDIP"

# Falls IPs verschieden ignoreip neu schreiben
if [ $CURIP != $OLDIP ]; then
    echo -n "Ändere ignoreip: "
    echo $CURIP > $TMPFILE
    echo -e "# written by $0 ad $(date)\\n\\n[DEFAULT]\\nignoreip = $IGNALWAYS $CURIP\\n" > $IGNFILE
    $(which fail2ban-client) reload
    # Debug
    $(which fail2ban-client) --dp | mail -s "$(hostname) fail2ban-dynip $CURIP" ...@gehirn-mag.net
fi

 

Falls Du weißt welchen DNS-Server Du fragen musst kannst Du Zeile 15 entsprechend ergänzen. Sowie sich die IP ändert lasse ich mir via Email die aktuelle fail2ban Konfig senden (Zeile 26). Wer das nicht will nimmt diese Zeile einfach raus. Was jetzt noch fehlt ist der regelmäßige Aufruf. Ich selbst verwende dazu folgenden cron Eintrag welcher alle 15 Minuten läuft:

# Fail2ban: die private IP auf die Whitelist setzen
*/15 * * * * /usr/local/bin/fail2ban-ignoreip.sh 2>&1 | /usr/bin/logger -t fail2ban-dynip

Fertig, das war es 🙂

 

by Aug 20, 2019 Keine Kommentare
Diese Abmahnung wurde maschinell erstellt und benötigt keine Unterschrift

Diese Abmahnung wurde maschinell erstellt und benötigt keine Unterschrift

Monitoring

Bei mir kommen regelmäßig Azubis, Praktikanten oder Studenten vorbei. Das ist absolut ok so – man lernt nun mal am Besten die anderen Abteilungen bzw. Unternehmen der Gruppe kennen indem man dort mal ein paar Tage rein schnuppert. Wenn es die Zeit zulässt erzähle ich ganz gerne neben dem was wir so machen noch ein paar Dinge über den üblichen Tellerrand darüber hinaus. Gern genommene Themen sind „Email“ (wir haben mehrere TB bei uns auf den Platten liegen), „Webhosting aus Adminsicht mit Hinblick auf Google Pagespeed“, „Der Einfluss von langsamen DNS auf ein Firmennetzwerk“, „Ethik und Moral zum Thema Monitoring“… Jetzt kommt meistens „langweilig“ oder „ne, Ethik ist nicht so meins“. Na wunderbar! Das Thema ist gefunden, der Einstieg bereits gemacht 😉

Zuerst einmal gehen wir dann immer der Frage nach was Monitoring überhaupt ist. Grob zusammengefasst findet man dieses hier als Einleitung auf Wikipedia (Logo und Text von hier https://de.wikipedia.org/wiki/Monitoring):
Monitoring ist die Überwachung von Vorgängen. Es ist ein Überbegriff für alle Arten von systematischen Erfassungen (Protokollierungen), Messungen oder Beobachtungen eines Vorgangs oder Prozesses mittels technischer Hilfsmittel oder anderer Beobachtungssysteme.
Ok, erfassen, messen und beobachten. Über das „wie“ wollen wir uns jetzt mal etwas weniger Gedanken machen, viel interessanter ist die Frage nach dem „was“.

Monitoring Allgemein

Gehen wir also zunächst mal der Frage nach was man überhaupt so alles mit einem Monitoring-System überwachen kann. Ich frage dann mal nach bzw. lenke die Diskussion in folgende Richtungen:

Dienste

Netzwerk um die Welt.

Vernetzte Dienste

Eine der häufigsten Antworten sind „Dienste“ oder die „Verfügbarkeit von Diensten“. Das kann sowas einfaches sein wie ein Ping auf Server, Router oder sonstige Geräte. Oder mit etwas mehr Anspruch weil via Protokoll verbunden wird um z.B. nachzusehen ob ein Mailserver artig Hallo sagt, ob ein Webserver eine Webseite ausliefert usw. Das ist ok und richtig so. Nur allzu oft wird hierbei etwas ganz wichtiges übersehen. Kurzer Exkurs: Häufig wird der Dienst alle 5 Minuten geprüft. Im Falle eines Fehlers wird der Abstand verkürzt, oftmals auf zwei Minuten. Bei 3 hintereinander aufgetretenen Fehlern wird alarmiert. Dann mal fix zusammen gerechnet was hier als worst case raus kommt: 9 Minuten. Also nach 9 Minuten wird jemand kontaktiert. Wieder eine offene Frage: Wie wird kontaktiert? Per Email, per SMS? Per Messanger (wie auch immer die heißen mögen)? Wie lange dauert es im Schnitt bis jemand auf die Nachricht reagiert und tatsächlich was tun kann? Und jetzt die einzig spannende Frage zu diesem Bild: Meint Ihr wirklich, dass bei einem produktionskritischen System wo Kunden drauf sind es um die 10 Minuten dauert bis die anrufen um sich zu beschweren, dass Sie nichts mehr arbeiten können? Exkurs Ende. Dienste überwachen ist wichtig. Nur braucht das allzu oft anzutreffende Zeitmodel wie gerade gezeigt eine dringende Überarbeitung. Es ist auf Dauer sehr ungünstig wenn die Kunden das bessere Monitoringsystem sind 😉

Hardware und Co.

Das mit den Diensten muss besser werden. Eine Möglichkeit das zu optimieren ist der Blick auf die Hardware. Was macht die CPU Auslastung? Wie voll ist die Festplatte? Wie steht es um den Arbeitsspeicher? Das sind sinnvolle Ergänzungen die einem helfen ein besseres Verständnis für die Last auf einem System zu bekommen. Und oftmals erhält man hier rechtzeitig Hinweise und kann agieren bevor was ausfällt. Ein Beispiel der von mir gerne verwendeten Hardware-Checks gibt es hier: Monitoring Linux Extended Memory.

Dienste 2.0

Schon wieder Dienste. Die hatten wir doch schon. Ja, zumindest einen Teil. Ich selbst bin riesengroßer Fan davon auch die andere Seite von den Diensten zu betrachten. Beispiel Webserver Apache: Das der Dienst verfügbar ist kann man mittels http bzw. https Anfrage an den Webserver prüfen. Kommt die erhoffte Webseite zurück ist alles gut. Nur was macht der Webserver eigentlich alles? Apache kennt einen Server Status der genau dies verrät. Ein Beispiel wie so etwas aussehen kann? Gibt es hier: https://exchange.icinga.com/dsbits/apache_serverstatus. Oder Du schaust in die angefügte Galerie: Dort sind ebenfalls ein paar Beispiele enthalten. Das habe ich unterm Strich für alles wo etwas mehr Last anliegt bzw. sehr, sehr produktionskritisch ist. Da sind neben dem Beispiel mit apache noch solche Dinge wie ISC DNS, Novell/NetIQ eDirectory, OpenLDAP, NFS-Server, GroupWise, Kopano usw. dabei. Selbst moderne Dateisysteme wie btrfs verraten einem beim genaueren Blick deutlich mehr Details zu ihren internen Vorgängen und Engpässen. Von Routern und Switchen gibt es über die VLANs kaskadierte Sichten zu den Netzwerkports. Netzwerk dicht? Ein Blick aufs Diagramm im Monitoring und sofort ist klar welche VLANs der Auslöser sind. Soviel dazu. Detailschärfe kann im Falles eines Falles das Leben so viel leichter machen. Kombiniert mit sinnvollen Limits und man wird rechtzeitig informiert bevor irgendetwas steht. Angenehmer Seiteneffekt dabei und nochmals am Beispiel apache: Der Server-Status wird ebenfalls via http/https aufgerufen. Also wenn das funktioniert, dann muss der Webserver als solches laufen. Der vorhin angesprochene Check auf http/https kann also weggelassen werden.

Fazit von Dienste 2.0: Mit geschickt gewählten Checks bleibt die Anzahl der Checks unverändert. Der Mehrwert an gewonnenen Informationen: Unbezahlbar 😉

Dienste 2.1

Was, schon wieder Dienste? Ja, bzw. ja… Zum Teil kann es lohnend sein Funktionsgruppen zu testen. Ich nenne das jetzt einfach mal so, folgende zwei Beispiele sollen erklären was ich meine: Eine der Basis-Datenbanken für eine große Softwarelösung sei die CRM-Datenbank mit den Adressdaten aller Kunden. Die ist so groß, dass die auf eigenem Blech läuft und sonst nichts macht außer CRM-DB. Über Webservices ist es möglich, dass externe Dritte Änderungen an den CRM-DB Einträgen vornehmen. Wenn es also funktioniert, dass über Webservices ein neuer Dummy-Kunde angelegt werden kann, dann muss auf dem Weg dazwischen alles funktionieren: Firewall, WAF, Webservices, die dortigen Applikationen und zu guter Letzt die CRM-DB selbst. Ein einziger Check, aber unterm Strich eine riesen große Fülle von Dingen die hierbei, wenn auch zum Teil indirekt, geprüft wurden. Geschickte Peformance-Daten hierbei erfasst und schon hat man eine Grundlage für die monatlichen SLA-Berichte an die Kunden. Monitoring kann Spaß machen. Beispiel 2: Eine Email von einem Server aus dem Internet an einen der via DNS gelisteten MX-Server übergeben und kurze Zeit später via IMAP bzw. GroupWare-Konnektor geprüft ob die Mail da ist. Bzw. Eicar-Testvirus (https://de.wikipedia.org/wiki/EICAR-Testdatei) oder GTUBE Spam-Email (https://de.wikipedia.org/wiki/GTUBE) verschickt – die sollten logischerweise nicht da sein oder in der Quarantäne wieder zu finden. So die Art. Weitere Details: Kopfkino. Mach was draus 😉

Es mag genug Szenarien geben wo so etwas sinnvoll ist. Vor allem wenn man es schafft aus den erfassten Daten noch zusätzliche Informationen wie zum Beispiel das angesprochene SLA-Reporting zu gewinnen.

Luxus

Neben dem bisher gezeigten kann ich noch mit folgenden Beispielen dienen die zum Teil für große Augen sorgen. Einfach mal ein Auflistung einiger Punkte was man so alles machen kann:

  • Für ein Email-Relay welches ausschließlich Emails im Namen von Kunden mit deren Domains versendet: Ein Check welcher prüft, dass die zugehörigen SPF-Records, sofern gesetzt, auch dieses Relay beinhaltet. Natürlich werden die Domains dynamisch ermittelt um bei Änderungen am Adresspool keine Änderung im Monitoring-System zu brauchen.
  • Gute Netzwerkdrucker haben die Möglichkeit via SNMP Daten bereits zu stellen. Toner bald leer, Papier aufgebraucht? Im ersten Fall eine Mail an die Materialwirtschaft damit rechtzeitig Nachschub bereit liegt, im zweiten Fall eine Mail an die Azubis den Papiervorrat wieder aufzufüllen. Und bei geleasten Geräten nebenbei die monatlichen Zählerstände an den Dienstleister versendet.
  • Via Montioring-API alle https-Webserver ermitteln und den SSL/TLS-Stack zu prüfen. Zum Beispiel hiermit: https://testssl.sh/. Mit geeigneter Monitoringsoftware kann der Link zum Bericht gleich noch bei den Check-Details mit eingefügt werden. Testssl kann dies darüber hinaus auch für SMTP-Server.
  • Für Webseitenentwickler ist der Pagespeed sehr wichtig. Warum externe Tools verwenden wenn man doch selbst die Time To First Byte (TTFB) überwachen kann?
  • Wir haben genügend Monitoring Checks die überprüfen wie die Hitrate eines Caches ist. Aber mal ehrlich, wer schaut da rein? Die zugehörigen Admins. Warum hier nicht gleichzeitig neben der Hitrate eine Empfehlung berechnen lassen auf welchen Wert man die dazugehörigen Einstellungen setzen müsste? Geheimnis ist das keins, die zugehörigen Formeln stehen oftmals im Handbuch des Servers. Macht das Admin Leben leichter da man nicht jedes mal selbst nach diesen Formeln die passenden Werte berechnen muss. Und dank Laufzeitdiagrammen hat man sogar noch eine Trendübersicht.

Und das waren nur ein paar Beispiele. Alles nur theoretischer Natur? Hab ich so bereits alles in der Praxis zum laufen gebracht – mehrfach zum Teil sogar. Da geht aber noch viel, viel mehr. Und bis jetzt ist das doch alles ok und alles andere als verwerflich. Was soll daran so böse sein wo man sich um Ethik und Moral Gedanken machen müsste? Nun ja, eins hat dies bisher gezeigt: Überwacht werden kann eigentlich so ziemlich alles. Und man kann richtig viel Information daraus gewinnen. Im nächsten Abschnitt gebe ich ein paar Bespiele was man sonst noch so machen könnte – wenn man wirklich wollte.

Very special Monitoring

Fangen wir mal hiermit an: In vielen mittleren und größeren Unternehmen gibt es Webproxys welche für das Surfen im Internet verwendet werden. Ohne Frage, dass Proxys eine Daseinsberechtigung haben und viele Vorteile mitbringen. Wenn dann auch noch solche Mechanismen wie Single-Sign-On (SSO) dazu kommen wird das richtig super in der Handhabe. Und im Hintergrund noch das Surfverhalten jedes einzelnen Mitarbeiters mit den gängigen Blacklists oder der firmeninternen Whitelist abgeglichen und schon hat man den „surft geschäftlich Quotient“ ermittelt. Der ist über Tage hinweg zu tief? Automatische Meldung an den Abteilungsleiter und/oder ins Personalbüro.

Na und bei Email geht das sogar noch einfacher und braucht so zusätzliches Zeug wie SSO doch gar nicht. Die Absender- bzw. die Empfängeradresse ist doch eindeutig. Dazu noch rasch das Unternehmensadressbuch via passender API vom Groupware System abgerufen und abgeglichen. Und Tada: Brauchbare Zahlen über die sich jeder cholerische Personalchef freut!

Bei Dir gibt es eine elektronische Schließanlage? Na wunderbar, schon wieder genug Zahlenfutter welches mit den vereinbarten Arbeitszeiten abgeglichen werden kann.

Das folgende hatten wir mal als Aprilscherz in einer größeren Monitoringumgebung geplant. Auf jedem Arbeitsplatz lief hier Windows. Also via WMI oder Powershell-Remote von jedem Rechner ausgelesen wer angemeldet ist und ob der Bildschirmschoner läuft. Im Monitoring kann dadurch rasch geprüft werden ob es sich lohnt zu einem Kollegen los zu laufen oder ob man doch lieber noch etwas wartet. So in Analogie zur Trojan-Room-Kaffemaschine 😉 Details zu dieser gibt es zum Beispiel hier: https://de.wikipedia.org/wiki/Trojan-Room-Kaffeemaschine.

Das war noch nicht bedenklich genug? Bitte, da geht noch mehr! Aus den Informatonen lässt sich wunderbar eine effektive Arbeitszeit ermitteln. Ja, aber der Kollege könnte doch mal im Meeting sein oder am geschäftlich telefonieren… Und Du denkst das ist ein Problem? Fix im Groupware Terminkalender nachgeschaut ob ein Termin drin steht oder ob laut Telefonanlage der Anschluss gerade besetzt ist.

Apropos Telefonanlage: Du weißt ja, Anlagen zeichnen geführte Gespräche in der Anrufliste auf. Das Unternehmensweite Adressbuch hatten wir ja schon mal im Zusammenhang mit Email. Also fix die Telefonate gegen die Nummern aus dem Adressbuch abgeglichen und schwupp, schon wieder beim privat telefonieren erwischt.

Wer ein Ticketsystem verwendet kann hier zum Beispiel die Anzahl der gelösten Tickets pro Kopf ermitteln. Ok, jeder der darin arbeitet weiß, dass es Tickets gibt die rasch erledigt sind während andere schon mal etwas Hirnschmalz erfordern um gelöst zu werden. Moderne Ticketsysteme kennen aber die Quote der wieder geöffneten Tickets. Ebenso lässt die Anzahl der ausgetauschten Nachrichten je Ticket auf dessen Komplexität schließen. Also wieder eine messbare Eigenschaft über mehrere verknüpfte Werte. Fehlt noch der Bezugswert mit dem dieser Quotient verglichen wird. Da bietet sich zum Beispiel der Abteilungsschnitt an. Das hier keiner behaupten kann die Tickets der Vertriebsabteilung hätten eine andere Komplexität als die der IT-Abteilung. Und genau das ist doch der Punkt und die Lösung steckt bereits in der Behauptung drin: Dann vergleiche doch auf Abteilungsbasis. Oder was auch immer der gemeinsame Nenner bei Dir im Unternehmen ist. Ein paar Male in Folge im Monat als schlechtester Mitarbeiter gekürt oder im Jahresschnitt zu weit hinter den Kollegen zurück? Schon kommt der große Holzhammer vorbei…

Ja und für die Programmierer die sich gerade noch entspannt zurück lehnen: Meint Ihr nicht auch, dass dank Revisionskontrollsystemen sehr elegant ermitteln werden kann wie viel zum Gesamtquellcode von jedem Einzelnen beigetragen wurde? Jaha, aber das ist doch noch keine Aussage über die Qualität des Codes. Manche Zeilen sind viel härter erarbeitet als andere die locker von der Hand gehen. Das mag ja alles sein, aber schon mal was von Quellcode-Bewertungen gehört? So wie z.B. COCOMO? Siehe für allgemeines hier: https://de.wikipedia.org/wiki/COCOMO. Oder gleich noch ein passendes Tool gefällig? Das gibt es hier: https://github.com/boyter/scc. Die Best-Of Liste von unten her gelesen wird dann jeden Monat in der Toilette aufgehängt. Oder wie sagte mein alter Mathelehrer an der Oberstufe immer? „Einmal an der Tafel blamiert fördert die Arbeitsmoral!“

Fazit

„Diese Abmahnung wurde maschinell erzeugt und benötigt keine Unterschrift.“  Dabei ging dieser Text doch nur der Frage nach was man denn so alles überwachen kann. Mit ein paar technischen Hinweisen wie man das umsetzen könnte. Hier wird global auf individueller Ebene entschieden ohne Rücksicht darauf ob die erfassten Daten für die gerade im speziellen betrachtete Situation überhaupt vollständig sind. Um im Bild der Zeit zu bleiben wird das Ergebnis per sozialem Netzwerk an der jeweiligen Pinnwand aufgehängt. Unbequeme persönliche Kommunikation mit Konfliktpotential? Wo denkst Du hin? Der Flame War der einem entgeht wäre zu schön gewesen. Als IT-Administrator und vor allem auch als IT-Verantwortlicher sollte man sich die richtigen Fragen stellen. Sei Dir bewusst was Du tust und kenne die Konsequenzen. Bekenne Dich zu dem was wirklich richtig ist. Sei mutig. Sage „nein“ wenn es sein muss. Auch oder gerade deswegen im IT-Umfeld. Ethik und Moral.

by Jun 17, 2019 Keine Kommentare
Postfix: IPv6 oder IPv4?

Postfix: IPv6 oder IPv4?

Email

Mal wieder ein Problem zum Thema Email und Postfix. Neulich erst SMTPUTF8, jetzt wieder etwas was sich der Admin vor Ort nach Erklärungen und Lösungen sucht.

Fortune hat einmal zu mir folgendes gesagt:

The light at the end of the tunnel may be an oncoming dragon.

Für alle diejenigen die fortune nicht kennen: https://de.wikipedia.org/wiki/Fortune_(Computerprogramm).

Achtung!

Man sollte natürlich richtig prüfen, ob die IPv6 Auflösung eventuell sogar wirklich ein Problem hat. Da die Frage aufkam hier das grobe Vorgehen dazu: In der Fehlermeldung steht eine IPv6 Adresse drin. Diese per Reverse-DNS auflösen. Der Rechnername, der hierbei raus kommt sollte via Forward-DNS wieder zur gleichen IPv6 Adresse führen. Unterm Strich genauso, wie es auch für IPv4 der Fall sein sollte. Bitte dran denken. Nur wenn das alles passt und immer noch nichts hilft, dann kann dieses vorgehen wie hier beschrieben eine sinnvolle Variante sein.

Das Spiel beginnt

Bevorzugt kommen solche Fragen ja immer am spätem Nachmittag rein. Mal wieder das Thema Email. Mal wieder auf den ersten Blick dubios: Angeblich kann ein Emailserver keine Mails an eine bestimmte Empfangsdomain senden. Als Grund wird der fehlende Reverse DNS-Eintrag angegeben. Dieser ist aber gesetzt. So auf die schnelle passt hier irgendwas nicht zusammen, der detailliertere Blick ins Protokoll muss her. Hier findet sich folgendes – stark gekürzt und anonymisiert. Du weißt schon, Datenschutz und so 😉

May  7 14:12:37 methusalix postfix/smtp[587]: 0D2B11E0027: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.57, delays=0.02/0.01/0.33/0.21, dsn=2.0.0, status=sent (250 OK id=1hNyxZ-00061t-DZ)
May  7 14:12:37 methusalix postfix/smtp[587]: 9600B1E0028: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.35, delays=0.01/0/0.22/0.12, dsn=2.0.0, status=sent (250 OK id=1hNyxZ-00068z-RW)
May  7 14:13:23 methusalix postfix/smtp[587]: EAE621E0028: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.4, delays=0.01/0/0.21/0.18, dsn=2.0.0, status=sent (250 OK id=1hNyyJ-0007Tp-6X)
May  7 14:55:19 methusalix postfix/smtp[6340]: A672D1E0027: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.65, delays=0.01/0/0.5/0.14, dsn=2.0.0, status=sent (250 OK id=1hNzct-0006QR-6i)
May  7 15:13:07 methusalix postfix/smtp[8811]: 6C1A31E0027: to=<emfp@aeng.er>, relay=mail.gatew.ay[1:1:1:1::1:1]:25, delay=0.39, delays=0.03/0.01/0.32/0.03, dsn=5.0.0, status=bounced (host mail.gatew.ay[1:1:1:1::1:1] said: 550-Inconsistent/Missing DNS PTR record (RFC 1912 2.1) 550 (methusalix.doma.in) [1:1:1:1::1]:44636 (in reply to RCPT TO command))
Aha… 4x geht es und einmal nicht. Was bei dem einen Versuch anders ist? Der war per IPv6, die anderen via IPv4. Ok, das mag ja jetzt sein: Reverse-DNS für IPv4 gesetzt, für IPv6 schlichtweg vergessen. Fix via host-Befehl im DNS abgefragt auf die IPv6 Adresse die laut Log keinen Reverse Eintrag haben soll: Oh wunder, der ist richtig auflösbar. Ab jetzt wird es seltsam. Aber wie so oft: Erstmal muss eine Lösung her. Die Suche nach der Ursache wird mal wieder hinten angestellt.

Also gut, das hier ist ganz klar ein Fall für den Blick in die Postfix Dokumentation bzw. in die aktuelle Konfiguration.

Recent Postfix SMTP clients randomly select between IPv4 and IPv6 so that mail won’t get stuck when one of the two is down. Wietse Zweitze Venema

Programmierer und Physiker

smtp_address_preference = any ist wie es sich gehört richtig gesetzt. Das macht so einfach mit am meisten Sinn und wird in der Dokumentation letztendlich genauso empfohlen. inet_protocols brauche ich gar nicht zu kontrollieren, muss auf any stehen. Sonst hätte es gar nicht die beiden unterschiedlichen Zustellvarianten geben dürfen. Um jetzt zu verstehen was da passiert sollte man die Doku kennen oder sich an das im Block links angeführte Zitat von Wietse erinnern.

Somit ist die Lösung für dieses Rätsel fix gefunden: Für diese eine Empfangsdomain sollte der Emailausgang ausschließlich auf IPv4 festgelegt werden. Nur kennt Postfix keine inet_protocol_map in der man dies festlegen könnte. Es ist also mal wieder die Frage nach etwas Kreativität um eine passende Lösung mit Postfix Mitteln entsprechend abzubilden.

Und der Weg zum Ziel ist unterm Strich mal wieder ganz einfach: Man definiert in der master.cf einen weiteren smtp Dienst welcher als Option das oben bereits erwähnte inet_protocols = ipv4 hat. Im zweiten Schritt noch fix einen passenden Eintrag für die Zieldomain in der transport Tabelle gesetzt welche genau diesen Dienst verwendet und voilà: Ziel erreicht.

Die Umsetzung

Die folgenden Beispiele zeigen an reinen Textdateien unter /etc/postfix die passende Konfiguration für die Empfängerdomain gehirn-mag.net. Wer dort bereits eine transport-Tabelle hat kann diese selbstverständlich nutzen. Wer ein Datenbank- oder LDAP-Backend hat kann diese Lösung sinngemäß übertragen. Hier aber, der Einfachheit wegen, das Beispiel an den „blanken“ Textdateien. Und Du solltest logischerweise die Empfängerdomain richtig anpassen 🙂

Die erste Datei die geändert wird ist /etc/postfix/master.cf. Hier wird ein weiterer Dienst eingetragen. Eine Zeile analog zur ersten gibt es bereits. Wichtig ist, dass zu Beginn am Anfang und am Ende smtp steht und kein smtpd. Diese kopiert ihr, ändert den Namen (Zeile 2, Spalte 1) und fügt darunter den Inhalt der Zeile 3 ein.

Als nächstes ist /etc/postfix/main.cf dran. Hier ist zu prüfen ob es eine transport_maps Zeile gibt. Falls nicht fügt Ihr diese einfach ein.

Und zu guter Letzt ist die transport Tabelle /etc/postfix/transport selbst. Hier ist der Eintrag für die Zieldomain zu setzen, dass diese unseren neuen IPv4 smtp Dienst verwendet.

smtp      unix  -       -       y       -       -       smtp
smtp-ipv4 unix  -       -       y       -       -       smtp
    -o inet_protocols=ipv4
transport_maps = hash:/etc/postfix/transport
gehirn-mag.net           smtp-ipv4:

Nun müsst Ihr noch via postmap /etc/postfix/transport diese für postfix übersetzen und mit postfix reload den Mailserver neu starten. Postfix versendet nun für Eure Zieldomain alle Mails dorthin via IPv4 anstatt frei zu wählen was er jetzt verwenden könnte.

Und fertig!

Was eine Lösung. Ist das wirklich elegant gemacht auf diese Art und Weise? Ja, das ist Sie. Auf ihre ganz spezielle Art. Einen eigenen Dienst in der master.cf anzulegen macht man eigentlich öfters. Am häufigsten wohl als Ziel für irgendwelche Postfachsysteme wie IMAP/POP3 oder Groupware-Systeme. Wenn man diese externe Domain mit der sinngemäßen gleichen Logik betrachtet ist das schon sehr ähnlich: Ein Postfachspeicher welcher Emails via SMTP annimmt und obwohl er eine IPv6 Adresse hat kann der Dienst aber nur IPv4. Ich betreue Postfix Umgebungen bei denen aufgrund von der Vielzahl und der Größe der dahinter liegenden Groupware Lösungen die transport-Tabelle länger ist bei vielen anderen Installationen die virtual-Tabelle. Da erlebt man noch ganz andere Dinge…

In größeren Emailumgebungen ist man gefühlt nie am Ende mit der Konfiguration angekommen. Man mag sich in dem zu Beginn angesprochenen Tunnel fühlen. Sobald die Ursache aber sauber erfasst wurde ist die Lösung des Problems rasch erledigt und das Ende des Tunnels naht. Bis zum nächsten Anruf 😉

Aber morgen kontaktiere ich erstmals den Emailadmin auf der anderen Seite und frage nach den Gründen für diese Fehlermeldung – Feierabend für heute.

Quellen

  • GNU Bild: Wikimedia – kann aber genauso gut auf gnu.org direkt gezogen werden
  • Wietse Bild: Wikimedia – public domain

by Mai 11, 2019 Keine Kommentare