Archiv 1. März 2020

Sonntag, 1. März 2020

Die „gesunden“ Corona-Kranken

In den nächsten Tagen wird man Drosten zufolge sehen, »dass neue Fälle und kleine Fallgruppen wie die Pilze aus dem Boden schießen werden«. Deutschland wird dabei vermutlich eine europäische Spitzenposition einnehmen, »weil unsere Bevölkerung sehr reisefreudig ist«. […]

Das beleuchtet die neue Qualität der sich in Europa ausbreitenden Epidemie: Die einzelnen Fälle sind nicht mehr auf einen bekannten Ursprungspatienten zurückzuverfolgen. Zwischen den bekannten Fällen liegen immer mehr unerkannte Infektionen mit vermutlich milder Symptomatik, die gar nicht in den Blick des Gesundheitssystem gekommen sind. Das sind die aus dem Boden hervorschießenden »Pilze« des Professors Drosten, die anscheinend wohl oder übel kommen werden.

Es wird eine ganz normale Pandemie

Will heissen: Es scheint Leute zu geben, die Corona in sich tragen, sich aber nicht (derart) krank fühlen, dass sie überhaupt an eine Corona-Infektion denken.

Beruhigend für all die, die bis jetzt nicht abschätzen können, ob die eigene Corona-Infektion nach einem kleinen Husten vorbei ist, oder uns eben doch für drei Wochen die Lunge aus dem Körper hustend und fiebrig flachlegt.

Beunruhigend für all die alten Leute über 60, welche statistisch einer deutlich höheren Corona-Sterblichkeit entgegensehen. Denn diese könnten von den gesund erscheinenden Corona-Kranken angesteckt werden und schlimmstenfalls an den von der Krankheit verursachten Komplikationen sterben.

A propos …

Bei Tichy drüben sehen sie schon den perfekten Sturm auf Deutschland zukommen:

Das Coronavirus und die wohl im Entstehen begriffene neue Migrationswelle über die Türkei und den Balkan treffen in Europa und insbesondere in Deutschland auf Gesellschaften, die mit existentiellen Bedrohungen und Krisen keine Erfahrungen mehr haben.

Quelle: Zwei Krisen auf einmal

Sind wir gespannt, wie sich diese zwei Ausnahmeereignisse auf die Abstimmung zur BGI vom 17. Mai 2020 auswirken werden.

Tags: , , , , , ,
Labels: Gesellschaft, Schweiz

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 1. März 2020

Was die Grünen [schon] alles verbieten woll(t)en

Angeregt von Manfred Messners Ich gestehe: Auch ich lese „Tichys Einblick“ und „Achse des Guten“ regelmässig habe ich auch damit begonnen, die Artikel der beiden Web-Sites täglich automatisiert in Instapaper zu bookmarken.

Und gelegentlich lese ich den einen oder anderen Artikel nun sogar. Ich mache das hier öffentlich, auf die Gefahr hin, dass mir ab heute Freundschaften gekündet, hier im Blog Hasskommentare hinterlassen oder sogar Morddrohungen gegen mich ausgesprochen werden.

Aber als Historiker bin ich in Quellenkritik ausgebildet und traue mir zu, Fake News, Ausländerhetze und was den Kollegen dort drüben sonst noch alles unterstellt wird, auszumachen. Ich sollte in der Lage sein, die interessanten, nützlichen Inhalte zu extrahieren, ohne gleich am äussersten rechten Rand der Gesellschaft aufzuwachen.

Und nützliche Artikel gibt es dort tatsächlich hie und da, zum Beispiel dieser:

Was die Grünen alles verbieten woll(t)en

Die Grünen setzen auf den Staat, und wenn vom Markt die Rede ist, dann meist in einem negativen Kontext. Und dass die Grünen eine Verbotspartei sind, ist keine Legende, wie Graw zeigt. Die Grünen forderten in den ersten beiden Jahren nach der Bundestagswahl 2017, also zur Halbzeit, in 26 Anträgen im Bundestag explizit Verbote, so etwa des Einsatzes gentechnisch veränderter Bäume. Nur die Linkspartei überbot sie mit noch mehr Verbotsanträgen (34), während die FDP im gleichen Zeitraum drei, die SPD zwei und die Union einen Verbotantrag einbrachten (S.96). Die Grünen wollten in ihrer Geschichte etliches verbieten, haben entsprechende Initiativen zumindest diskutiert oder fordern sie bis heute – vieles auf Bundes-, manches auf Landesebene. Es würde den Platz sprengen, all diese Ideen aufzuführen, von denen sicher nicht alle falsch sind – aber die Summe macht es. Verboten werden sollten:

  • Atomkraft,
  • Nachrüstung,
  • Volkszählung,
  • Privatfernsehen,
  • Kabelausbau,
  • Kasernierung von Wehrpflichtigen,
  • Flughafenprojekte,
  • Nachtflüge,
  • Kurzflüge,
  • Transrapid,
  • Autos in Innenstädten,
  • Verbrennungsmotoren (ab 2030),
  • Fracking,
  • Plastiktüten,
  • Plastikstrohhalme,
  • Kohle,
  • Schweröl,
  • Werbung für E-Zigaretten,
  • öffentlich zugängliche Zigarettenautomaten,
  • Limonadenverkäufe an Schulen,
  • Onlineshopping am Sonntag,
  • Zero-Rating beim Mobilfunk,
  • Heizpilze,
  • Paintball,
  • Ponyreiten auf Jahrmärkten,
  • Erste-Klasse-Abteilungen in der Bahn

usw.usf. (S. 95).

Quelle: Die Grünen: Partei der Verbote, des Moralismus und der Macht

Meine Prophezeiung: Je schneller die Grünen auch in der Schweiz klaren Wein einschenken und ihre ersten Verbote versuchen durchzudrücken, umso rascher wird die Partei wieder auf ihre ursprüngliche Wählerstärke schrumpfen. Denn sobald die Verbote auch von den städtischen Wählern verlangen, ihr Leben umzukrempeln, wird deren Unterstützung in den nächsten Wahlen rasch sinken. Den Lebensstil ändern? Ja, gerne, aber bitte einfach alle anderen.

Tags: , , ,
Labels: Politik

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