Skip to content

Update auf Debian 12

^ v M ><
Debian 12 ist vor kurzem veröffentlich worden, Zeit für Updates. Wie üblich ging das weitestgehend problemlos über die Bühne, nur ein paar Dinge brauchten etwas händisches Nachtreten:

Firmware Pakete


Die unfreien Firmware-Pakete wurden von non-free nach non-free-firmware ausgelagert. Entsprechend muss die /etc/apt/sources.list ergänzt werden, sonst werden die Firmware-Pakete nicht aktualisiert.

vim


Alle paar Releases wieder gibt es eine kaputte Version von vim, die man wieder zurechtkonfigurieren muss, damit z.B. einfügen per Mittelklick auch in meiner Umgebung (d.h. viel SSH und xterm) noch geht. Hier die aktuelle Config:
let g:skip_defaults_vim = 1
filetype plugin indent on
set tabstop=4
set shiftwidth=4
set paste
set noai
set vb
syntax enable

Die erste Zeile setzt erst mal alles auf Standardeinstellungen zurück, damit man anfangen kann zu arbeiten...

Zoneminder


Die Maschine wurde von Debian 10 und Zoneminder ab externem Repo erst zu Debian 11 mit Zoneminder ab backports aktualisiert und dann auf Debian 12 (ohne Extras) angehoben. Wichtig war nur nach jedem Update einmal zmupdate.pl -f auszuführen.

Nextcloud


Das Nextcloud-Update war etwas fummelig. Debian 11 kommt mit PHP 7.4, welches ab Nextcloud 26 nicht mehr unterstützt wird. Debian 12 kommt mit PHP 8.2, welches von Nextcloud 25 noch nicht unterstützt wird. Also war hier folgendes vorgehen angesagt:
- Nextcloud auf das letzte 25er Release aktualisieren
- Debian aktualisieren
- Auf Nextcloud 26 (wichtig, nicht latest, denn das ist bereits 27 oder noch neuer) von Hand aktualisieren
- Nextcloud über den eingebauten Updater auf die neuste Version bringen.

OpenHAB vs Xiaomi Sensoren

^ v M ><
Vor einiger Zeit habe ich angefangen, mit OpenHAB das Monitoring von meinen Servern auf die ganze Wohnung auszuweiten. U.a. wäre es schön zu wissen, ob ich den Tiefkühler im Keller wieder geschlossen oder doch die Tür aus lauter Senilität offen gelassen habe. Entsprechende Sensoren gibt es schon für relativ wenig Geld z.B. von Xiaomi (oder für massiv mehr Geld auch von anderen Herstellern, ob die dann einfacher einzubinden sind, ist die grosse Frage). Allerdings ist die Einbindung der Xiaomi-Sensoren in OpenHAB eine chinesische Oper in mehreren Akten:

Akt 1: Das Starterset

Das Starterset gibt's für rund 80.- und es kommt mit einem Druckschalter, zwei Türsensoren und zwei Bewegungsmeldern sowie der Basisstation. Gemäss Beschreibung ist alles ganz einfach: Die Basisstation starten, auf einem Android-Telefon die Mihome-App installieren, als Serverstandort "Mainland China" wählen, App mit der Basisstation verbinden, über ein verstecktes Menü den Developer-Mode aktivieren, den Key auslesen und damit die Basisstation in OpenHAB integrieren.
Dann wäre alles ganz einfach mit einem Datenfluss Sensor -> Xiaomi-Hub -> OpenHAB.
Ja, aber...
Genau, denn das ganze geht nur mit der Basisstation "Mainland China Edition", welche in Europa nicht erhältlich ist. Vermutlich kann man sie über einen chinesischen Grosshändler von Übersee liefern lassen (Reisestromadapter nicht vergessen, chinesische Stecker passen nicht in europäische Steckdosen). Aber die EU-Edition ist unbrauchbar:
- wählt man in der App Serverstandort "Mainland China", so lässt sich die Basisstation nicht finden und somit auch nicht verbinden
- wählt man Serverstandort "Europa", so fehlt das versteckte Menü, um den Developer-Mode zu aktivieren.

Akt 2: Veraltete App

Mit etwas Recherche ergab sich, dass auf dubiosen Seiten eine veraltete Version der Mihome-App zu finden ist, welche einen Fehler enthält: Sie schreibt ein Debug-Log. Worin der Zugriffskey zu finden ist. Leider hilft der alleine nicht weiter. Damit kann man zwar über die Xiaomi Mi IO Erweiterung von OpenHAB den Hub einbinden. Aber das war auch schon alles. Auf die Sensoren hat man deswegen noch keinen Zugriff. Dafür müsste weiterhin der Developer-Mode aktiviert werden, welcher auch einen Telnet-Zugang auf dem Gerät öffnet.

Nun gäbe es noch zwei weitere Optionen: Eine modifizierte Mihome-App von einer russischen Website, die komplett in kyrillisch gehalten ist. Nun äääh... Njet! Oder aber den Lötkolben auspacken, den seriellen Port abgreifen, sich damit Terminal-Zugang verschaffen und darüber den Telnet-Server aktivieren. Nun, da dies mit guter Wahrscheinlichkeit das Gerät schrotten kann, lasse ich das auch (vorerst) lieber. Immerhin könnte ich es noch weiterverkaufen, solange es noch funktioniert.

Akt 3: Der Aqara-Hub

Ein erneuter Blick in die Dokumentation des Mihome-Bindings zeigt: Der Hub in Version 3 (welcher als Aqara Hub für Apple Homekit im Handel ist), soll etwas zugänglicher sein. Der kostet leider alleine schon fast so viel wie das ganze Set. Und kann dann genau so wenig. Entsprechend habe ich den umgehend wieder zurückgesendet...

Akt 4: Billiger Zigbee-Stick

Die Xiaomi-Geräte halten sich, wie aller proprietärer Müll, natürlich nie ganz genau an die Standards. Aber immerhin genug, dass das Protokoll noch knapp als Zigbee durchgeht. Also habe ich für 9€+3.50€ Versand beim reichsten Mann der Welt einen USB-Zigbee-Stick gekauft. Zu meiner grossen Überraschung wurde dieser, obwohl Elektrogerät, vom reichsten Mann der Welt seinem Marktplatz aus Deutschland über den Rhein versendet. Sehr unüblich. Und kam auch superschnell an. Ebenfalls unüblich.
Es handelt sich um einen simplen USB-Stick mit CC2531-Chip und zigbee2mqtt-kompatibler Firmware vorinstalliert. Sehr genial!

Grundsätzlich würde OpenHAB zwar den Zigbee-Stick direkt über das Zigbee-Binding ansprechen können. Der Datenfluss wäre dann Sensor -> USB-Stick -> OpenHAB. Aber da war doch bei Xiaomi was mit Protokollstandard und sich daran halten. So lassen sich die Sensoren zwar einbinden, werden aber als "offline" angezeigt und es lässt sich kein Status abfragen. Es gilt also wie üblich: wieso einfach, wenn es auch kompliziert geht?

Nun beginnt die von-hinten-durch-die-Brust-ins-Auge-Installation für den Datenfluss Sensor -> USB-Stick -> zigbee2mqtt -> mqtt-broker -> OpenHAB.
Als erstes wird der Stick angeschlossen, dieser wird als USB-Serial-Gerät /dev/ttyACM0 erkannt.
Nun muss ein MQTT-Broker installiert werden, z.B. mosquitto aus den Debian-Paketquellen. Dieser wird ohne weitere Konfiguration gestartet.
Als nächstes wird zigbee2mqtt mit gefühlt zweitausend Node.JS-Abhängigkeiten installiert (u.a. npm aus den Debian Backports, wenn man Debian Stable als Basis nutzt). Dies ist, im Gegensatz zum später folgenden OpenHAB-Teil, hervorragend dokumentiert, so dass sich dieser Teil eher als Malen-nach-Zahlen denn Systemadministration anfühlt.
Nun können die Geräte im Prinzip schon eingebunden werden. Dazu einfach den Sensor mit der in der Packung beiliegenden SIM-Pin resetten, und gut. Gemäss Anleitung kann es sein, dass man den Vorgang mehrmals wiederholen muss, bei den ersten beiden Sensoren hat es aber jeweils auf anhieb geklappt. Ein Blick in journalctl -u zigbee2mqtt -f zeigt denn auch gleich Aktivität an.
Jetzt kommt der harte Teil: OpenHAB mit MQTT verbinden. Das ist sehr oberflächlich und abstrakt dokumentiert. Dazu kommt beim Googeln nach Lösungen das Chaos mit Anleitungen für MQTT1- und MQTT2-Binding hinzu. Welche nun bei meiner Installation gilt? Böh? Letztendlich habe ich die Anleitungen für MQTT2 befolgt, das hat irgendwann auch funktioniert. Vermutlich: MQTT1==OpenHAB1, MQTT2==OpenHAB2 (und bei mir läuft 2.5).

