instruyete – Seite 3 – man lernt nie aus

Serverdienst mit DS-Lite und AVM Fritz!Box

Bei einem DS-Lite Internet Anschluss gibt es gleich 2 Herausforderungen für einen zu betreibenden Serverdienst.

Es gibt keine IPv4 Adresse mehr, die dem Anschluss (also primär dem Router) zugewiesen ist. Lediglich bei ausgehenden IPv4 Verbindungen wird mittels NAT auf Provider Ebene (Grand Carrier NAT) temporär eine IPv4 Adresse zugewiesen (Details siehe hier).
Wie üblich gibt es keine festen IP-Adressen. Im Bezug auf IPv6 bedeutet dies, dass der 64bit Prefix für den Anschluss sich ändert. In der Regel spätestens bei einem Reboot des Routers.

Beim zweiten Punkt offenbart sich ein generelles Problem. IPv6 hat ja den Vorteil des riesigen Adressraumes. Daher bekommt bei einem IPv6 Internetanschluss jedes im Netzwerk verbundenes Gerät eine öffentliche IPv6 Adresse (beginnend mit 2001:), die sog. Global Unicast Adressen. Voraussetzung dafür ist eine Router-Propagation (Details siehe Link oben) und somit wäre dieses Setup für einen Serverdienst eigentlich prädestiniert. Aber leider behalten sich in der Regel die Provider eine Änderung des 64-Prefixes (fiktives Beispiel 2001:0a0b:436d:0881) vor.

Elektronisch unterschreiben – digitale Signaturen

Das geregelte Ableben meines Fax-Gerätes ermuntert zu einer Recherche wie es denn um elektronische Unterschriften steht. Möglichst solche die juristisch auch eine Beweiskraft entfalten.

Das Verfahren für solche Signaturen lehnt sich stark an die Sicherung von Webseiten an – man generiert ein Schlüsselpaar – privat und öffentlich – und unterschreibt mit dem privaten Schlüssel. Der Gegenpart prüft die Signatur mit dem öffentlichen Schlüssel und wenn es kryptographisch passt, dann stammt die Unterschrift vom Inhaber des Schlüsselpaares.

Die Frage, die sich hier aufdrängt ist natürlich wie man davon ausgehen kann, das der Unterzeichnende tatsächlich derjenige ist für den er sich ausgibt. Diese Verbindung von Identität zu dem abstrahiertem Objekt eines öffentlichen Schlüssels ist das Zertifikat, welches den öffentlichen Schlüssel zu einem Subjekt (Identität) zuordnet. Elektronisch unterschreiben – digitale Signaturen weiterlesen

MedAngel ONE Bluetooth Temperatursensor

Hier mal eine kleine Vorstellung von einem Gerät, dass zuverlässig genau das tut, was es soll – nämlich den einen gemessenen Temperaturwert via Bluetooth an ein Android Phone zu übertragen. Der primäre Zweck ist die Temperaturüberwachung von Insulin (oder anderen Medikamenten)

Der Sensor ist in seiner Länge kleiner als eine AAA Batterie (Micro) und benötigt eine RS-2032 Knopfzelle.

Eine Kröte – zum Glück die einzige – muss man gleich zu Beginn schlucken. Ohne ein Account bei MedAngel bekommt man leider keine Werte. Wenn man das in Kauf nimmt, kann es losgehen.

Die Übertragung findet ungefähr alle 5 Minuten statt. Es scheint so zu sein, dass bei stärken Änderungen die Sendefrequenz erhöht wird, während sie bei Stabilität verringert wird. Die Verbindung ist äußerst zuverlässig.

Die Anzeige der Restkapazität der Batterie zeigt selbst bei RS-2032 Knopfzellenakkus eine sehr akkuraten Wert an. Restkapazität in % und Signalstärke in dB können im angezeigten Bild per Drücken angezeigt werden.
Mit der gleichen Technik funktioniert auch das Histogramm, welches den Verlauf der letzten 4-Wochen anzeigt. Durch drücken und aufziehen, zoomt man sich genauer in die Verläufe herein.

Es gibt 2 Modi, die allerdings nur auf die Alarme eine Konsequenz haben. Storing and Travel – geben an, ob das Insulin gelagert oder transportiert wird. Im letzteren Fall gelten lockere Temperaturgrenzwerte.

Apple vernachlässigt Bug-Reports

Dieser Artikel im heise newsticker spricht mir aus der Seele. An Apple einen Bugreport zu schicken, ist vergeudete Zeit. Selbst wichtige Probleme wie services oder gar sicherheitsrelevante Fehler werden lange ignoriert.

