Archiv ‘IT’

Samstag, 23. Mai 2020

Zwei Cyon IMAP-INBOXen innerhalb von drei Wochen zerschossen

Seit 2012 bin ich glücklicher Kunde von Cyon, eines schweizerischen Hosting-Anbieters. In den letzten drei Wochen hat sich das Erlebnis etwas getrübt.

Wichtig: Die unten beschriebene Problematik hatte ich in den letzten acht Jahren nie, und schon gar nicht innerhalb von drei Wochen zwei Mal. imapfilter hat bisher auch immer reibungslos funktioniert.

Das erste Problem

Am Morgen des Samstag, 9. Mai 2020 konnte ich plötzlich nicht mehr auf meine E-Mails in der INBOX von Konto A zugreifen. Weder in Apple Mail (meinem hauptsächlichen E-Mail-Client), noch über RainLoop (Webmail), noch mit imapfilter, welches ich verwende, um E-Mails automatisiert in Unterordner zu verschieben (oder im Falle von Spam: zu löschen).

Das alle 5 Minuten laufende imapfilter, gepaart mit Healthchecks, ist übrigens auch ein optimales „Frühwarnsystem“, welches mir meldet, wenn mit dem Mailserver etwas nicht stimmt.

Das Log von RainLoop (unter RAINLOOPROOT/data/_data_/_default_/logs) zeigte den Fehler schön auf:

...
[08:55:36.698][1c50d1ff] IMAP[DATA]: > TAG3 SELECT "INBOX"\r\n
[08:55:36.960][1c50d1ff] IMAP[ERROR]: Stream Meta: Array
...
[08:55:36.961][1c50d1ff] IMAP[ERROR]: MailSo\Net\Exceptions\SocketReadException: MailSo-Net-Exceptions-SocketReadException (NetClient.php ~ 523) in %PATH%/rainloop/v/0.0.0/app/libraries/MailSo/Net/NetClient.php:523
Stack trace:
...

Und so sah das Symptom bei imapfilter aus:

...
Sat May  9 10:41:38 2020: reading data through SSL; the connection has been closed cleanly
...

Diese Meldung wurde in einer Schleife ausgegeben, und zwar bei jedem Befehl, der E-Mails filtern und — falls vorhanden — verschieben sollte.

Als ich imapfilter im Debug-Modus laufen liess …

$ imapfilter -v -l log.txt -d debug.txt recipe.imapfilter

… tauchte folgende erhellende Nachricht im Debug Log (debug.txt) auf:

IMAP (5): 107C NO [UNAVAILABLE] Maximum number of connections from user+IP exceeded (mail_max_userip_connections=75)

Weil die IMAP-INBOX nicht abrufbar war, steckten meine Scripts in Endlosschleifen fest, welche die Zahl der Verbindungen pro E-Mail-Konto und IP voll ausschöpfte. Es waren also keine Verbindungen mehr möglich.

Als erstes schaltete ich deshalb den imapfilter-Cronjob ab, um dem IMAP-Server eine Verschnaufspause zu gönnen. Dann wurde rasch klar, dass die E-Mails in der INBOX aus irgendeinem Grund nicht aufgelistet werden konnten. Ich hatte in den zwei Tagen zuvor einige Anpassungen am imapfilter-Konfiguration vorgenommen; eine Möglichkeit war, dass die Verschiebeaktionen dabei zu einer korrupten INBOX-Datei geführt haben könnten.

Obwohl das Problem an einem Wochenende auftrat, schrieb ich dem Support — wohlwissentlich, dass ich erst am Montag eine Antwort erhalten würde. Vielleicht würde ja trotzdem eine gute Seele reinschauen … leider nein, The Computer Says No.

Ich kämpfte deshalb auf eigener Faust weiter: Nach viel Pröbeln wählte ich die Holzhammer-Methode: Nach einem lokalen Backup des kaputten Dovecot-Verzeichnisses löschte ich via SSH alle Dateien im INBOX-Verzeichnis (Pfad: siehe unten), ein frischer Start, sozusagen. Seither funktioniert die INBOX wieder.

Glück im Unglück: Da ich bei Konto A versuche, Inbox Zero anzuwenden, waren nur vier E-Mails von der Löschaktion betroffen, von denen ich die von Apple Mail lokal gespeicherten .emlx an einen sicheren Ort kopieren konnte.

Das zweite Problem

Kurz nach Mitternacht in der Nacht von Donnerstag auf Freitag, 22. Mai 2020 traten gemäss imapfilter Probleme mit Konto B auf. Ich merkte dieses am späteren Freitag-Morgen, als ich mit meinen Mail-Clients nicht mehr auf meine E-Mails in der INBOX von Konto B zugreifen konnte. Dieses Mal gab es aber keine Überlastung der erlaubten Verbindungen. imapfilter meldete bei Abfragen auf die INBOX:

...
Fri May 22 14:47:16 2020: IMAP (5): 127C NO [SERVERBUG] Internal error occurred. Refer to server log for more information. [2020-05-22 14:47:16] (0.040 + 0.000 + 0.039 secs).
...

Ohne Zugriff auf die Logs konnte ich „SERVERBUG“ nicht weiter eingrenzen. Erneut schrieb ich eine E-Mail an den Support (Versand um 15:19 Uhr), und erhielt um 16:57 Uhr eine Antwort. Leider in der Form „Have you tried turning it off and on again?“. Die Hoffnung war verloren, dass mir Cyon noch vor dem Wochenende beim Debugging helfen konnte — somit sah ich ca. 56 Stunden ohne E-Mail entgegen.

Hilfreich war in der ersten Antwort des Supporters einzig der Tipp, anstelle von RainLoop doch bitte das „offizielle“ Webmail von Cyon zu verwenden: webmail.cyon.ch, welches auf RoundCube basiert. Gesagt, getan. So konnte ich dem Supporter klipp und klar belegen, dass das Problem auf der Serverseite lag. Wenn ich die INBOX anwählte, erschien am unteren Bildschirmrand ganz in rot folgende Fehlermeldung:

image-9075

Serverfehler: UID SORT: Internal error occurred. Refer to server log for more information. [2020-05-22 17:59:38] (0.041 + 0.000 + 0.040 secs)

Leider gab es seither keine Antwort mehr, weshalb ich mir erneut selber helfen musste (wieso passieren diese Fehler immer auf’s Wochnenende hin?!)

Das Problem war dieses Mal etwas anderer Natur — Apple Mail und imapfilter zeigten partout keine E-Mails mehr in der INBOX an; die Unterordner konnten hingegen abgerufen werden. RoundCube hingegen zeigte die INBOX etwas erratisch manchmal an, manchmal nicht.

Die schlussendliche Lösung:

  • Per SSH auf den Shared Hosting-Server einloggen
  • Alle dovecot-Prozesse abschiessen mittels
    $ ps ax | grep -i dovecot | grep -v grep | awk '{print $1}' | xargs kill
  • Die (möglicherweise korrupte?) dovecot.index Datei löschen
  • In Cyons RainLoop Webmail einloggen
  • Die E-Mails der letzten Tage im problematischen Mail-Ordner von Hand durchgehen; solche, die nicht angezeigt werden konnten, habe ich kurzerhand gelöscht
  • Einen neuen Unterordner erstellen; bspw. BACKUPYYYYMMDD
  • Alle verbleibenden E-Mails im problematischen Ordner auswählen und in den Backup-Ordner verschieben (ich hatte Angst, dass der Verschiebeprozess nicht funktionieren würde, klappte in dem Fall aber problemlos)
  • Zurück auf SSH wechseln
  • Im Verzeichnis des problematischen Emailordners rm -rf * ausführen, um alle vorhandenen Dateien zu löschen (ACHTUNG: Wer diesen Befehl am falschen Ort ausführt, löscht sich sein gesamtes Benutzerverzeichnis)
  • RoundCube, RainLoop Apple Mail und imapfilter wieder starten resp. öffnen — der problematische Ordner ist jetzt zwar leer, aber kann immerhin wieder ohne Fehlermeldungen abgefragt werden. Im Hintergrund erstellt Dovecot alle benötigten Dateien wieder.
  • Falls gewünscht die E-Mails aus dem Backup-Ordner zurück in den (neu erstellten) ehemals problematischen Ordner verschieben oder kopieren (ACHTUNG: Es könnte sein, dass eine ganz bestimmte E-Mail im Backup Dovecot zum Straucheln bringt; in dem Fall würde man mit der Rückkopieraktion das Problem wieder von vorne starten … bei mir war das glücklicherweise nicht der Fall)

Epilog

Ohne Zugriff auf die IMAP-Logs ist mir aber weiterhin nicht möglich herauszufinden, was denn nun wirklich genau das Problem war. Und so besteht zu befürchten, dass das Problem jede Minute erneut auftreten kann.

Und nein, ich gebe nicht Cyon die Schuld: Es könnte sein, dass mein spezielles Setup mit 5-minütigen imapfilter-Verbindungen die Ursache hinter den Problemen ist. Bspw. eine Anpassung, welche tausende E-Mails verschiebt und der Mailserver noch am kopieren ist, wenn der nächste imapfilter-Prozess bereits wieder startet und gerade in Kopie befindliche E-Mails irgendwohin kopiert. Oder ein Software-Update meiner Debian-Systeme in den letzten drei Wochen.