Wie also vorgehen:
In der zigbee2mqtt-Konfigurationsdatei /opt/zigbee2mqtt/data/configuration.yaml den Output nicht als JSON sondern Attribut ausgeben lassen. Dazu folgende Zeilen einfügen, speichern, zigbee2mqtt neu starten:
experimental:
    output: attribute
Und wenn wir schon in der Konfiguration herumfummelt, sollte man auch gleich den Sensoren vernünftige friendly_name vergeben.
Zuerst das MQTT-Binding in OpenHAB installieren.
Dann in /etc/openhab2/things/ eine .things-Datei mit den nötigen Einträgen erstellen. Irgendwann habe ich im Forum halbwegs taugliche Anleitungen gefunden...
Und sich nun wundern, dass die Things zwar im GUI auftauchen, aber keinerlei Daten gelesen werden... Signalstärke? NaN. Batterielevel? NaN. Zustand? Off. grrrmpf. Nach langem Debuggen (ja, zigbee2mqtt schreibt in mosquitto, mittels mosquitto_sub -v -t '#' kann man da schön mitlesen) irgendwann einfach mal den spontanen Windows-Reflex ausgelöst und OpenHAB selbst neugestartet. Uuund! Bingo! Alles tut. So einfach! Der Neustart ist übrigens für jedes neu hinzugefügte (oder umbenannte) Gerät nötig.

Das Finale: die OpenHAB-Things-Datei

Bridge mqtt:broker:MosquittoMqttBroker "Mosquitto MQTT Broker" [ host="127.0.0.1", secure=false] {
  Thing topic xdoor1 "Xiaomi Door Sensor" @ "Location" {
  Channels:
    Type switch : contact "contact" [ stateTopic = "zigbee2mqtt/xdoor1/contact", on="true", off="false" ]
    Type number : voltage "voltage" [ stateTopic = "zigbee2mqtt/xdoor1/voltage" ]
    Type number : battery "battery" [ stateTopic = "zigbee2mqtt/xdoor1/battery" ]
    Type number : linkquality "linkquality" [ stateTopic = "zigbee2mqtt/xdoor1/linkquality" ]
  }
}

Weitere Sensoren lassen sich nun einfach dem Bridge-Block hinzufügen. Mit etwas mehr Tippaufwand lassen sich auch Sensoren ausserhalb des Bridge-Blocks definieren:
Thing mqtt:topic:MosquittoMqttBroker:BodySensor "Xiaomi Body Sensor" (mqtt:broker:MosquittoMqttBroker) @ "Location" {
  Channels:
    Type switch : occupancy "occupancy" [ stateTopic = "zigbee2mqtt/xbody1/occupancy", on="true", off="false" ]
    Type number : voltage "voltage" [ stateTopic = "zigbee2mqtt/xbody1/voltage" ]
    Type number : battery "battery" [ stateTopic = "zigbee2mqtt/xbody1/battery" ]
    Type number : linkquality "linkquality" [ stateTopic = "zigbee2mqtt/xbody1/linkquality" ]
}
Die vorhandenen Channels lassen sich per mosquitto_sub oder journalctl herausfinden. Sobald man einen Sensor stimuliert, sendet er alle diese Angaben an den Zigbee-Controller.

Applaus

Natürlich is OpenHAB gerade in Kombination mit Zigbee (oder Z-Wave) bezüglich Möglichkeiten ein Fass ohne Boden. Schon ohne Funkanbindung lässt sich einiges an Technik anbinden: Drucker, Mail- und XMPP-Konten, WLAN (bzw dazu verbundene Endgeräte), Telefonanlagen, mpd (Music Player Daemon), Videokameras (z.B. via Zoneminder - aber das wäre ein Blogeintrag für sich). Mit Zigbee wird alles noch viel wilder. Nach den Sensoren kann das ganze restliche Haus eingebunden werden, von Lampen, Heizung und Rolladensteuerung über die Waschmaschine zum Rasenmäher bis zur Wallbox des Elektrofahrzeugs.
Wenn weitere Zigbee-Sensoren/Aktuatoren etwas weiter weg aufgestellt werden sollen, nimmt man einfach einen Raspberry Pi, schliesst daran einen weiteren USB-Stick an, installiert zigbee2mqtt und lässt damit die Sensordaten übers Netzwerk an den MQTT-Broker auf der OpenHAB-Maschine senden.

Die Covid Tracing App des Bundes...

^ v M ><
Was sagt der Hersteller: WIR RESCHPEKTIEREN DEN DATENSCHUTZ, IM FALL!

Schlimm genug: Die App verbindet sich mehrmals täglich zu Servern "des Bundes" (mehr dazu gleich), "um Konfigurationsdaten zu laden". Yeah right. Alleine das macht prinzipiell rückverfolgbar. Theoretisch wissen sie somit, wann ich zuhause, im Mobilnetz, im Büro, bei Freunden, an bestimmten SBB-Bahnhöfen, im Ausland oder zufällig mit Staatsfeinden ins gleiche WLAN eingeloggt bin.
Praktisch wird es nicht ganz einfach sein, da bei der Serververbindung nur eine begrenzte Menge Informationen über mein Telefon mitgegeben wird (App UserAgent Config Abruf).
Dies natürlich unter der Voraussetzung, dass die zu installierende Version aus dem Appstore dem entspricht, was da bei Microsoft-Github publiziert wird.

Ein weiterer Blick in den Sourcecode in Kombination mit ein paar DNS-Lookups macht alles noch viel schlimmer.

Verbindungen aufgebaut werden zu folgenden vier URLs:
https://codegen-service.bag.admin.ch/
https://www.pt.bfs.admin.ch/
https://www.pt.bfs.admin.ch/
https://www.pt1.bfs.admin.ch/
Und sind die wenigstens in der Schweiz, bei einem Schweizer Provider gehostet?

dig +short codegen-service.bag.admin.ch
162.23.137.58
$ dig +short www.pt-d.bfs.admin.ch
dhubv7mx4v0yy.cloudfront.net.
13.226.154.78
13.226.154.73
13.226.154.33
13.226.154.13
$ dig +short www.pt-d.bfs.admin.ch
dhubv7mx4v0yy.cloudfront.net.
13.226.154.13
13.226.154.73
13.226.154.78
13.226.154.33
$ dig +short www.pt1-d.bfs.admin.ch
pt1-d.bit.admin.ch.
162.23.137.59
$ dig +short www.pt1.bfs.admin.ch
pt1.bit.admin.ch.
162.23.137.65

Aber wem gehören diese Server denn?
$ whois 13.226.154.78
[..]
Organization: Amazon Technologies Inc. (AT-88-Z)

Natürlich! Immerhin: Dafür wurden sie ja schon kritisiert. Und das haben sie auch von Anfang an so angesagt. Leider haben es entweder der Bund oder die Medien ([1] [2]) da nicht ganz genau genommen mit der Wahrheit, wird doch behauptet, man nehme die Server von Amazon Deutschland.

Doch ein GeoIP-Lookup der hinter den CloudFlare verteilten Amazon-Server zeigt:
$ geoiplookup 13.226.154.78
GeoIP Country Edition: US, United States

Und wo gehen meine Datenpakete denn so überall durch, auf dem Weg zu Uncle Sam?
traceroute to 13.226.154.78 (13.226.154.78), 30 hops max, 60 byte packets
[..]
9 pd9ef372e.dip0.t-ipconnect.de (217.239.55.46) 30.289 ms 30.243 ms 29.741 ms
10 xe-5-2-0-0.ldn4nqp1.uk.ip.tdc.net (80.150.170.174) 32.190 ms 31.931 ms 32.210 ms
[..]

Schlaaaand und extraeuropäisches Territorium (UK)! Können wir da nicht noch die Russen und die Chinesen irgendwie auch involvieren?

Immerhin: Der IP-Range 162.23.0.0/16 gehört dem Bund und routet in die Schweiz.
Und: Alle Verbindungen werden zumindest verschlüsselt aufgebaut und die Zertifikate sind im Code gepinnt (uuuh, ich seh schon den Totalausfall kommen, wenn die Zertifikate erneuert werden müssen...).

Fazit: Es ist schlimm. Aber es könnte wirklich sehr viel schlimmer sein. V.a. in Anbetracht dessen, dass das arbeitende Steuergelder sind.

Konsequenz: Installiert, aber nur auf dem Zweittelefon, in dem keine SIM-Karte eingesetzt ist, das kaum ein WLAN ausser meinem daheim kennt und bei dem es mir egal ist, wenn der Akku nach 30 Minuten alle ist.

Firefox-Einstellungen für Sicherheit und Privatsphäre

^ v M ><
Neulich hat Debian (endlich...) ein Upgrade von Firefox ESR 52 auf Firefox ESR 60 durchgeführt. Das hat wie so viele Updates gute und schlechte Seiten. Positiv ist, dass ein aktueller und flotter Browser installiert wird. Negativ ist, dass nun fast alle meine Addons nicht mehr verfügbar sind.