Da bleiben dann Feature Regressions wie das seit mehreren Releases kaputte CardDAV gleich ganz liegen. Der Bug Report 16938876 wird dann spätestens mit Abwicklung der Firma Apple geschlossen.

rsync zu microSDXC card

Beim Kopieren von Mediendateien vom NAS zu einer microSDXC Karte für den Einsatz auf dem Mobiltelefon, gab es wieder exakt das gleiche Problem, wie ich schon vor über 8 Jahren auf folgendem Blogpost geschrieben hatte:

rsync Problem UTF8 (World vs. Apple)

Was mir aber bis vor kurzem nicht klar war, ist die Tatsache, dass die Normalisierungsprobleme auch auf einem Dateisystem mit UTF-16 Dateinamenkodierung auftritt.

Die microSDXC Karte ist nämlich mit dem moderneren Windows Dateisystem exFAT formatiert, das wiederum UTF-16 für die Kodierung von Filenamen benutzt. Daher auch hier der dringende Rat:

Eine Synchronisierung der Dateien von einem macOS Betriebssystem ist nicht empfehlenswert, schon gar nicht in heterogenen Umgebungen.

Wenn man übrigens nicht sicher ist, welches Filesystem auf einer Karte verwendet wird, dann empfiehlt sich folgendes Kommando:

lsblk -no name,fstype

Apple Reparatur – zur Hölle

Wenn mal wieder das MacBook zur Apple Reparatur muss – Butterfly Tastatur lässt grüßen – dann gibt man es einfach im Apple Store ab und zwar gleich mit dem Passwort eines admin Users!

Warum?

Weil Apple gerne ein Hilfprogramm installieren möchte und dazu einen admin Account benötigt!

Warum nicht per Startmedium?

Keine Antwort! Apple braucht den admin-account!

Noch übler ist es, dass sein einigen Jahren das macOS Verschlüsselungssytem FileVault2 nicht mehr per User, sondern die ganze Partition verschlüsselt. Daher nützt es nichts, einen dummy admin-account anzulegen, mit der Intention, dass dieser nicht an die verschlüsselten Dateien der anderen (ebenfalls admin user) herankommt.

Der einzige Workaround ist, alle user-bezogenen Daten zu löschen und mittels TimeMachine von einem externen Medium (Server) später wieder herzustellen.

Again: Apple Sucks!

Google Earth Pro unter Linux mit falschen Ortsanflug

Die meisten deutschsprachigen Benutzer von Google Earth (Pro), welche das Programm unter Linux betreiben, dürften diesen Fehler kennen, da er auch schon seit vielen Jahren bekannt ist.

Man gibt im Suchfeld eine Adresse an und der Anflug an diese landet irgendwo anders. Da Google kein Interesse hat den Fehler zu beseitigen, muss mal wieder ein Workaround her. Dieser besteht darin, gewisse Regionaleinstellungen nicht auf DE einzustellen, sondern auf US. (frei nach H. Simpson: „USA USA USA„)

LC_NUMERIC=en_US.UTF-8

bringt die Abhilfe. Allerdings ist ein globales Setzen dieser Variable nicht empfehlenswert, da man sich sonst Probleme einhandelt wenn gleichzeitig die restlichen Regionaleinstellungen (LC_xxxx) auf DE verbleiben.

Diese Einstellung soll nur für dieses Programm gelten und am elegantesten (aus Anwendersicht) löst man dies in dem man die .desktop Datei manipuliert. Diese befindet sich beispielsweise auf meinem Ubuntu 16.04 System unter:

/usr/share/applications/google-earth-pro.desktop

und vollzieht dort folgende Änderung:

Exec=env LC_NUMERIC=en_US.UTF8 /opt/google/earth/pro/google-earth-pro %f

Nachteil dieser Lösung ist, dass bei jedem Paketupdate von Google Earth diese Änderung erneut durchgeführt werden muss. Dennoch meines Erachtens eine bessere Lösung als manipulierte Startskripte, die man eventuell beim Starten nach längerer Nichtbenutzung gar nicht mehr anwendet.

Das Ubuntu Wiki schreibt auch zu diesem Thema unter Orte werden falsch angeflogen.

Raspberry PI 3 Touch Screen Display sehr EMV sensitiv

Das offizielle – 7“ große – Touch Screen Display für den Raspberry PI 3 ist sehr sensitiv auf elektromagnetische Unverträglichkeit.

Dies äussert sich in unkontrollierten Aktionen auf dem Bildschirm, wie das Springen des Cursors, anklicken beliebiger Punkte und daher auch zufällige Ausführung von Programmen und Aktionen.