Es könnte aber auch sein, dass der Fehler bei Cyon zu suchen ist — d.h. ein kaputter RAM-Baustein, der beim Schreiben IMAP-Ordnerdateien korrumpiert, oder das Storage-System, welches zu schreibende Daten verfälscht, oder ein Update von Dovecot, nach welchem sich die Software nicht mehr wie gewohnt verhält. Oder eine Inkompatibilität zwischen der neuen Dovecot-Version mit dem bisherigen imapfilter; oder mit dem neuen imapfilter und der bisherigen Dovecot-Version.

Cyons E-Mail-Infrastruktur

Was ich bei diesen Problemen über Cyons E-Mail-Infrastruktur gelernt habe:

  • Cyon verwendet Dovecot als IMAP-Server
  • Ist man per SSH auf dem Cyon-Server eingeloggt, kann man sich die (eigenen) laufenden IMAP-Server-Prozesse mit folgendem Befehl anzeigen lassen. Die Zahl der Prozesse ist meines Erachtens proportional zur Anzahl der Clients, die gerade per IMAP E-Mails abfragen (mindestens 1 Prozess, es können aber durchaus auch mehrere pro Client sein).
    $ ps ax | grep -i dovecot
    3662642 ?        S      0:00 dovecot/imap
    3662645 ?        S      0:01 dovecot/imap
    3662646 ?        S      0:00 dovecot/imap
    3662706 ?        S      0:00 dovecot/imap
    3663038 ?        S      0:00 dovecot/imap
    3664246 ?        S      0:00 dovecot/imap
    3674314 ?        S      0:00 dovecot/imap
    3674316 ?        S      0:00 dovecot/imap
    3674317 ?        S      0:00 dovecot/imap
    3674449 ?        S      0:00 dovecot/imap
  • Die Mail-Daten eines Benutzers liegen in einer Ordnerstruktur unter /userdata01/%CYONUSER%/mail
  • Die Mail-Ordner einer E-Mailadresse %EMAILUSER%@%DOMAIN% finden sich unter /userdata01/%CYONUSER%/mail/%DOMAIN%/%EMAILUSER%/mailboxes
  • In einem Mail-Ordner finden sich normalerweise folgende Dateien:
    drwxr-x--x 2 user user    158 May 23 17:02 ./
    drwxr-x--x 3 user user     32 May 23 16:43 ../
    -rw-r----- 1 user user  15024 May 23 16:41 dovecot.index
    -rw-r----- 1 user user  15024 May 23 16:41 dovecot.index.backup
    -rw-r----- 1 user user 391208 May 23 17:34 dovecot.index.cache
    -rw-r----- 1 user user   2144 May 23 17:02 dovecot.index.log
    -rw-r----- 1 user user  32928 May 23 16:41 dovecot.index.log.2
  • Löscht man die Cache-Datei dovecot.cache in einem Mailordner (kann mehrere hundert Megabytes oder sogar Gigabytes gross sein), wird diese von Dovecot nicht automatisch neu generiert. Nichts geht mehr; d.h. der Ordner wird als leer angezeigt.
  • Löscht man die Index-Datei dovecot.index, wird diese von Dovecot automatisch neu generiert. Beim zweiten Problem half dies tatsächlich, dass ich wieder Zugriff auf E-Mails erhielt.

Tags: , , , , , , ,
Labels: IT, Schweiz, Web

Keine Kommentare | neuen Kommentar verfassen

Montag, 20. April 2020

upc kappt Peering mit Init7 / Fiber7

Ich habe vor einigen Jahren mit OpenVPN ein Site-to-Site VPN zu einem Bekannten in der Agglomeration Bern aufgebaut und betreibe dieses VPN bis heute.

Der Bekannte ist Kunde von upc cablecom (der schnellste und preiswerteste Anbieter in der Agglomerationsgemeinde) mit einem 300 MBit/s Download-Abo, ich als Städter bekanntermassen Kunde von Fiber7 mit (theoretisch) symmetrischen 1 GBit/s.

Letzte Woche (KW16 2020) waren SSH-Verbindungen zu einem Server beim Bekannten auf einmal sehr, sehr hakelig — die Latenz zwischen Tastatureingabe und erscheinen des Zeichens auf dem Bildschirm war sehr hoch. Bestätigt wurde diese durch meine Überwachung der Geschwindigkeit mit speedtest-cli und Aufzeichnung und Visualisierung der Werte mit Cacti:

image-8955

Der Einbruch am Dienstag-Morgen war offensichtlich.

Eine fiebrige, verbissene Suche begann: War ein Angreifer in das Netzwerk eingedrungen und zog nun Gigabyte-weise an Daten ab? Oder war ein Rechner eines Mitbenutzers von Malware gekapert worden? Oder führte der Mitbenutzer einfach nur tonnenweise Bittorrent-Downloads durch? Oder war eine Netzwerkkomponente ausgetickt und flutete das Netzwerk und den Router mit Paketen? Oder hatte upc cablecom einfach etwas am Netzwerk geschraubt, worauf der Geschwindigkeitseinbruch manchmal nur mit einem Neustart des Modems behoben werden konnte?