Während das Update auf dem Laptop problemlos funktionierte, hat es mir auf dem Desktop das Browserprofil so zerschossen, dass sich Firefox partout nicht mehr dazu bewegen liess, eine Website aufzurufen (nicht mal von 127.0.0.1). Eine gute Gelegenheit, frisch anzufangen und die Einstellungen nochmals zu prüfen - und die Modifikationen hier zu notieren, damit ich sie beim nächsten Mal wieder finde und jemand dies für irgendjemanden von Nutzen ist.

Firefox modifiziere ich aus drei Gründen: Für bessere Benutzbarkeit, Performance und Sicherheit/Privatsphäre. Hierzu installiere ich ein paar (hoffentlich vertrauenswürdige) Plugins und passe einige Einstellungen in der about:config an.

Als Addons unverzichtbar sind NoScript und uBlock Origin (eigentlich wäre mir Request Policy lieber, aber das wurde ja von Firefox durch das Update getötet). Mir geht es weniger darum, lästige Werbung auszublenden. Ich habe nichts gegen Werbung, wenn sie direkt vom Website-Betreiber gehostet wird (kein Tracking) und nicht aufdringlich ist (ergo: statische Bilder). Aber Werbenetzwerke wurden auch schon von Bösewichten dazu missbraucht, Schadsoftware auf an sich vertrauenswürdigen Webseiten zu verbreiten (siehe z.B. hier... Link geht bewusst zum Verursacher). Es ist somit reine Selbstverteidigung.
Nach wie vor auf der Suche bin ich nach einem Addon zur Verwaltung von Cookies, da auch Cookie Controller nicht mehr funktioniert.

Die Benutzbarkeit optimiere ich durch folgende Einträge in der about:config:
accessibility.typeaheadfind.flashBar;0
browser.bookmarks.showMobileBookmarks;true
browser.feeds.handlers.application;/usr/bin/akregator
browser.tabs.closeWindowWithLastTab;false
browser.tabs.loadBookmarksInTabs;true
browser.urlbar.formatting.enabled;false
browser.urlbar.suggest.openpage;false
browser.urlbar.trimURLs;false
dom.disable_window_open_feature.toolbar;true
network.proxy.autoconfig_url;http://xxx/wpad.dat # nur auf Desktop
network.proxy.type;2 # nur auf Desktop
pdfjs.disabled;true

Für die Performance wird der Disk-Cache in eine RAM-Disk verschoben, das schont auch die SSD. Da mein /tmp eh schon in einer RAM-Disk liegt, bietet sich das an. Das ist zwar eine leichte Schwächung der Systemsicherheit, da /tmp per se allen Nutzern einsehbar ist. Da ich aber keinen shared Unix-Mainframe sondern eine Workstation nur für mich selbst habe, bleibt die Auswirkung in überschaubahrem Rahmen:
browser.cache.disk.parent_directory;/tmp
Als winziger Bonus wird auch die Privatsphäre minimal gesteigert, da der Disk-Cache somit nach einem Neustart des Computers definitiv gelöscht ist. Somit lassen sich Cache-Timing-Trackings reduzieren - eine eh schon eher esoterische Schnüffelmethode. Alternativ kann der Disk-Cache natürlich auch ganz deaktiviert werden.

Zu guter letzt wird noch die Privatsphäre gegenüber Mozilla und Google gesteigert. Dazu werden jede Menge unnötige Cloud-Dienste von Mozilla deaktiviert. Ebenfalls wird Google Safebrowsing ausgeschaltet. Dies weniger wegen Privatsphärebedenken, denn unter Berücksichtigung der Funktionsweise dieser Datenbank ist diese trotz Google-Herkunft tatsächlich relativ wenig bedenklich. Aber ich stelle den Nutzen in Frage. Ein aktuell gehaltenes Linux und ein Bisschen Vorsicht beim wild herumklicken bringt mehr Sicherheit als (potentiell veraltete und unvollständige) URL-Listen. Ausserdem spart dies Bandbreite und Festplattenplatz, da die Safebrowsing-Datenbank doch mehrere Gigabyte gross ist.
beacon.enabled;false
browser.pagethumbnails.capturing_disabled;true # neu zu erstellen
browser.safebrowsing.blockedURIs.enabled;false
browser.safebrowsing.downloads.enabled;false
browser.safebrowsing.downloads.remote.block_dangerous;false
browser.safebrowsing.downloads.remote.block_dangerous_host;false
browser.safebrowsing.downloads.remote.block_potentially_unwanted;false
browser.safebrowsing.downloads.remote.block_uncommon;false
browser.safebrowsing.downloads.remote.enabled;false
browser.safebrowsing.malware.enabled;false
browser.safebrowsing.phishing.enabled;false
browser.search.suggest.enabled;false
captivedetect.canonicalURL;http://xxx/success.txt # nur auf Laptop
datareporting.healthreport.service.enabled;false
extensions.blocklist.enabled;false
extensions.getAddons.cache.enabled;false
extensions.screenshots.disabled;true
extensions.screenshots.upload-disabled;true
geo.enabled;false
network.captive-portal-service.enabled;false # nur auf Desktop
startup.homepage_welcome_url;
toolkit.telemetry.unified;false
toolkit.telemetry.coverage.opt-out;true # neu zu erstellen
Eine gute Beschreibung vieler dieser Punkte sowie einige weitere Einstellmöglichkeiten finden sich in dieser grossartigen Anleitung.

Als weiteren Punkt in der Privatsphäre passe ich meine Cookie-Speicherdauer an und aktiviere den Do-Not-Track-Header:
network.cookie.lifetimePolicy;2
network.cookie.cookieBehavior;1
privacy.donottrackheader.enabled;true
Diese drei Anpassungen sind auch komfortabel per Maus über die Einstellungen erreichbar. Cookies werden akzeptiert, jedoch nicht von von dritten. Beim Schliessen des Browsers werden alle Cookies gelöscht. Dies ist ein guter Kompromiss zwischen Verfolgbarkeit einschränken und Webseiten benutzbar erhalten, ohne übermässig lange Ausnahmelisten führen zu müssen.

Zur Verbesserung der Sicherheit wird der Zugriff auf die Zwischenablage gestutzt:
dom.event.clipboardevents.enabled;false
dom.allow_cut_copy;false

Gibt es noch brauchbare Mobiltelefone?

^ v M ><
So, dieses Jahr hatte ich ja schon viel Spass mit Telefonen. Erst verreckt das Samsung S5 mal so ganz spontan in den Ferien. Als Ersatz gab es dann das günstigste vor Ort erhältliche Telefon (Neo Spark), welche sich als Zwischengerät ganz gut macht, aber langfristig nicht brauchbar ist (zu schlechtes Display, zu lahmer Prozessor). Dann spinnt plötzlich mein noch keine zwei Monate altes Moto Z...

Aber wenn ich jetzt schon frustriert losrante, dann richtig. Holen wir also zum Rundumschlag gegen die Elektroschrotthersteller aus. In Sachen mobiler Kommunikations- und Unterhaltungszentralen mit staatlicher Komplettüberwachungsschnittstelle hat man heute grundsätzlich die Wahl zwischen teuren und billigen Geräten. Und die sind in ihren Vor- und Nachteilen diametral gegensätzlich.

Billige Geräte haben neben dem tiefen Preis ihre Vorteile:
+ SD-Kartenslot
+ DualSIM
+ Klinkenbuchse für Kopfhörer
+ wechselbare Akkus
+ weitgehend unmodifiziertes Android
+ relativ robuste Bauweise
Aber irgendwie müssen die niedrigen Preise gerechtfertigt werden:
- mieses Display, wovon man blind wird. Dazu ist die Auflösung so gering, dass diverse Apps nicht installierbar sind.
- lahmer Prozessor und wenig RAM
- keine Android-Sicherheitsupdates (sell&forget)
- meist kein 4G oder andere brandaktuelle Funkübertragungsmodi

Teure Geräte weisen hingegen folgende Pluspunkte auf:
+ gutes Display mit hoher Auflösung, schöner Farbwiedergabe und Lesbarkeit bei Tageslicht draussen
+ zeitgemäss schneller Prozessor
+ mit etwas Glück während bis zu zwei Jahren alle paar Monate ein Android-Sicherheitsupdate, das ausgewählte Sicherheitslücken stopft
+ mit noch etwas mehr Glück gibt es alternative ROMs, die auch noch Jahre später im Wochentakt Updates veröffentlichen
Doch nicht alles was glänzt ist Gold:
- fest verbauter Akku mit viel zu kurzer Laufzeit
- SD-Kartenslot wird zum selten gewordenen Fundstück
- DualSIM? Vielleicht gegen ganz happigen Aufpreis. Und dann nur im Austausch gegen die SD-Karte
- grausam verunstaltete und unbedienbare Herstelleroberfläche (die dann als Ausrede dafür dient, Sicherheitsupdates viel zu spät oder gar nicht zu veröffentlichen)
- tonnenweise unnütze, nicht deinstallierbare Bloatware, welche den internen Speicher vollmüllt
- immer öfter eine fehlende Klinkenbuchse
- filigran-empfindliche Bauweise (Displays gehen bis über den Rand, Komponenten mangelhaft verbunden, Elektronik geht schon beim Anschauen kaputt)