Beschrieben wird diese Effekt u.a. auch auf dem Raspberry PI Forum.

Das Problem ist reproduzierbar, wenn man in einer Schaltung welche die GPIO Ports benutzt eine PWM Ansteuerung – im Bild von RGB LEDs – vornimmt.

Vor allem das Flachbandkabel – auf dem Foto mittig zu sehen, welches das Panel vom Raspberry her aus steuert, scheint sehr sensitiv auf äußere elektromagnetische Einflüsse zu sein.

subjectAltName

Seit Chrome 58 funktionieren einige https Verbindungen nicht mehr, da der Browser das Zertifikat als ungültig erklärt.

Hintergrund ist RFC2818, der die Namenserkennung des zu sichernden Servers nicht mehr im CN (Common Name) Feld, sondern via DNS Eintrag in Feld SAN (Subject Alternative Name).

Nach einigen Versuchen, hat sich gezeigt, dass das Zertifikatsrequest noch nicht unbedingt die Requested Extension x509v3 Subject Alternative Name haben muss.

Spätestens aber beim Signieren muss es aber in das Zertifikat (public key) eingetragen werden. Dazu schaut man in der OpenSSL Steuerungsdatei

/etc/ssl/openssl.cnf

wohin die Variable

x509_extensions

zeigt. Dabei handelt es sich um eine Sektion die weiter unten mit [ ] eingeschlossen ist. Dort trägt man folgende Zeile ein.

subjectAltName=${ENV::SAN}

Dies erlaubt eine dynamische Zuweisung des DNS Eintrags als Umgebungsvariable, die man bspw. vor der Signierung auf der Kommandozeile setzt.

export SAN=DNS:www.testserver.org

Die Umgebungsvariable ist aber mit der o.g. Konfiguration auch notwendig, da sonst openssl ein extension Fehler wirft.

Abgeleitet wurde diese Konfiguration von dieser Webseite – danke dafür.

Tagging ID3v2 in mp4 (Musik)Videos

Bei mp3 Musiksammlungen ist es schon sein 2 Jahrzehnten üblich die Metainformationen über Künstler, Albumname etc. in dem sog. ID3v2 Format zu speichern. Tagging Editoren können diese Metainformationen jederzeit ändern.

Falls die Musiksammlung mit Musikvideos bereichert wird, kommt natürlich die Frage auf ob diese Dateien dann ebenso getaggt (mit Metainformationen versehen) werden können.
Prinzipiell hängt das erstmal mit dem Containerformat zusammen in der das Video eingebettet ist. Falls dies ein MPEG-4 Container ist, dann funktioniert das Prinzipiell. MPEG-4 Container (Part 14) erkennt bspw. an an den Dateisuffixen

Die Liste ist sicher nicht vollständig. Dateien mit diesen Containertyp können Video- aber auch Audiodaten enthalten. Vor allem Apple benutzt dieses Format schon seit längerem – aber auch andere Anbieter stellen z.B. Musikvideos in diesem Format zur Verfügung – also alles bestens?

Werkzeuge zum taggen

Ale erstes benötigt man erstmal ein Programm zum taggen. Ein sehr professioneller, proprietär und kostenpflichtig, Tagger ist Jaikoz – der kann aber dieses Format nicht mit ID3v2 tags versehen.
Was unter aber unter Linux normalerweise funktioniert ist ein Taggen mit easytag – das Standardwerkzeug zum Taggen des Gnome Desktops (funktioniert selbstverständlich auf allen Linux Desktops).
Normalerweise heißt in diesem Zusammenhang, dass der Audiostream innerhalb des MPEG-4 Containers mit MPEG AAC Audio kodiert ist – was bei Musikvideos nicht unüblich ist.

Aufnahme in eine Bibliothek

Hier sind wir beim noch größeren Problem angelangt. Zwei Bibliotheken

Rhythmbox (unter Linux)
Samsung Audio Player (auf Android)

ignorieren diese Dateien vollständig. Dagegen bindet

Clementine (unter Linux)

diese Dateien mit ein und spielt dann nur den in der Datei enthaltenen Audiostream ab (ignoriert den Videostream).
Hoffnung hätte ich gerne in KODI – das plattformunabhängige Multimediacenter – dort wird diese Datei aber in der Musiksammlung komplett ignoriert.
Die Videosammlung kann sie aufnehmen, aber die enthaltenen Tags nicht auswerten – was sich allerdings ab Version 18 laut diesem Wikieintrag ändern soll.

Das ist Situation im Mai 2018 – Dinge ändern sich beständig aber nicht so schnell wie landläufig erwartet oder geglaubt wird.