Die Nachforschungen brachten nichts zu Tage, aber immerhin lernte ich folgende Netzwerkanalyse-Tools/Features meiner Infrastruktur kennen:

  • Traffic Analysis des EdgeRouters X ER-X, welcher am Kabelmodem hängt
  • iftop Zeigt in Echtzeit an, von und zu welchen IPs ein Server Daten übertragt (Homepage)
  • iptraf-ng (Homepage)

Am Dienstag-Abend ereilte mich ein Geistesblitz: speedtest-cli misst die Geschwindigkeit von einem Server am Agglomerations-Standort zum Ookla Speedtest-Server von Init7 (Server „Init 7 (Winterthur, Switzerland)“ mit ID 3026). Aus Interesse wählte ich einen anderen Server aus der Liste aus, und zwar den Speedtest-Server von Sunrise. Zuerst führte ich einen manuellen Speedtest zu Init7 durch, danach zu Sunrise. Und siehe da, hier lag die Antwort wie auf dem Präsentierteller:

$ ./speedtest-cli --server 28045
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from UPC Schweiz (80.218.X.X)...
Hosted by Sunrise Communication AG (Lausanne) [6X.XX km]: 30.667 ms
Testing download speed........................................
Download: 302.88 Mbit/s
Testing upload speed..................................................
Upload: 42.32 Mbit/s

$ ./speedtest-cli --server 3026
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from UPC Schweiz (80.218.X.X)...
Hosted by Init 7 (Winterthur) [13X.XX km]: 165.956 ms
Testing download speed........................................
Download: 25.82 Mbit/s
Testing upload speed..................................................
Upload: 9.48 Mbit/s

Am selben Abend sendete ich eine Anfrage an Init7 raus, ob und wie sie sich diesen markanten Geschwindigkeits-Unterschied erklären können. Am Morgen hatte ich die Antwort, und wurde auf folgendes Schreiben verwiesen. Diese Meldung war bei mir im Corona-Trubel vollkommen untergegangen.

Fazit: upc cablecom, how dare you?

Nachtrag

smokeping visualisiert die Latenz von DNS-Abfragen aus dem upc cablecom-Netz gegen den DNS-Server von Init7 ebenfalls sehr schön:

image-8956

Auf Wunsch Thomas‘ (siehe Kommentar unten) noch dieselbe Grafik für Test-Abfragen an einen der DNS-Server der upc cablecom (ns10.cablecom.net) …

image-8957

… zu Swisscom (dns2.bluewin.ch) …

image-8958

… und zu Sunrise (cache02.sunrise.ch)

image-8959

Tags: , , , , , , , , , , , , , , , , ,
Labels: IT, Schweiz

7 Kommentare | neuen Kommentar verfassen

Montag, 13. April 2020

HP ProBook 6570b erkennt bootbaren USB-Datenträger nicht

Gestern half ich einer Bekannten, ihr HP ProBook 6570b mit einer vom Software-Hersteller nicht mehr unterstützten Windows 7 Professional-Installation auf Windows 10 zu lüpfen.

Diese unsägliche Upgrade-Odyssee bestätigte mir wieder einmal, dass mein Entscheid 2004 richtig war, Windows den Rücken zu kehren und auf Mac OS X (heute: macOS) sowie Debian GNU/Linux zu setzen.

Frickelmässig hat sich im Umgang mit Windows kaum etwas geändert — mit Backup-Image, dateibasiertem rsync-Backup, Installationsdatenträger herunterladen und erstellen sowie drei (!) Installationsversuchen (Stichwort: 0x800f0955 - 0x20003 und „The installation failed in the SAFE_OS phase with and error during INSTALL_UPDATES operation.“) habe ich gut und gerne 12 Stunden verbraten.

Ein kleines Problem ganz zu Beginn: Der USB-Installationsdatenträger, ein 8GB USB-Stick, wurde vom HP BIOS anfänglich nicht als Bootquelle aufgeführt (beim Booten ESC drücken, dann F9). Nach viel Haare ausreissen dann die Erkenntnis auf Grund eines Tipps in einem Forum: Ich hatte den Datenträger an einem der zwei SS (SuperSpeed) USB-Anschlüsse auf der rechten Seite des Geräts angeschlossen. Das BIOS erkennt aber nur USB-Datenträger, die am linken USB/eSATA-Anschluss angeschlossen werden.

Wie bescheuert ist das denn?!

Tags: , , , , , , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Montag, 13. April 2020

Bildschirm eines Debian-Servers nach Inaktivität ausschalten