Doch mal kurz der Reihe nach. Was war mit dem S5? Das Display hatte schon länger einen Wackelkontakt, nachdem das Telefon einen Sturz aus 80cm Höhe auf einen Turnhallenboden (die sind relativ weich...) erdulden musste. Es ist mir in sitzender Position aus der Hosentasche gefallen. Und ein paar Monate später so mitten in Dubrovnik beschloss der Wackelkontakt jetzt permanent keinen Kontakt zu geben. Da ich LineageOS installiert hatte, war natürlich auch die Garantie futsch. Die Reparatur würde gleich viel wie ein Neugerät kosten. Also ab in die Tonne damit.

Was war nun mit dem Moto Z? Nun, Ich war wieder einmal unterwegs und hatte grobfahrlässigerweise vergessen, ein Backup-Telefon mitzunehmen. Das Gerät wurde auf dem Flug von Zürich nach Dubai noch etwas zum Musikhören (Musik liegt auf der SD-Karte) genutzt. In Dubai habe ich den Anschlussflug gesucht und dafür mit dem Telefon auf der Flughafenwebseite das Gate ausfindig machen wollen. Plötzlich zeigt Firefox keinen Inhalt sondern nur noch eine schwarze Fläche an. Hmm, na gut, Flughafenseite futsch? Nein, tritt auch sonstwo auf. Also gut, Firefox neu gestartet. Problem bleibt. Na schön, Methode Windows angewendet und das Telefon neu gestartet. Ganz dumme Idee. Ab jetzt hängt das Gerät im Reboot Loop. Per Zufall in den Bootloader gelangt. Cache Reset. Nützt nix. hmmm. Schweren Herzens Factory Reset durchgeführt. Nützt nix. Also gut, SIM/SD-Tray raus. Geht wieder. FUCK YOU! Herumgespielt. Mit SD ohne SIM: Reboot Loop. Mit SIM ohne SD: startet.
Na schön, dann müssen wir halt den ganzen Drecksmüll wieder neu installieren, um das Gerät wieder benutzen zu können. Aber nein, das geht nicht. Das Flughafen-Wifi verlangt Authentifizierung. Der Setup-Manager kann aber keine Wifi-Login-Portalseiten anzeigen und weigert sich ohne funktionierende Internetverbindung das Gerät einzurichten. Überspringbar ist er auch nicht, es muss zwingend ein Google-Konto hinzugefügt werden. Danke Google. Danke Motorola. Alle Daten umsonst verloren und das Telefon taugt bis auf weiteres nur noch als Briefbeschwerer.
Immerhin: Das Herstellerandroid ist nicht komplett unbenutzbar, so dass ich es bislang ohne LineageOS ausgehalten habe. Daher ist noch Garantie drauf. Mal schauen, wie viele Monate es dauern wird, den Rotz repariert zu bekommen.

War denn nun die SD-Karte kaputt? Nein, ein Test unter Linux und einem anderen Android-Telefon zeigt, dass die Karte einwandfrei ist. Im Gegentest mit anderen SD-Karten bleibt der Bootloop reproduzierbar. Aber selbst wenn: Es darf nicht sein, dass wegen so einer Lappalie wie eine(r/m) defekten SD- oder SIM-Karte(nslot) das System anfängt merkwürdige Verhaltensweisen zu zeigen oder sogar nicht mehr starten kann. Das ist eindeutig ein Versagen der Entwickler von entweder Google oder Motorola oder beiden. Jedes lumpige Desktop-Betriebssystem bekommt es fertig, bei fehlerhaften externen Datenträgern noch irgendwie zu starten, oder zumindest eine halbwegs aussagekräftige Fehlermeldung auszugeben. Sogar Windows kann das seit 20 Jahren.

Da das Gerät gerade mal zwei Monate alt geworden ist, kann ich nur spekulieren, dass der für geplante Obsoleszenz zuständige Entwickler bei Motorola geschlampt und sich in der Einheit vertan hat. Statt zwei Jahre bekam der SD-Slot somit halt nur zwei Monate. Handkehrum stellt Google hunderte Entwickler an, die als Einstellungsvoraussetzung über einen Doktortitel verfügen müssen, zahlt denen 200'000 Franken Einstiegsgehalt und dann sind diese Leute offenbar allesamt zu dumm zum Scheissen. Das kann doch alles nicht wahr sein! Android 2017 ist schlimmer als Windows 95! In jedem Aspekt!

Leider gibt es aber auch keine Alternative zu Android. Die ganzen Hoffnungsträger sind bereits eingestampft (Maemo, FirefoxOS, Ubuntu Phone), kommen nicht in die Puschen (Jolla), liegen im Sterben (Windows, Blackberry) oder sind proprietär (Apple, Windows, Blackberry). Bei den iPhones kommt noch dazu, dass die von vorneherein ohne SD-Kartenslot daherkommen.

So langsam muss ich mir überlegen, nicht aus einem Raspberry Pi, einem UMTS-Stick und einem Batteriepack etwas selber zusammenzufummeln. Das macht dann wenigstens, was ich will und ist einfach reparierbar (wenn auch unhandlich, unpraktisch und unsexy). Oder ich muss mit Herrenhandtasche gefüllt mit dedizierten Geräten für jeden Zweck das Haus verlassen. Zumindest fällt dann in der Regel nur ein Drittel des Geräteparks (Musikplayer, Kamera, Telefon) auf's Mal aus.

Android und Linux verknüpfen: KDE Connect (ohne KDE)

^ v M ><
Per Zufall bin ich auf eine sehr coole Software gestossen: KDEConnect. Damit lässt sich ein Android-Telefon von einem Linux-PC aus fernsteuern. Oder der Linux-PC lässt sich von einem Android-Telefon aus fernsteuern. Oder man kann recht bequem Dateien zwischen Telefon und PC austauschen. Einzige Bedingung: Beide Geräte müssen sich im gleichen lokalen Netzwerk befinden (ob WLAN, kabelgebunden oder gemischt ist egal).

Wie es der Name schon sagt, ist KDEConnect eigentlich für die KDE-Desktopoberfläche entwickelt worden. Mit ein Bisschen tricksen läuft es aber auch relativ gut unter schlankeren Desktops wie z.B. dem von mir präferierten XFCE. Als erstes sollte es auf dem Telefon installiert werden, das geht bequem aus dem Play Store (oder wie f-droid auf Google-freien Systemen). Nun kann es gleich gestartet werden und auf einen paarungsbereiten PC warten.
Danach muss es mitsamt einiger Abhängigkeiten auf eben diesem PC installiert werden (hier wie immer für Debian Jessie erklärt):
aptitude install kdeconnect qdbus-qt5 kde-runtime

Nun müssen die KDE-Hintergrunddienste initialisiert werden:
$ qdbus org.kde.kded /kded loadModule kdeconnect
true
$ kbuildsycoca4 -noincremental

Und schon sollte es tun:
$ kdeconnect-cli --list-devices
- Samsung Galaxy S III: xxxxxxxxxxxxxxx (reachable)
1 devices found
$ kdeconnect-cli --pair --device xxxxxxxxxxxxxxx

Benachrichtigungen des Telefons poppen nun fröhlich auf dem Desktop auf.

Als Feinschliff kann noch das indicator-Applet installiert werden, damit Telefoninformationen im Systray dargestellt werden. Dieses ist leider noch nicht in Debian stable enthalten und muss händisch kompiliert werden. Immerhin war der Autor aber so freundlich, schon die ganzen Debian-Paketierdaten zur Verfügung zu stellen, so dass im Handumdrehen ein .deb-Paket erstellt werden kann, das eine saubere Installation (und Deinstallation) der Software erlaubt.
$ git clone https://github.com/vikoadi/indicator-kdeconnect.git
$ aptitude install build-essential valac libappindicator3-dev libgtk-3-dev debhelper #ggf weitere Pakete nötig
cd indicator-kdeconnect
$ dpkg-buildpackage -rfakeroot -uc -b
$ cd ..
$ su
# indicator-kdeconnect_0.1_amd64.deb
# exit
$ indicator-kdeconnect


Das ist echt ein Tool, das ich schon lange gebraucht habe (ohne es zu wissen) :-)

pfSense vs IPv6

^ v M ><
Seit ich beim einzig brauchbaren Provider der Schweiz bin (das ist der, der es gelegentlich auch in die deutschen News schafft, da er als vermutlich einziger Provider der Welt offen und explizit für Netzneutralität eintritt), habe ich endlich auch Internetzugang mit dem Protokoll der Zukunft, IPv6. Der Provider ist sogar so freundlich, dass ich auf Anfrage kostenlos ein statisches IPv6-Prefix erhalten kann, d.h. meine Computer immer unter der gleichen Adresse erreichbar sind.

Leider hat das auf der technischen Seite einen kleinen Schönheitsfehler, denn das statische Prefix wird anhand der DUID zugewiesen. Diese muss auf Seiten des Providers eingetragen werden. Die DUID ist eine pseudozufällig generierte, einzigartige ID meines IPv6-Clienten, also meiner Firewall. Diese Firewall benutzt als Softwarebasis das freie Firewallprojekt pfSense. Diese hat in der neusten Version allerdings ein sehr nerviges "Feature": Bei jedem Neustart wird die DUID neu generiert. Dies führt dazu, dass ich nach Softwareupdates, Stromausfällen o.ä. jeweils immer dem Support des Providers schreiben muss, er solle bitte die neue DUID eintragen. Somit ist mein IPv6-Zugang für eine Weile gestört, bis der Provider meiner Bitte nachgekommen ist.

Das zu unterbinden, erfordert leider etwas Gebastel...:
Zuerst muss man sich per SSH auf der Firewall einloggen und eine Shell aufrufen (Taste 8 drücken). Dann muss die Datei, welche die DUID enthält, an einen Ort kopiert werden, wo sie einen Neustart der Firewall übersteht:
cd /conf
mkdir dhcp
cp /var/db/dhcp6c_duid .

Danach wird über das Webfrontend ein Job eingerichtet, der diese Datei bei jedem Neustart bevor das Netzwerk gestartet wird wieder nach /var/db kopiert. Dazu muss als erstes über die Paketverwaltung (System -> Package Manager -> Available Packages) das Paket "Shellcmd" installiert werden.
Danach kann unter Services -> Shellcmd ein neuer Befehl definiert werden:
Command: cp -f /conf/dhcp/dhcp6c_duid /var/db/
Shellcmd Type: earlyshellcmd
Comment: Fix braindead IPv6 DUID regeneration

Fazit: die proprietären Sonicwall und Fortinet mögen unbrauchbar sein, aber auch die freie pfSense ist nicht frei von Macken. Eine perfekte Firewall-Lösung existiert auf diesem Planeten schlicht nicht.

Im Original findet sich die Lösung hier.

Sonicwall Rant

^ v M ><
Meine Verachtung für proprietäre Netzwerk"sicherheits"produkte ist über die letzten Tage wieder deutlich gestiegen. Objekt meines diesmaligen Hasses ist der Müll von Sonicwall, der sich somit von mir aus gleich auf neben Fortinet auf der Elektroschrotthalde einfinden darf.

Und zwar ging es darum, zwei bisher als Single Point of Failure betriebene Dienste mittels bestehender Loadbalancer-Infrastruktur auf Basis von Keepalived zu ausfallsicheren Clustern zu verbinden. Soweit so einfach, die redundanten Server installiert (bzw den Hot Standby auf Funktionstüchtigkeit überprüft), dem Loadbalancer zwei neue Virtual IPs hinzugefügt und die jeweiligen Maschinen zu Clustern verbunden.

Ein kurzer interner Funktionstest zeigt: Tut perfekt.

Als nächstes werden die geclusterten Dienste öffentlich freigegeben, dafür muss erstmal ein weiteres Loch in die Firewall gestanzt werden. Keine Sache für den ersten Cluster (erste virtuelle IP) und eigentlich auch nicht für den zweiten Cluster (zweite virtuelle IP). Als nächstes erfolgte natürlich der Funktionstest von extern, was beim ersten Cluster schlagartig mit Erfolg beschieden war.

Nicht so aber beim zweiten Cluster. Da war einfach keine Verbindung zu erstellen. Nun, woran könnte das liegen? Die Firewall-Regeln sahen alle gut aus, hmmm, kann das am Cluster liegen? Das ist ja doch eine komplexe Konfiguration mit Anpassungen auf Seiten des Loadbalancers und den geclusterten Maschinen. Also nochmals rigoros alles überprüft. Schaut gut aus. Und intern funktioniert's ja. Also doch die Firewall? Nochmals die Regeln überprüft... Mir sagen lassen, dass ich halt die Firewallregel irgendwie(tm) falsch erstellt hätte und sie nochmals prüfen solle. Gut. Nochmals unnötig Zeit auf die Überprüfung der Firewallregeln verschwendet. Die sehen einfach(tm) identisch zum anderen neuen Dienst aus. Die Regeln und das Netzwerk-Objekt gelöscht. Die Regeln und das Netzwerk-Objekt neu erstellt. Mir erneut sagen lassen, dass wohl die Regeln irgendwie(tm) falsch erstellt seien, da Sonicwall sowas ja noch nie gemacht hätte. Weiter am Loadbalancer debuggt und mit tcpdump und telnet herumgespielt. Erwartetes Ergebnis: Der Verbindungsaufbau von extern erreicht nicht einmal den Loadbalancer. Also zurück zur Firewall...

Und dann habe ich folgenden Versuch unternommen: Die Cluster-IP wurde von xxx.xxx.xxx.xxx zu xxx.xxx.xxx.xxy geändert. Danach wurde in der Firewall das Netzwerk-Objekt ebenfalls auf diese IP angepasst (also die eigentliche Regel habe ich nicht angefasst). Und zuletzt nochmals einen Test von aussen gefahren: BOOM! Katsching! Zugriff!

Als nächstes habe ich folglich *sämtliche* Firewallregeln darauf überprüft, ob sie Einfluss auf die zuerst genutzte IP haben könnten. Ich bin nicht fündig geworden.

Mit anderen Worten: Die bescheuerte Sonicwall diskriminiert ohne wirklichen Anlass eine gewisse IP-Adresse. Aber hey, was ist von einem Produkt zu erwarten, dessen Name mit NSA beginnt? Vermutlich sah die IP-Adresse einfach zu arabisch aus. Die ist ja schliesslich komplett in arabischen Ziffern notiert....

Jedenfalls verdient Sonicwall für solche Bugs in ihren überteuerten Produkten von mir einen Mittelfinger und ein "Fuck You", das Linus Torvalds Mittelfinger gegen nVidia wie einen Kindergeburtstag aussehen lässt. Es kann nicht angehen, dass meine teure Lebens- und Arbeitszeit verschwendet wird und versucht wird mein Selbstvertrauen kaputtzumachen.

Fairphone 2

^ v M ><
Schon vor meiner Rückkehr habe ich mir das Fairphone 2 bestellt und liefern lassen, damit ich endlich mein vier Jahre altes S3 ablösen kann, das trotz CyanogenMod und vielen Tricksereien beständig langsamer wird. Während es sich beim Fairphone zwar um eine gute Idee handelt, ist die Software so schlecht, dass ich es wohl bald ersetzen muss, wenn nicht schnellstmöglich Unterstützung durch beispielsweise CyanogenMod kommt.

Das Fairphone 2 besticht vor allem durch "faire" Produktion. Das heisst zum einen dass den Arbeitern in den Fertigungswerken Löhne bezahlt werden, die das Überleben ermöglichen. Zum anderen werden möglichst nur konfliktfrei abgebaute Rohstoffe eingesetzt, d.h. nicht solche, die brutale Diktatoren oder blutrünstige Rebellentruppen finanzieren. Und auch der Kunde soll nicht zu kurz kommen, das Gerät ist modular aufgebaut, leicht zu reparieren und soll über mehrere Jahre mit Ersatzteilen und Softwareupdates versorgt werden.

Die Hardware ist ziemlich einwandfrei. Zwar bezahlt man den Preis der guten Reparierbarkeit durch ein relativ dickes, schweres Gerät. Doch dafür ist es griffig und liegt ausgesprochen gut in der Hand. Bei Verwendung fühlt es sich schnell an, das Display ist scharf, flimmert aber leicht. Neben zwei vollwertigen MicroSIM-Slots gibt es einen zusätzlichen Slot für eine MicroSD-Karte, man muss sich also nicht wie bei den meisten DualSIM-Geräten zwischen zweiter SIM und mehr Datenspeicher entscheiden. Der Akku ist natürlich wechselbar, somit kann man das Gerät bei einem kompletten Freeze auf die harte Tour Neustarten statt mehrere Stunden zu warten, bis der Akku leer ist. Auch softwareseitig ist der erste Eindruck gut. Halbwegs aktuelles Android und kaum vorinstallierter unnützer Bloat. Doch damit hat es sich leider schon...

Die rückseitige Abdeckung lässt sich nur mit viel Gefummel entfernen und wieder aufsetzen. Fraglich, wie lange die hält, bevor sie ersetzt werden muss. Ausserdem sammelt sich sehr viel Staub in der Kante zwischen Abdeckung und Display.

