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

Sonntag, 23. Februar 2020

In wie vielen Schweizer Haushalten lauscht Kantar Media den Internet-Verkehr mit?

Einem Bekannten habe ich damit geholfen, sein Heimnetzwerk zu aufzubauen und helfe ihm bis heute dabei, es zu betreiben.

Vor einigen Wochen meldete sich der Bekannte bei mir und erzählte mir davon, wie er gerade einen Besuch von einem Mitarbeiter der Kantar Media Switzerland GmbH erhalten hatte.

Medienkonsum messen

Mein Bekannter hat sich seit längerem dazu bereit erklärt, für eine kleine Entschädigung eine Box des Unternehmens bei ihm in der Stube zu installieren, welche die gerade konsumierten Radio- und TV-Sendungen erkennt und diese an das Unternehmen zurückmeldet.

Ich vermute dies erfolgt mittels Fingerprinting des Audiosignals von Radio- und TV-Sendungen zusammen mit einem exakten Timing-Signal, in etwa vergleichbar mit der iPhone-App Shazam, welche einem sagt, wie das Lied heisst, welches man gerade im Radio oder in der Disco hört.

Ich mag mich diesbezüglich an Vorlesungen in meinem Studium der Medienwissenschaften erinnern, in welchen Matthias Friedrich Steinmann jeweils erzählte, wie er selber eine solche Firma aufgebaut und zum internationalen Erfolg geführt hatte. Abnehmer der von ihn erhobenen Daten waren die Radio- und Fernsehsender sowie die Werbeindustrie. Anhand der Zuhörer- und Zuschauerzahlen und deren Demographie konnte man den Preis für Werbeminuten berechnen und den beworbenen Unternehmen vorrechnen, wie viele Leute mit einer Werbung potentiell erreicht werden konnten.

Das unsichtbare Streaming

Beim letzten Besuch brachte der Kantar-Mitarbeiter ein neues, zusätzliches Kästchen mit. Auf Grund der digitalen Revolution konsumieren immer mehr Leute Streaming-Angebote über das Internet. Das neue Kästchen wird deshalb an das Netzwerk gehängt und erkennt, wenn im Haushalt Streaming-Angebote konsumiert werden und meldet Informationen dazu an das Unternehmen zurück. Dies ergänzt das bisherige Kästchen, welches den „konventionellen“ Radio- und TV-Konsum überwacht.

MITM Black Box?

„Spannend!“, dachte der Information Security Professional in mir. Und irgendwie war mir da schon bewusst, dass da etwas nicht ganz koscher sein konnte: Da kann meiner bescheidenen Meinung nach nur Packet Capturing zum Einsatz kommen, welches den gesamten ausgehenden Internet-Verkehr mitschneidet, in Echtzeit analysiert und aus den Paketen die URLs herausfiltert, welche auf den Konsum von Streaming-Angebote hindeuten. Diese Informationen werden per Internet in Echtzeit an Server des Unternehmens übermittelt, dort gespeichert und zu verkaufbaren Auswertungen verwurstelt. Wie das aber mit verschlüsseltem Verkehr (HTTPS) funktionieren soll, ist mir bis heute unklar (SNI?).

Hier ein Photo des ominösen Kästchens mit der Aufschrift „Kantar Media UK Ltd“, „Made in England“, „Model 5010-001“ einer Seriennummer sowie „CAN ICES-3 (B)/NMB-3(B)“:

Als ich dieses Gerät sah, war ich verwirrt: Ich hätte erwartet, dass es einen Ethernet-Eingang sowie einen Ethernet-Ausgang aufweist und zwischen den Router und das restliche Netzwerk gepatcht wird. Wie auf dem Photo sichtbar verfügt das Kästchen aber nur über einen Ethernetport.

IP-Konflikt

Ein Blick in das Log von arpwatch zeigte mir dann das Übel: Das Kästchen war mit der internen, nicht-öffentlichen IP-Adresse des Routers konfiguriert worden. Das arpwatch-Log war dementsprechend voll mit flip flops, sozusagen ein Abbild des Kampfes des EdgeRouters mit dem Kästchen über die Vorherrschaft der nun doppelt vorhandenen IP, die von zwei unterschiedlichen MAC-Adressen beansprucht wurde.

Ein Kollege vermutet, dass wenn das Kästchen genug lange im Netzwerk aktiv gewesen wäre, schlussendlich alle Clients das Kästchen als Gateway angesprochen hätten. Das Kästchen wiederum hätte den Verkehr dann über den echten Router ins Internet gelotst.

Zwischenfazit

Für mich war der Fall klar: Die MAC-Adresse des Geräts wurde im UniFi-Controller kurzerhand geblockt, und der Block ist bis heute aktiv.

Ich befürchte, dass diese Black Box in Haushalten von hunderten Familien in der Schweiz installiert ist und schön brav den gesamten Internet-Traffic der „Kunden“ mitschneidet.

Vermutlich sind sich die wenigsten Leute über die Sicherheits- und Datenschutzimplikationen im Klaren, auf welche sie sich mit der Installation dieses Trojaners eingelassen haben.

Vielleicht habe ich einfach eine zu blühende Phantasie und alles ist extrem simpel aufgebaut — die Logik im Kästchen schaut nur die Ziel-IP-Adressen an, und vielleicht noch die übertragene Datenmenge. Fertig. Damit lassen sich aber nur Aussagen machen wie „Mario Aeby, männlich, 39, verheiratet, wohnhaft in Bern in einem Zweipersonenhaushalt, Haushaltseinkommen 50’000 Franken, konsumiert an Abenden und Wochenenden zwischen 30 und 60 Minuten Amazon Prime, Netflix oder Apple TV“. Ob das dem Unternehmen reicht?

Läuft mit der Datensammlung aber etwas schief (absichtlich oder unabsichtlich), werden DNS-Queries mitgeschnitten und Firmware-Updates auf das Gerät gepusht, welche dann ein deutlich gläsernes Bild von mir zeichnen könnten. Mit nicht viel Aufwand könnte das Kästchen sogar verhindern, dass ich bestimmte Adressen ansurfen kann. So etwa wie es China seit Jahren mit dem Internetkonsum seiner Bevölkerung macht.

Und ja, vermutlich könnte ein Techniker im Fernwartungsmodus problemlos das LAN auskundschaften gehen, in welchem sich das Kästchen befindet.

Nachtrag

Höchstwahrscheinlich handelt es sich bei diesem Gerät um den Kantar Focal Meter. Das Unternehmen berichtet diesbezüglich:

Kantar’s Focal Meter collects data by intercepting web traffic from all devices connected to the home router, preserving respondent privacy by only reporting data from a specified list of BVOD and other online video sites.

Quelle: BARB commissions Kantar Focal Meter for deployment across UK Television Audience Measurement Panel

Mit einer Google-Suche stösst man dann auch auf ein Web Learning-Angebot, welches vermutlich nur für Kantar-Mitarbeiter gedacht ist. Die Homepage ist aber für jedermann frei zugänglich und zeigt neben einem Photos des Geräts auch ein interessantes Schema, bei welchem es sich aber nicht um den Aufbau des Focal Meters handelt, sondern des Virtual Meters (einer Software, die auf den Computern der Teilnehmer installiert wird).

Tags: ,
Labels: Security

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 23. Februar 2020

Anstelle des Green Screens kommt in Hollywood jetzt der LED-Screen

Die Leute von ILM haben für die Star Wars-Serie The Mandalorian eine neuartige Technologie namens Stagecraft entwickelt, welche auf gigantischen LED-Screens beruht und die altbekannten Green Screens grösstenteils überflüssig macht.

Die exakte Position und Ausrichtung der Filmkameras wird im Raum bestimmt und das auf den LED-Screens anzuzeigende Bild mit der aus Computer-Spielen bekannten Unreal Engine im korrekten Blickwinkel entsprechend gerendert.

Im Grunde kehrt man also zurück zu den Matte-Paintings, welche nun aber als Lichtquelle dienen, animiert sein können und deren Blickwinkel man in Echtzeit anpassen kann.

Die folgende Reportage geht ausführlich auf die (aktuellen) Limitationen der Technologie ein: Rechenkraft, aber auch die vorgängige Auswahl und Besuch der Landschaften für hochauflösende Photos und Vermessungen.

Die Vorteile hingegen überwiegen: Schauspieler können sich besser in das „Bühnenbild“ hineinversetzen, man benötigt keinen Green Screen mehr und hat somit auch potentiell keine grünen Artefakte mehr, die man nachher rausretuschieren muss — und generell ein deutlich verkürztes Post Processing. Der grösste Vorteil aus meiner Sicht:

We can create a perfect environment where you have two minutes to sunset frozen in time for an entire 10-hour day,

The Mandalorian: This Is the Way – The American Society of Cinematographers

Tags: , , , , , ,
Labels: Unterhaltung

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 23. Februar 2020

Vin Jaune

Im Juni 2019 stolperte ich über einen Artikel in The Atlantic. Wissenschaftler haben herausgefunden, dass die Traubensorte Savagnin Blanc in Europa seit über 900 Jahren unverändert angepflanzt wird:

In a medieval cesspit in central France, archaeologists dug up a small, hard grape seed. They believed it to be 900 years old, based on the artifacts found nearby. When geneticists crushed up the grape seed, extracted its DNA, and compared it with modern grapes, they found a perfect genetic match in Savagnin Blanc—a grape still grown, still picked, and still made into wine in Europe today.