Ich habe hier bereits erwähnt, dass gebrauchte ThinkPads mit Debian die Linux-Server meiner Wahl sind.

Gestern habe ich meinen ELK Log-Server von einem Lenovo ThinkPad X201 auf ein Lenovo ThinkPad T440p migriert (und habe gleichzeitig von einem unsäglichen Docker-Gefrickel auf native Pakete gewechselt).

Eines der bis eben ungelösten Probleme war, dass sich der Bildschirm des ThinkPads nach einer Inaktivitäts-Zeitlimite nicht automatisch ausschaltete. Das habe ich nun folgendermassen gelöst:

/etc/default/grub

...
GRUB_CMDLINE_LINUX_DEFAULT="consoleblank=60"
...

Der Wert 60 drückt die Inaktivitätszeit in Sekunden aus.

Danach muss noch GRUB aktualisiert werden, und dann wird’s ab dem nächsten Neustart nach 60 Sekunden dunkel:

# update-grub

Tags: , , , , , , , , , , , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 9. April 2020

Hände weg von Zoom

Zoom is a security and privacy disaster, […] In the meantime, you should either lock Zoom down as best you can, or — better yet — abandon the platform altogether.

Quelle: Security and Privacy Implications of Zoom

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 1. März 2020

Unter macOS High Sierra mit MacPorts, postfix und s-nail E-Mails versenden

Emails von der Kommandozeile versenden — was man bei Linux im Handumdrehen hinkriegt, erforderte bei mir unter macOS stundenlange Handstände.

MacPorts postfix anstelle macOS postfix

Doch jetzt habe ich den Kniff raus: Die von macOS mitgelieferte postfix-Installation habe ich schlussendlich ignoriert und auf das MacPorts postfix-Paket gesetzt.

MacPorts Variants nicht vergessen

Der erste Fallstrick lauert schon hier: Um heutzutage über einen Hoster E-Mails zu versenden, benötigt man zwingend SASL und TLS. Diese Features müssen als sog. MacPorts Variants explizit mitinstalliert werden, sonst landen sie nicht auf dem Mac:

# port install postfix +sasl +tls

Ansonsten meldet postfix:

...
Mar 01 14:16:11 imac postfix/smtp[70687]: warning: smtp_sasl_auth_enable is true, but SASL support is not compiled in
Mar 01 14:16:11 imac postfix/smtp[70687]: warning: TLS has been selected, but TLS support is not compiled in
...

Verzeichnisse und Pfade zur Sicherheit hardkodieren

Eine funktionierende postfix-Konfiguration mitsamt Installationsscript habe ich von meinen Linux-Servern herüberkopiert (diese Anleitung alleine würde das Format dieses Blog-Artikels sprengen). Die Konfiguration habe ich aber mit den MacPorts-Einstellungen ergänzt. Denke daran: Bei Linux liegen die Konfiguration sowie die Arbeitsverzeichnisse allesamt am erwarteten Ort (bspw. /etc/postfix/main.cf). Da wir unter macOS auf MacPorts setzen, liegt dieselbe Datei hier unter /opt/local/etc/postfix/main.cf. Deshalb habe ich zur Sicherheit in main.cf folgende von MacPorts vorgeschlagene Ergänzungen (siehe /opt/local/etc/postfix/main.cf.sample) hinzugefügt:

$ cat /opt/local/etc/postfix/main.cf
# Directories
queue_directory = /opt/local/var/spool/postfix
command_directory = /opt/local/sbin
daemon_directory = /opt/local/libexec/postfix
data_directory = /opt/local/var/lib/postfix
meta_directory = /opt/local/etc/postfix
manpage_directory = /opt/local/share/man
sample_directory = /opt/local/share/postfix/sample
readme_directory = /opt/local/share/postfix/readme
shlib_directory = no
html_directory = no

# Paths
sendmail_path = /opt/local/sbin/sendmail
newaliases_path = /opt/local/bin/newaliases
mailq_path = /opt/local/bin/mailq

# Log
maillog_file_prefixes = /var, /var/log/macports/postfix
maillog_file = /var/log/macports/postfix/postfix.log

# Other stuff ...
mail_owner = _postfix
setgid_group = _postdrop
default_privs = nobody
unknown_local_recipient_reject_code = 550
debug_peer_level = 2
...

Logs in eine Datei schreiben

Weiter hatte ich während dem Debuggen so meine liebe Mühe, die Logging-Informationen zu finden, da diese an syslog gesendet werden und bei macOS dann in der Console.app landen. Deshalb habe ich im Gegensatz zu meinen Linux-Installationen auch noch die Konfigurationsdatei /opt/local/etc/postfix/master.cf anpassen müssen. Essentiell war es, die folgende Zeile einzufügen:

...
postlog   unix-dgram n  -       n       -       1       postlogd
...

Quelle: Postfix logging to file or stdout

Verhindern, dass fälschlicherweise die macOS postfix-Konfiguration geladen wird

Damit mir die Parallelinstallation von Postfix nicht in die Quere kommt und ich mir sicher war, dass die MacPorts-Installation von postfix tatsächlich die Konfiguration unter /opt frisst, habe ich kurzerhand den macOS postfix-Ordner verschoben:

# mv /etc/postfix /etc/postfix.bkp

Ob das wirklich nötig gewesen wäre sei dahingestellt; Vorsicht, wer das auf seinem System macht: Ich garantiere für nichts.

Postfix starten und stoppen

Die Postfix-Installation lädt man folgendermassen:

# port load postfix
# launchctl unload /Library/LaunchDaemons/org.macports.postfix.plist
# launchctl load -w /Library/LaunchDaemons/org.macports.postfix.plist

Die plist-Datei zeigt als symbolischer Link nach /opt/local/etc/LaunchDaemons/org.macports.postfix/org.macports.postfix.plist. In dieser Datei habe ich folgendes angepasst/ergänzt — das ist nicht zwingend nötig, sollte aber dazu führen, dass Postfix bei jedem Neustart automatisch gestartet wird. Ausserdem sollten im Fall von Start-Problemen Fehlermeldungen in eine Log-Datei geschrieben werden:

...
        <string>--pid=none</string>
    </array>
    <key>Disabled</key>
    <false/>
    <key>KeepAlive</key>
    <true/>
    <key>StandardOutPath</key>
    <string>/var/log/launchd.macports.postfix.standard.log</string>
    <key>StandardErrorPath</key>
    <string>/var/log/launchd.macports.postfix.error.log</string>
</dict>
</plist>

s-nail verwendet standardmässig die macOS mail-Executables

Anschliessend musste noch eine Mail-Programm her, welches erlaubt, den Absender eines E-Mails selber zu setzen. MacPorts bietet hierzu s-nail an (Homepage des Entwicklers).

# port install s-nail

Als ich mit s-nail ein Test-Mail versenden wollte folgte eine weitere Hiobs-Botschaft:

$ echo "Test email" | mail user@domain.tld
unknown: fatal: open /etc/postfix/main.cf: No such file or directory
/Users/user/dead.letter 7/135
mail: ... message not sent

Ich übertreibe nicht, wenn ich sage, dass ich Stunden mit Debugging verbracht habe. Bis ich plötzlich realisierte, dass s-nail die offiziellen Mail-Executables mail, mailx und/oder sendmail unter /usr/bin verwendet. Der Lackmus-Test: Wenn ich diese Mail-Executables manuell aufrief, erschien ein- und dieselbe Fehlermeldung.

Dies obwohl meine Bash PATH-Variable /opt/local/bin und /opt/local/sbin vor /usr/bin und /usr/sbin nennt, verwendete s-nail aus irgendeinem Grund standardmässig die letztgenannten Pfade.

Wie sage ich s-nail aber, dass es stattdessen die MacPorts mail-Befehle verwenden soll? Folgende Anpassung in /opt/local/etc/mail.rc war nötig:

...
set mta=/opt/local/sbin/sendmail

Absender (From:) der E-Mails selber festlegen

Anschliessend musste noch eine Mail-Programm her, welches erlaubt, den Absender eines E-Mails selber zu setzen. Ich verwende in Bash-Scripts sehr oft folgendes Konstrukt, und ich wollte sicherstellen, dass die Scripts sowohl unter Debian GNU/Linux als auch macOS laufen (Argument -a):

$ echo -e "Test" | $(which mail) -a "From: DNS Query Analyzer " -s 'Top 25 DNS Queries' user@domain.tld another.user@domain.tld

Ich habe leider eine schlechte, aber auch eine gute Nachricht. Die gute: Man kann auch unter macOS den Absender setzen. Leider aber nicht mit demselben Befehl wie unter Debian GNU/Linux.

Bei s-nail muss ich leider ein anderes Argument verwenden:

$ echo -e "Test" | $(which mail) -r "DNS Query Analyzer " -s 'Top 25 DNS Queries' user@domain.tld another.user@domain.tld

Postfix hat Probleme mit selber gesetzter Absenderadresse und SPF Records

Doch nun trat bereits das nächste Problem auf, wie ein Blick in die leere INBOX und in /var/log/macports/postfix.log zeigte:

...
Mar 01 15:43:59 imac postfix/smtp[81049]: 4D0E3FBBE221: to=<user@domain.tld>, relay=s000.cyon.net[149.126.4.000]:25, delay=20, delays=0.03/20/0.03/0.04, dsn=5.0.0, status=bounced (host s000.cyon.net[149.126.4.000] said: 550 SPF: 1.2.3.4 is not allowed to send mail from emeidi.com (in reply to RCPT TO command))
...