Für die Kamera gibt es einen Hardware-Knopf auf der Seite. Durch Druck wird die Kamera-App gestartet... Leider nicht immer auf den ersten Druck :-( Ist die Kamera-App gestartet, funktioniert der Knopf als Auslöser. Das ist cool, somit kann man das Gerät als sehr schnell einsatzbereite Kamera verwenden. Sind weitere Fotogelegenheiten absehbar, kann der Bildschirm einfach über den Power-Knopf aus- und wieder eingeschaltet werden, die Kamera ist sofort wieder verfügbar. Leider mangelt es der Kamera-App an Funktionalität, ein Panorama-Modus wäre schon noch was... Ausserdem ist die Bildqualität eher mässig. Das alte S3 macht die deutlich besseren Fotos.

GPS funktioniert leider nur im High-Precision-Mode richtig. Dieser braucht aber mehr Strom und überträgt Standortdaten an Google. Im Device-Only-Mode dauert es mehrere Stunden, bis endlich die Position bestimmt werden kann. Das ist unbrauchbar.

SD-Karten werden nur erkannt, wenn sie mit dem uralten und nur mässig stabilen FAT32 formatiert wurden. Weder das Monopolisten-Dateisystem ExFAT noch freie Systeme wie ext4 sind unterstützt.

Bluetooth Pairing ist fast unmöglich, da paarungsbereite Geräte in aller Regel nicht gefunden werden.

Irgendwie hatte ich im Hinterkopf, dass eines der Ziele von Fairphone (erste Version) auch war, dass der Benutzer damit machen können soll, was er will. Das heisst auch, dass er relativ leicht und auf offiziell abgesegnetem Weg den root-Modus aktivieren kann. Nun, beim Fairphone 2 ist davon nicht viel vorhanden. Man muss modifizierte Images aus dubiosen Quellen flashen und auch sonst ein gewaltiges Gebastel vornehmen (siehe hier). Das ist ein schlechter Witz.

Schlimm wird es bei den Einstellmöglichkeiten von Android. Wenn man CyanogenMod mit seinen erschlagenden Möglichkeiten der Grob- und Feinkonfiguration kennt, fühlt man sich beim Fairphone wie ein Apple- oder Gnome-Jünger mit bescheuerten Voreinstellungen, die nicht änderbar sind. Zumindest den Wifi-Tethering-Button hätte ich schon gerne in den Quick-Toggles...

Aber so richtig schmerzhaft ist das Fehlen des Privacy Guard - wohl das Killerfeature von CyanogenMod. Damit lassen sich die Berechtigungen von Apps einschränken, ohne dass die Funktionalität der App ernsthaft beeinträchtigt wird. Somit kann man notorischen Privatsphäre-Killern beispielsweise den Zugriff auf das Adressbuch verweigern. Update: Stattdessen liefert Fairphone eine "Privacy Impact" Anzeige mit. Beim ersten Start einer App wird angezeigt, welchen Einfluss die App auf die Privatsphäre haben kann. Das ist total nervig und überflüssig, denn diese Information erhalte ich schon im Play-Store, wenn ich eine App installiere. Ausserdem kann ich mir nur anzeigen lassen, dass meine Privatsphäre verletzt wird, aktiv dagegen vorgehen wie beim Privacy Guard ist nicht möglich. Das Feature ist im Prinzip zwar deaktivierbar, doch wenn man das tut, funktionieren die meisten Apps nicht mehr richtig. Völlig gaga!

Doch all diese Problemchen sind ja nicht so tragisch, da man immerhin ein Gerät bekommt, das im Prinzip macht, wofür man es eigentlich erworben hat, oder? Nein! Tut es nicht! Denn es stürzt sehr häufig ab und bootet spontan neu. Oder das Netzwerk hängt sich auf, Internetzugriff wird nur durch einen manuellen Neustart wieder ermöglicht.

Und dann kommt der Todesstoss: Viele Apps funktionieren einfach nicht richtig! Eingabeformulare werden nicht ausgewertet oder falsch angezeigt. In CSipSimple können keine neuen Konten hinzugefügt werden, da der "Add Account" Button nicht auf Eingabe reagiert. In der Mobility App kann kein Standort ausgewählt und somit auch keine Reservation getätigt werden... Ich kann mir nicht vorstellen, dass dies generell an Android liegt - vermutlich ist die von Fairphone verwendete Grafikbibliothek einfach ein Bruch. Update: Die Probleme konnte ich beheben, indem ich das obsolete "Privacy Impact" wieder aktiviert habe, siehe hier.

Was also soll ich noch weiter mit diesem Schrottdings? Die produktive Nutzung ist mir kaum möglich, wenn das Gerät so unzuverlässig ist. Dem vielen Geld und den hohen Erwartungen wird das Gerät auf Anwenderseite so einfach nicht gerecht.

Let's Encrypt

^ v M ><
Heute habe ich auf dem Server neue SSL-Zertifikate von Let's Encrypt installiert. Bislang habe ich selbstsignierte Zertifikate genutzt, um sichere Übertragung zu ermöglichen ohne dafür unverschämte Mengen Geld an dubiose Certificate Authorities zum Fenster hinauswerfen zu müssen. Let's Encrypt bietet kostenlose Zertifikate an und wird von den wichtigsten Browserherstellern unterstützt. Somit sollte nichts mehr dagegen sprechen, mein Blog über https aufzurufen.

Vorteil: Die NSA kann nicht mehr wissen, was genau gelesen wird :-)

Hotel WLAN

^ v M ><
WLANs in Hotels sind meist einfach nur ein Ärgernis da oft nicht zu gebrauchen. Folgende Kategorien von Hotel-WLANs habe ich unterwegs angetroffen:
  • ohne WLAN: sehr selten, aber das gibt es nach wie vor.
  • Besonders schön fand ich die Episode der Unterkunft, die zwar WLAN hatte, aber "nicht für die Gäste". Auf meine Rückfrage, warum sie dann ein zweites WLAN mit Namen "Guest1" betreiben, kam die Antwort, dass sie das Passwort dafür nicht wüssten...
  • kostenpflichtiges WLAN: sehr populär, insbesondere sind die Preise dann meist so hoch, dass ein halber Tag surfen mehr kostet als eine SIM-Karte mit Datenpaket für einen Monat.
  • WLAN nur in bestimmten Bereichen: geizige Hotelliers haben irgendwo im Keller einen einzelnen WLAN-Accesspoint, der mit etwas Glück den Bereich rund um die Reception abdeckt. (vermutlich heisst es "Reception", weil man nur dort WLAN Empfang hat...)
  • WLAN, das gar nicht funktioniert: Das kommt dann in allen möglichen Farben daher: Mal kann man gar nicht verbinden. Dann kann man zwar verbinden, bekommt aber keine IP-Adresse. Oder es klappt soweit alles mit der Verbindung, nur ist das WLAN scheinbar nicht ans Internet angeschlossen.
  • WLAN, das nur zeitweise funktioniert: Das ist einer der grossen Favoriten. Das WLAN funktioniert nur ein paar Minuten lang, danach fällt es wieder für einige Stunden aus.
  • WLAN, das unbrauchbar langsam ist: Dies ist wohl die Standardkonfiguration. Das WLAN ist so unerträglich langsam, dass kaum etwas funktioniert. Meist dürfte das an zu geringer Bandbreite und billigster Hardware liegen, die einfach nicht genügend Leistung hat, um die vielen gleichzeitigen Verbindungen von dutzenden Smartphones (die ja jede Menge Hintergrundrauschen produzieren) vernünftig handhaben zu können. Auf den Philippinen liegt das jeweils daran, dass das Hotel-WLAN mangels Verfügbarkeit von kabelbasierten Internetanschlüssen ein MiFi-Accesspoint ist, der Zugang zum eh schon komplett überlasteten Mobilfunknetz des Landes bietet.
  • WLAN, das tatsächlich funktioniert. Kostenlos. Ja, das gibt es. In sehr, sehr seltenen Fällen.
Und natürlich können Hotels auch WLANs haben, die in mehreren Gruppen zugleich sind (z.B. nur in gewissen Bereichen und gar nicht funktionierend...).

Aus diesem Grund lege ich mir in jedem Land als erstes immer eine SIM-Karte zu. Wenn man weiss, was man braucht, kostet das nämlich nicht viel und schont die Nerven. Als Kaufhilfe bietet sich dieses phänomenale Wiki an!

Weltreise FAQ: IT-Ausrüstung

^ v M ><
Klar, die wichtigste Frage für reisende Nerds und Geeks ist natürlich immer: was für technische Spielereien kommen ins Gepäck? So wurde ich doch tatsächlich schon zweimal gefragt, ob ich auch einen Raspberry Pi mit dabei habe. Die Antwort ist natürlich nein, da ein Raspberry mit allem nötigen Zubehör für minimale Nützlichkeit dann auch wieder ein ordentliches Gewicht und mächtig viel Volumen benötigen wird. Ganz davon abgesehen, was sollte der Raspberry können, was mein Laptop nicht auch kann? Und wann würde ich neben reisen und bloggen noch Zeit dafür finden?



Kernstück ist ganz klar das Smartphone (in meinem Fall ein drei Jahre altes Samsung Galaxy S3 mit CyanogenMod Firmware). Es passt in die Hosentasche und ist somit immer und überall dabei. Dank Verbindung zum Internet entweder per WLAN oder lokaler SIM-Karte ist es unerlässliches Hilfsmittel für Recherchen jeglicher Art. Es kann als Kamera dienen, als Medienplayer oder Notizblock und ganz wichtig als Navigationshilfe dank Google Maps und OpenStreetMap. Ah ja, zur Not kann man damit glaub auch telefonieren...
Da das Gerät noch über einen wechselbaren Akku verfügt, habe ich auch einen zweiten Akku mit im Gepäck. Zur Funktionserweiterung ist das USB-OTG-Kabel mit dabei, womit z.B. ein USB-Stick für unkomplizierten Datenaustausch angehängt werden kann. Ein Kopfhörer und ein Headset darf natürlich auch nicht fehlen.

Ein Notebook brauche man nicht, Internetcafes bzw für Gäste nutzbare Computer gäbe es überall. Ja stimmt. Aber (in extra Grossschrift): Falls ich auf mein eBanking zugreifen muss, will ich das ganz bestimmt nicht über einen PC mit veraltetem Windows XP machen, dessen einzige je installierte Updates die neuesten Viren sind... Von der hygienischen Qualität der Tastaturen will ich mal gar nicht reden. Ausserdem will ich für's bloggen oder sonstige Planungstätigkeiten mich nicht in ein stickiges Zimmerchen setzen, das ich unter Umständen erst suchen muss, sondern das auch von meinem Hotelzimmer (oder Balkon des Bungalows) in aller Ruhe mit meiner bevorzugten Software machen können. Des weiteren bietet ein Notebook die Möglichkeit, bequem mit Datenträgern zu jonglieren und die Fotos der diversen mitgeschleppten Kameras sowie von Freunden einfach zusammenzutragen und bearbeiten. Die mit der Actionkamera aufgenommenen Filme lassen sich leicht bearbeiten und schneiden. Und zu guter Letzt kann ich über subsurface den Tauchcomputer auslesen.
Als konkretes Gerät habe ich mich für ein Lenovo X1 Carbon mit so ziemlich allen Extras (aber ohne Touchscreen) entschieden. Das Gerät ist sehr klein (nur 1.5cm dünn) und leicht (nur 1.2kg), somit trägt es kaum auf. Trotzdem bietet es bei Bedarf brachiale Rechenleistung. Lediglich das Fehlen eines SD-Kartenlesers ist etwas schade, so dass hier ein zusätzlicher Ausrüstungsgegenstand mit ins Gepäck muss. Alternativ hätte ich mein Netbook mitnehmen können, jedoch bietet dies nur geringe Rechnleistung, für längeres Arbeiten nervig kleine Bildschirmauflösung und eine relativ klein dimensionierte Tastatur für meine grossen Hände.
Als weiteres Zubehör neben dem Ladegerät sind ein 3m langes Flachband-Netzwerkkabel, das Ethernet-Breakout-Kabel, diverse USB-Sticks (einer davon als Notfall-Live-Stick), diverse USB-Kabel, passiver USB-Hub, eine kleine Funkmaus, ein USB-Headset und eine externe HD für Backups mit dabei.
Das Gerät ist natürlich von UEFI/Firmware bis Harddisk/OS komplett verschlüsselt und mit Passwörtern gesichert, so dass ein Dieb damit leider nur einen eleganten Briefbeschwerer erstehen würde. Die Markenlogos sind allerdings überklebt, um den Laptop etwas unscheinbarer zu halten. Zu seinem Schutz steckt das Gerät in einer Neoprenhülle.

Um eine ganze Bibliothek mittragen zu können, führt kein Weg an einem eBook-Reader vorbei. In meinem Fall handelt es sich um einen Kindle Paperwhite. Dank dem Notebook können bequem beliebige Dokumente via Calibre in Kindle-verwertbare Formate umgewandelt werden.

Als primäre Kamera habe ich meine unterdessen sechs Jahre alte Fuji F80 mit dabei. Diese ist komplett abgeschrieben, bietet aber immer noch relativ gute Bildqualität und ist relativ handlich. Ausnahme ist leider das Ladegerät, das sehr viel Volumen einnimmt. Ein zwingendes Kriterium für meine nächste Kamera ist somit, dass sie per USB-Anschluss geladen werden kann. Auch hier ist ein zweiter Akku mit dabei.

Als sekundäre Kamera ist eine billige Actioncam (Gembird ACAM-002) eingepackt, die im Gegensatz zum Vorgängermodell auch gemäss Spezifikation funktioniert. Die Kamera ist bis 30m wasserdicht und funktioniert auch mindestens in 25m Tiefe noch zuverlässig. Sogar die Knöpfe reagieren dann noch. Das hebe ich besonders hervor, denn beim Vorgängermodell war in 7m Tiefe Schluss mit jeglicher Funktionalität.
Ebenfalls zu Testzwecken mit dabei ist eine Billigst-Actioncam, die zwar auch bis 30m wasserdicht sein soll, jedoch werden schon in 2m Tiefe die Knopfabdeckungen eingedrückt, so dass das Gerät unbedienbar wird. Gefilmt hat sie auch überhaupt nichts, daher wird sie bei nächstbester Gelegenheit in die Schweiz zurückverfrachtet.

Als Backuptelefon ist mein altes Nokia 6300 mit dabei. Dort steckt derzeit auch die Schweizer SIM-Karte drin, jedoch ist es meist ausgeschaltet. Genutzt wird es v.a. für den Empfang der mTAN-Codes der eBanking-Zugänge.

Um Actioncam und Handy ohne Steckdose zu laden, habe ich ein Akkupack im Gepäck. Damit in ordentlicher Menge gefilmt und fotografiert werden kann, sind auch einige Micro-SD-Karten mit dabei. Mehr zum Spass ist noch ein Asus WL-330nul WLAN Accesspoint mit dabei. Der ist superklein und kann als USB-Ethernet-WLAN-alles-zu-allem-Adapter eingesetzt werden. Um überall USB-Geräte laden zu können, fliegen diverse USB-Steckernetzteile herum, sowohl mit Euro-, US- als auch KFZ-Stecker. Wichtig ist auch ein zweipoliger Steckerkonverter, dazu noch die Plastikdongles, um in UK-Steckdosen Eurostecker einstecken zu können. Derzeit in Singapur deponiert ist ein MiFi (mobile WiFi), damit wir in Kambodscha, Laos, Vietnam jeweils eine SIM-Karte unter allen Reisenden teilen können.

Zwischen IT- und Tauchequipment steht der Tauchcomputer. Um diesen auslesen zu können, musste noch ein USB-Infrarot-Dongle mit ins Gepäck.

Zwar handelt es sich um keine IT- sondern nur Elektrogeräte, aber immerhin sind sie per USB-Anschluss zu laden und seien daher hier erwähnt: Meine Stirnlampe kann zwar mit AAA-Batterien betrieben werden, für maximale Leistung gibt es aber einen Akku, der eine Standard Micro-USB-Buchse bietet.
Da mein Haarschneidegerät ersetzt werden wollte, suchte ich spasseshalber danach, ob es da auch etwas per USB ladbares gäbe, und ich wurde tatsächlich fündig. Es gibt genau einen Hersteller, der so etwas produziert, und da es sich mit Wilkinson auch um eine renommierte Marke im Bereich Haarentfernung handelt, wurde das Gerät als "reisekompatibel" eingestuft und erworben. Leider ist der Anschluss semiproprietär... Das Gerät kann zwar mit einem normalen USB-Ladegerät geladen werden, das dauert aber unabhängig von der Leistungsfähigkeit mehrere Stunden. Eine schnelle Ladung gibt es nur mit dem mitgelieferten Ladegerät, dessen Micro-USB-Stecker aber in keine sonstige Buchse passt, da am Stecker ein zusätzlicher Plastiknippel befestigt ist. Vermutlich drückt der im Gerät auf einen Knopf, der dann die Schnelladung aktiviert. Eventuell lässt sich das also "hacken".

s9y Twitterplugin Hack für Vermeidung von SSL

^ v M ><
Das Twitter-Plugin für mein Blog kündigt neue Einträge auf Twitter an, von wo sie dann wiederum auf Facebook veröffentlicht werden können. Leider mit einem Nachteil: Es wird immer das Schema verwendet (also http oder https), womit auch der Eintrag erstellt wurde. Es ist somit nicht möglich, für die Veröffentlichung http oder https zu erzwingen. In meinem Fall wäre es schön, wenn immer eine URL beginnend mit http:// verwendet werden würde, da ich zwar die Einträge über das verschlüsselte https:// schreibe, dafür aber ein selbstsigniertes Zertifikat benutze, das bei anderen Leuten eine Fehlermeldung im Browser erzeugt. Dies möchte ich nicht ändern, da kostenpflichtige Zertifikate einfach zu teuer sind, kostenlose Zertifikate wie z.B. von StartSSL meinen Ansprüchen nicht genügen und ich bei Mozilla's Let's Encrypt nicht wirklich Lust habe, Skripte zu installieren, die mir zuletzt noch die Webserver-Konfiguration zerschiessen.

Lösung: Ein schneller Hack des Plugins, um die veröffentlichte URL auf http:// festzunageln. Nachteil: Wenn ich das Plugin aktualisiere, muss ich daran denken, den Hack erneut vorzunehmen.

In der Datei serendipity_event_twitter.php muss in der Funktion generate_article_url die Zeile
$server = $urlparts['scheme'] . '://' . $urlparts['host'];
ersetzt werden durch:
$server = 'http://' . $urlparts['host'];

Dieser Eintrag dient mal wieder der Dokumentation und als Erinnerung an mich selbst, sowie als Erklärung für alle die sich wundern, warum der Artikel über Kuala Lumpur sich ohne Fehlermeldung aufrufen lässt :-)

Custom Debian Live USB-Stick

^ v M ><
Ausgehend von einem bestehenden Debian-Installer-Hybrid-Image habe ich ein Live-System für USB-Sticks gebaut, das an meine Bedürfnisse angepasst ist. Für Notfälle bietet sich deses System für die Hosentasche ebenso an, wie für spontane Installationen.

Benötigt wird zuerst ein passend vorkonfiguriertes, bestehendes Image. Das spart gegenüber einer frischen Zusammenstellung viel Zeit und Testaufwand. Das Vorgehen ist aber ansonsten weitgehend Identisch, weshalb ich dieser Anleitung folgen konnte. Sämtliche Schritte müssen mit root-Rechten durchgeführt werden. Als Basis habe ich das Debian 8.1 Installer-Image mit XFCE benutzt.

Einige nötige Pakete müssen auf dem Host-System installiert und die Arbeitsverzeichnisse erstellt werden:
aptitude install syslinux syslinux-utils squashfs-tools rsync xorriso isolinux
mkdir -p live_boot/chroot/
cd live_boot/
mkdir -p image/live

Danach wird das als Vorlage genutzte ISO gemountet und entpackt:
mkdir /mnt/iso /mnt/iso_root
mount debian-live-8.1.0-amd64-xfce-desktop.iso /mnt/iso -o loop
mount /mnt/iso/live/filesystem.squashfs /mnt/iso_root -o loop
rsync -av /mnt/iso_root/* chroot/
rsync -av /mnt/iso/* image/ --exclude=/mnt/iso/live

Nun gehen wir in's chroot:
mount -o bind /dev chroot/dev
cp /etc/resolv.conf chroot/etc/resolv.conf
chroot chroot

Das chroot muss nun noch mit ein paar Pseudodateisystemen und Einstellungen versorgt werden, bevor es vollständig operabel wird:
mount none -t proc /proc
mount none -t sysfs /sys
mount none -t devpts /dev/pts
export HOME=/root
export LC_ALL=C

Ab jetzt befindet man sich im chroot und kann die nötigen Modifikationen des künftigen Live-Systems vornehmen, z.B. die Konfiguration anpassen, beliebige weitere Pakete installieren oder das System aktualisieren. Dabei geht man genau gleich vor, wie bei einem installierten Arbeitssystem. Damit der USB-Stick z.B. alle WLAN-Karten unterstützt, können Firmware-Dateien (aus Debian non-free) nachinstalliert werden. Die Tastaturbelegung kann in /etc/default/keyboard an die eigene Tastatur angepasst werden, etc.

Ist man mit den Anpassungen fertig, wird das chroot wieder abgebaut und verlassen:
aptitude clean
rm -rf /tmp/*
echo > /etc/resolv.conf
umount -l /proc
exit
umount chroot/sys
umount chroot/dev/pts
umount chroot/dev
rm chroot/root/.bash_history

Nun wird das squashfs-Image mit dem root-Dateisystem erzeugt und der Kernel kopiert. Ein allfällig bestehendes squashfs-Image sollte aber davor gelöscht werden, da es sonst ergänzt statt überschrieben würde:
rm image/live/filesystem.squashfs
mksquashfs chroot image/live/filesystem.squashfs -e boot
cp chroot/boot/vmlinuz-3.16.0-4-amd64 image/live/vmlinuz
cp chroot/boot/initrd.img-3.16.0-4-amd64 image/live/initrd.img

Als vorletzter Schritt wird das ISO erzeugt. xorriso kann unter Verwendung von isohybrid, welches sich bei Debian im Paket syslinux-utils befindet, direkt ein bootfähiges Hybrid-ISO generieren. Gegenüber genisoimage hat xorriso mehrere Vorteile, einerseits wird das Hybrid-ISO in einem Schritt erstellt (statt es nachträglich per iso-hybrid Aufruf zu konvertieren), andererseits wird ein korrekter MBR auf den Stick geschrieben, so dass sich dieser nachträglich noch mit gparted umpartitionieren liesse. Der xorriso-Befehl wurde mit Tipps aus dem Ubuntu-Forum noch etwas optimiert:
cd image
xorriso -as mkisofs -D -r -J -joliet-long -l -V "Debian Live" -b isolinux/isolinux.bin -c isolinux/boot.cat -iso-level 3 -no-emul-boot -partition_offset 16 -boot-load-size 4 -boot-info-table -isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -o ../debian-live.iso .
cd ..

Dieses Hybridimage ist nicht per UEFI startbar, daher müssen UEFI-Systeme für dieses Image weiterhin den Legacy-Bootmodus aktiviert haben.

Das Image wird abschliessend auf einen USB-Stick geschrieben und kann danach getestet werden:
dd if=debian-live.iso of=/dev/sdX

Fortinet Rant

^ v M ><
Letztes Wochenende hatte ich das Vergnügen, eine Fortinet-Installation zu konfigurieren. Das sind nicht ganz günstige Firewalls, die sich einen professionellen Anstrich geben. Dann ist ja alles easy, oder? Bislang hatte ich noch keine Erfahrung mit den Geräten und somit zum ersten mal welche von nahem gesehen.
  • Alle paar Minuten (in einem zufälligen, willkürlichen Interval) wird man aus dem Webinterface automatisch ausgeloggt. Nicht gespeicherte Einstellungen gehen dabei verloren. Besonders toll, wenn das mitten in einem etwas längeren Assistenten passiert und man mehrfach von vorne anfangen darf.
  • Die Geräte wären ja echt ausführlich dokumentiert. Leider verweist Google konsequent auf veraltete Dokumentation unter docs-legacy.fortinet.com und die Links sind nicht einfach zu docs.fortinet.com abänderbar... SEO, anyone?
  • Die Doku besteht oft aus schönen Schritt-für-Schritt Anleitungen. Z.B. klicke auf den Menüpunkt "Router"... wait... das Gerät hier hat keinen Menüpunkt Routing... - oder klicke auf System -> Network -> Routing, dort auf New Item und fülle Feld X, Y, Z folgendermassen aus... nur dass der Assistent unter New Item die Felder X, Y und Z nicht bietet. aaaargh!
  • Die Geräte müssen beim Hersteller registriert werden, um z.B. Firmware-Updates zu erhalten. Auch nach scheinbar erfolgreicher Registrierung motzt das Gerät, dass die Registrierung nicht vollständig sei.
  • Auf einem der Geräte hat das dann auch dazu geführt, dass OTA-Firmware-Updates nicht möglich sind. Mann muss das Image also mühsam von Hand auf der Website des Herstellers suchen, anhand der kryptischen Dateibezeichnung das richtige erraten und ins Gerät hochladen.
  • Somit haben wir zwei Geräte, beide mit der gleichen Firmware-Version und der gleichen Grundkonfiguration. Nun lassen wir auf beiden den gleichen Assistenten laufen und tragen die gleichen Werte ein (logischerweise sind die IP-Adressen jeweils abweichend, aber ansonsten...). Das Ergebnis: Man erhält völlig andere Resultatansichten.
  • Es gibt eine USB-Konsole, worüber man die Geräte auch mit einer bequemen App für Desktop-Windows, OSX, Android und iOS konfigurieren und überwachen kann. Und ähem, hüstel, räusper... wo ist der Linux-Support?
Das sind alles Dummheiten, die ich bei einem Gerät, das 500 Franken aufwärts in der blanken Ausführung ohne Extras ausgesprochen ärgerlich finde. Das grundsätzlich kostenlose pfSense macht sowas nicht. Aber hey, wie sagt der Manager so schön: was nix kostet...

Handkehrum: Wenn die Dinger mal eingerichtet sind, scheinen sie ihren Zweck zu erfüllen. Immerhin. In der Grundkonfiguration scheinen sie auch standardmässig auf hohe Sicherheit eingstellt zu sein (d.h. es funktioniert zwar erstmal nichts, dafür funktioniert aber auch nichts, wovon man nichts weiss). Und mit dem Upgrade des OS auf Version 5.2 hat sich enorm viel an der Benutzerfreundlichkeit getan. Sonst wäre obige Liste noch viel länger.