This grape, it turns out, has survived unchanged for almost a millennium. In a time that has spanned the Hundred Years’ War, the Enlightenment, the French Revolution, Napoleon, and two world wars, someone has always thought to take cuttings of Savagnin Blanc to keep planting into the ground anew.

Quelle: A Medieval Grape Is Still Used to Make Wine

Was mein Interesse weckte war der Hinweis auf einer Weinsorte, von der ich noch nie gehört hatte:

Savagnin Blanc is also known as Traminer Weiss, and it is still grown in a few European countries. But it is perhaps most famously used to make vin jaune or “yellow wine” from Jura in France. Vin jaune comes in a squat bottle called a clavelin and it has taken on a bit of a cult status. “It is probably the weirdest wine you’ll ever have,” Bonné says. “It is intensely yellow-colored. The best way I can describe it, it has almost no fruit characteristics. It’s nuts, almonds, and walnuts, and this very distinct, slightly acidic tang, too.”

Gestern kam mir dieser mysteriöse Wein wieder in den Sinn, und ich machte mich kurz vor Ladenschluss auf den Weg in den Globus Bern, um den teuersten Wein zu kaufen, den ich mir in meinem Leben geleistet habe:

Vin Jaune Arbois 2009 für 65 CHF; an Lager im Globus Bern-Marktgasse

(Vermutlich hätte es für die erste Degustation auch ein ähnliches Produkt aus dem Manor für die Hälfte des Preises getan. Doch diesen Wein müsste ich online bestellen und in die neue Filiale in Bern liefern lassen.)

Wieder zu Hause entdeckte Stephanie die Preisetikette, worauf ich mich genötigt sah, auf YouTube nach englischen Degustationsnotizen zu suchen. So war es mir möglich, ihr ohne grosse Worte zu erklären, was an diesem Wein so speziell sein soll:

(Schlechte Videoqualität, und das Intermezzo mit dem Mitarbeiter fand ich unpassend — aber immerhin ein englisches Video, welches einem den Geschmack des Weins näherbringt)

Nun warte ich auf die passende Gelegenheit, den (hoffentlich) edlen Tropfen zu geniessen.

Tags: , , , , , ,
Labels: Essen

Keine Kommentare | neuen Kommentar verfassen

Montag, 10. Februar 2020

Offenbar kein Android TV 9 Pie für meinen Sony KD-65AG8

Sony hat kürzlich ein Update für seine Android TVs veröffentlicht, welches Android TV 9 bereitstellt. Das interessanteste neue Feature: Apple AirPlay- und Apple Homekit-Unterstützung.

Leider unterstützt mein kürzlich gekaufter Sony Bravia KD-65AG8 (OLED) das Update nicht. Der Grund liegt offenbar weder bei Sony noch bei Google:

Yeah Google requires 3 major updates, but unfortunately the MediaTek CPU chip inside the older TVs is discontinued so there’s no Android 9 support for it. Therefore Sony can’t install Android 9 on that CPU. Because Sony needs MediaTek to update the CPU’s software (Linux kernel version). :-/

Quelle: Firmware update: Welcome to Android™ 9 Pie for Sony’s 2018-2019 TVs (AF9, ZF9, AG9, ZG9, XG85/XG87 and XG95 Series) – Starting on 11th December 2019

Gemäss ZKelectronics handelt es sich um den MediaTek MT5891. Der Sony KD-65AG9 hat hingegen den MediaTek MT5893 verbaut (Quelle).

Tags: , , , ,
Labels: Unterhaltungselektronik

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

2 Kommentare | neuen Kommentar verfassen

Sonntag, 19. Januar 2020

Einen Sony Bravia OLED KD-65AG8 auf Android TV 8 lüpfen

Gleich nach der Installation des neuen TVs öffnete ich die Einstellungen des Geräts und führte eine Suche nach Software-Aktualisierungen durch. Der TV, damals noch mit Android TV 7 ausgestattet, meldete mir, dass die Software auf dem neuesten Stand sei.

Ich wusste, dass das nicht stimmen konnte. Ich ging deshalb auf die Web-Site von Sony Schweiz und fand das gewünschte Update unter folgendem Link: Firmware-Update auf V6.6545 (via KD-65AG8 > Downloads

Die 1.8 GB grosse Datei herunterladen, auf einen USB-Stick kopieren, den USB-Stick an einem beliebigen USB-Anschluss des TVs einstecken — und schnurstracks installiert das Gerät das Update (der Benutzer wird nicht gefragt, ob er wirklich updaten möchte).

Der Unterschied zwischen den beiden Android TV-Versionen wird im folgenden Video gut gezeigt:

Beim KD-55AF8 waren im Juli 2019 noch andere Handstände nötig, um Android einzuspielen. Dies, weil Sony das Update damals noch nicht an die grosse Glocke gehängt hat. Ich habe mir notiert, dass ich mir damals die Datei sony_dtvota_2016_1606520100_eua_auth.zip suchen und herunterladen musste, welche damals auf irgendeinem Sony-Server in Japan herumlagen. Ich glaube, bin mir aber nicht sicher, dass ich mich von diesem Video habe anleiten lassen, um an die ZIP-Datei zu gelangen.

Tags: , , , , , , , , ,
Labels: Unterhaltungselektronik

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. Januar 2020

National Geographics „Expedition Amelia“: Einfach nur enttäuschend

Gestern nahmen wir uns die Zeit, die bereits vor einiger Zeit entdeckte National Geographic-Sendung „Expedition Amelia“ endlich anzuschauen.

Das Fernseh-Team begleitet Robert Ballard, den Entdecker der Wracks der Titanic und der Bismarck, auf der Suche nach der Lockheed Electra der Flugpionierin Amelia Earhart.

Während die bessere Hälfte rasch einmal einnickte, hielt ich bis zum Schluss durch. Und musste völlig enttäuscht feststellen, dass ich gerade 90 Minuten meines Lebens verschwendet hatte.

Erstens fanden die Forscher keinen einzigen Anhaltspunkt, dass sich Amelia und ihr Navigator auf dem Weg von Lae (Papua Neu Guinea) nach Howland verflogen hatten und tatsächlich wie vermutet auf Nikumaroro (der ehemaligen Gardner Island) notgelandet waren.

Das in sich wäre nicht schlecht; zu Beginn einer solchen mehrmonatigen Reportage weiss man nicht, was einen erwartet. Eine Sendung zu machen und zu veröffentlichen, die von einem Misserfolg erzählt, ist meiner Meinung nicht verwerflich.

Doch leider verfallen sowohl die B-Klasse-Protagonisten (Amateure?) in fürchterlichen Aktivismus, in „wishful thinking“, klammern sich an jeden Strohhalm und reden alles schöner als es ist. Stichworte:

  • Irgendwelche Knochenfunde aus einem Archiv auf einer Pazifik-Insel werden nach Florida gebracht, weil man sich davon die sterblichen Überreste von Earhart erhofft. Statt nach der Analyse nüchtern und klar zuzugeben, dass die Knochen nicht von ihr sind, eiert man vor der Kamera weiter rum und macht dem Zuschauer Hoffnung.
  • Ein paar Schäufelchen Erde von Nikumaroro werden als „DNA Samples“ verkauft.
  • Leichenhunde schlagen an, und die „Archäeologen“ buddeln sich durch die Insel auf der Suche nach den sterblichen Überreste einer Frau, die vermutlich vor 83 Jahren gestorben ist. Was kann da noch gross übriggeblieben sein?
  • In Notizen einer Radiofunk-Amateurin in New Jersey (!) werden so interpretiert, damit sie auf die Theorie einer Notlandung auf Nikumaroro passen. Was meiner Vermutung nach verschwiegen wird: So schlimm wie im heutigen Internet waren die Fake News von damals sicher nicht, aber vermutlich erlaubten sich eine ganze Ladung von Funkamateuren ein Spässchen mit den naiven Empfängern und gaben auf ihren Funksprüchen an, Amelia zu sein.
  • Die 57 Meldungen von Funksprüchen werden zeitlich korreliert und entsprechen angeblich „genau“ den Gezeiten, die auf Nikumaroro herrschen (die Funksprüche seien immer nur bei Ebbe abgesetzt worden). Ich verstehe nicht viel von Gezeiten, aber sollten diese nicht in einer ganze Pazifik-Region identisch sein? Auf eine bestimmte Insel zu schliessen ist unwissenschaftlich.
  • Funde eines Kosmetikbehälters, von verhärtetem Rouge und einem quadratischen Glas auf Nikumaraoro lassen nur einen Schluss zu: Das müssen Überbleibsel einer Frau, nämlich von Amelia Earhart, sein!

In einem Indizienprozess würden die Leute vollen Schiffbruch erleiden (fast so wie die SS Norwich City). Gepaart mit der Erzähltechnik der Fernsehleute, die jedes noch so kleine Ereignis aufbauschen, um die Zuschauer über die Werbepausen hinweg zu ködern, ergibt dies ein fürchterliches Resultat.

Von National Geographic hätte ich mir eigentlich eine deutlich wissenschaftlicher-fundierte Sendung erhofft. Stattdessen ist schales Infotainment rausgekommen, das nicht viel über dem Niveau von History Channel-Sendungen liegt. Derart grottenschlecht wie Hunting Hitler ist Expedition Amelia nicht. Aber die journalistischen Tendenzen sind identisch.

Tags: , , , , ,
Labels: Unterhaltung

Keine Kommentare | neuen Kommentar verfassen