Faszinierend. Unter Linux hatte ich eine solche Fehlermeldung noch nie gesehen. Ich verwende für den Versand „offizieller“ E-Mails jeweils emeidi.com als Absenderadresse.

Schlussendlich blieb nur die Holzhammer-Methode. Ich verschob alle Konfigurationsdateien, welche auf meinen Linux-Installationen nicht existierten, von /opt/local/etc/postfix in den Unterordner _old. Schlussendlich sah das Verzeichnis so aus:

$ find /opt/local/etc/postfix/opt/local/etc/postfix
/opt/local/etc/postfix/_old
/opt/local/etc/postfix/_old/access
/opt/local/etc/postfix/_old/access.sample
/opt/local/etc/postfix/_old/aliases
/opt/local/etc/postfix/_old/aliases.sample
/opt/local/etc/postfix/_old/bounce.cf.default
/opt/local/etc/postfix/_old/canonical
/opt/local/etc/postfix/_old/canonical.sample
/opt/local/etc/postfix/_old/generic
/opt/local/etc/postfix/_old/generic.sample
/opt/local/etc/postfix/_old/header_checks.sample
/opt/local/etc/postfix/_old/LICENSE
/opt/local/etc/postfix/_old/main.cf.default
/opt/local/etc/postfix/_old/main.cf.proto
/opt/local/etc/postfix/_old/main.cf.sample
/opt/local/etc/postfix/_old/master.cf.proto
/opt/local/etc/postfix/_old/master.cf.sample
/opt/local/etc/postfix/_old/relocated
/opt/local/etc/postfix/_old/relocated.sample
/opt/local/etc/postfix/_old/TLS_LICENSE
/opt/local/etc/postfix/_old/transport
/opt/local/etc/postfix/_old/transport.sample
/opt/local/etc/postfix/_old/virtual
/opt/local/etc/postfix/_old/virtual.sample
/opt/local/etc/postfix/header_checks
/opt/local/etc/postfix/main.cf
/opt/local/etc/postfix/makedefs.out
/opt/local/etc/postfix/master.cf
/opt/local/etc/postfix/postfix-files
/opt/local/etc/postfix/sasl
/opt/local/etc/postfix/sasl/outgoing
/opt/local/etc/postfix/sasl/outgoing.db

In sasl/outgoing entfernte ich zudem den TCP-Port nach der Server-Adresse, und master.cf ergänzte ich mit Zeilen, die bisher nur unter Linux existierten.

Heureka

Und jetzt endlich kann ich mir von der Kommandozeile aus E-Mails senden. Hat nur geschlagene sechs Stunden gedauert.

Tags: , , , , , , , , , , , , , , , ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Montag, 10. Februar 2020

Raspberry Pi zeigt ständig „Can’t update Chromium“ Overlay an

Mein Dashboard zu Hause läuft auf einem Raspberry Pi 3 mit Debian Buster 10.2. Der RPi lädt beim morgendlichen Neustart um Punkt 05:00 Uhr den Chromium-Browser, welcher die Web-Site mit dem Dashboard aufruft.

Seit ein paar Tagen zeigt Chromium oben rechts ein Layover mit folgender Meldung an:

Can’t update Chromium

Chromium couldn’t update to the latest version, so you’re missing out on new features and security fixes.

(da ich selber kein Photo des Dashboards angefertigt habe, verlinke ich hier auf einen Screenshot eines anderen Benutzers aus dem Internet)

Da Debian kein Update von Chromium anbietet, hilft ein apt-get upgrade chromium hier leider nicht weiter.

Das Symptom behebt man, indem man Chromium mit einem zusätzlichen Kommandozeilenargument startet — nachfolgend ein Auszug aus /home/pi/.config/lxsession/LXDE-pi/autostart:

...
@chromium-browser --no-default-browser-check --check-for-update-interval=604800 --disable-pinch --incognito --kiosk

Den Tipp mit --check-for-update-interval=604800 (Eintrag in der Liste der Kommandozeilenargumente) habe ich auf Stack Overflow in der Frage Disable “chrome is out of date” notification gefunden.

Da man als verantwortungsvoller SysAdmin entweder Debian unattended-upgrades respektive cron-apt (Vergleich) eingerichtet hat, oder sich zumindest automatisiert über Paket-Aktualisierungen informieren lässt, ist diese Symptombekämpfung vertretbar.

Die Entwickler von Chromium könnten sich meiner bescheidenen Meinung nach überlegen, ob es nicht besser wäre, nur dann eine Meldung anzuzeigen, wenn auch tatsächlich ein Update verfügbar ist. Denn die Meldung erscheint rein basierend auf dem Alter der Applikation, nicht basierend darauf, ob eine neue Version verfügbar ist:

there’s background process that checks the build date against the current time, and will start to complain if it’s more than 12 weeks ago.

Quelle: Debian Bug report logs – #943668 Getting „Can’t update Chromium“ notifications

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 23. Januar 2020

grep interpretiert Dateiinhalte fälschlicherweise als Binärdaten

Ein Bash-Script, welches täglich meine SVN-Logs auf unerwartete Zugriffe durchgeht, meldete mir gestern:

...
1  Binary  file  (standard  input)  matches
...

Dabei handelt es sich um eine Meldung von grep, mit welchem ich die Apache-Logs filtere. Offenbar enthält das Access Log von dieser Woche Inhalte, die grep glauben machen, dass es sich um eine Binärdatei und nicht um eine ASCII/UTF-8-Datei handelt. In Durchgängen in früheren Monaten und Wochen trat dieses Problem nicht auf.

Wenn man sich sicher ist, dass man grep ASCII-Daten füttert, kann man dies mit einem Argument forcieren:

$ grep --text README.txt

So klappt die Auswertung nun auch wieder mit meinem Bash-Script.

Nachtrag

Gemäss diesem Unix & Linux Stack Exchange-Artikel erachtet grep eine Datei als Binär, wenn es erstmalig auf das NUL-Zeichen trifft.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. Januar 2020

Signal-Werte meiner Ubiquiti UF-SM-1G-S

Kürzlich hat ein Bekannter ein zweites Stockwerk mit Netzwerkverkabelung erschlossen. Hierzu haben wir nicht Ethernet Cat6 gewählt, sondern wegen der Grösse der Lehrrohre auf Glasfaser gesetzt.

Dies bedingt leider aber auch, dass an beiden Enden des Glasfasers SFP-Module verwendet werden müssen, die die Lichtwellen auf Ethernet konvertieren.

Ich habe mich auf der einen Seite für einen gebrauchten Ubiquiti Unifi Switch US-8-150W entschieden, auf der anderen Seite ein bei mir nach Fiber7-Tests unbenutzt herumliegender TP-Link MC220L, der im Modus Auto mit Ethernet auf einen Ubiquiti Unifi Switch US-8-60W gepatcht ist. Als SFP-Module verwende ich beidseitig Ubiquiti UF-SM-1G-S. Als Kabel hat der Bekannte ein Lightwin LWL-Patchkabel LC/APC-LC, Singlemode, Simplex, 15m gezogen.

Aktuell erreiche ich mit diesem Setup auf Seite des US-8-150W folgende Signal-Werte:

  • Output Pwr. -6.03 dBm
  • Input Pwr. -8.57 dBm

Das SFP-Modul ist 47 Grad Celsius warm, die Spannung beträgt 3.284 Volt und der Strom beträgt 31.890 mA. Diese Infos kann man allesamt in Echtzeit über die UniFi Controller-Software auslesen.

Leider habe ich keine Ahnung, ob diese Werte gut oder schlecht sind …

Tags: , , , , , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Sonntag, 12. Januar 2020

Kabelmodem direkt nach dem Verstärker anschliessen? Schlechte Idee.

Ein Bekannter plant derzeit, die Stockwerke seiner Immobilie mit Ethernet- oder Glasfaser-Kabeln zu erschliessen.

Da hatte ich eine zündende Idee: Da der Bekannte upc cablecom-Kunde ist, könnte man nach der Verkabelungsaktion das Kabelmodem von der Stube im 1. OG in den Keller zügeln, wo der Verstärker angebracht ist. Ich erhoffte mir davon höhere Bandbreiten beim Up- und Download, da ich der Qualität der Verkabelung vom Verstärker zur Stube nicht traue. Je näher das Modem am Verstärker ist, desto weniger leistungsschwächende Interferenzen erhoffte ich mir.

Nachdem das Modem zum Verstärker gezügelt worden wäre, hätte man nur noch ein Netzwerkkabel vom Kabelmodem zum Stockwerks-Switch ziehen müssen und die Bewohner wären in den Genuss schnellerer Bandbreiten gekommen.

Falsch gedacht. Eine kurze Google-Recherche lotste mich auf folgende Forumsdiskussion:

Einfach so an den Verstärker anschließen geht nicht. Das Modem ist von genau definierten Pegelwerten abhängig, d.h. Deine vom Techniker gesetzte Dose wurde eingemessen. Bei dieser Einmessung fanden das zur Dose führende Kabel und die Dose selbst Berücksichtigung.

[…] [Die Installation einer neuen Kabeldose] sollte jemand machen der Ahnung von Kabelanlagen, Dämpfungen und Rückkanal hat.

Quelle: Kabelmodem direkt mit dem UM-Gerät im Keller verbinden

Tags: , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen