planetknauer.net

Von Mostar ging es per Bus nach Dubrovnik. Diese Busfahrt war deutlich weniger Vorurteilsbestätigend, da der Bus pünktlich abfuhr und der Fahrer einen sehr zivilisierten Fahrstil hatte. Dubrovnik ist schon deutlich touristischer als Mostar, was sich insbesondere bei der Verpflegung niederschlägt. Die hiesigen Cevapi hier waren die wenigst schmackhaften auf der ganzen Reise. Dafür gab es guten Fisch und die Glace-Portionen waren so gross, dass sie dies wieder wettmachen konnten.

Die Stadt hat letzter Zeit grössere Bekanntheit durch Filmaufnahmen für "Game Of Thrones" erlebt und stellt dank ihrer sehr gut erhaltenen mittelalterlichen Altstadt die Kulisse für zahlreiche Orte in der Saga. Dementsprechend wird dies kräftig beworben. Genau wie Mostar hat leider auch diese Stadt Kriegsschäden erlitten, welche noch nicht überall behoben sind.

Natürlich darf man sich einen Stadtrundgang nicht entgehen lassen. U.a. muss man auch auf den Stadtmauern spazieren und die Festung Lovrijenac besteigen. Diese kosten leider relativ viel Eintritt, doch es empfiehlt sich die Dubrovnik-Karte zu lösen. Diese kostet nur wenig mehr als die Mauern alleine und enthält Eintritte in diverse Museen (wobei längst nicht alle davon die Zeit wert sind...) sowie eine Tageskarte für den Bus. Für eine Küstenstadt ist Dubrovnik erstaunlich hügelig und bietet viele enge, verzweigte und malerische Gassen und Treppen, die auf Erforschung warten.

Ein weiteres Ausflugsziel stellt der Hausberg Srd dar, welcher per Seilbahn erschlossen ist. Neben einem fantastischen Ausblick über die Stadt und die Adria-Inseln befindet sich dort die Ruine einer Festung, welche von Napoleon gebaut wurde. Leider ist diese stark beschädigt und ist daher kaum zugänglich.

Mindestens so lohnenswert ist die Insel Lokrum, welche per Fähre in wenigen Minuten zu erreichen ist. Neben einem weiteren GoT-Drehort befinden sich dort ein verlassenes Kloster, eine weitere Festung und ein botanischer Garten. Die Gegend rund um das Kloster ist von Pfauen und Hasen besiedelt. Wer plant, ein Picknick auf der Insel zu essen, sollte sich an einen Strand oder zur Festung begeben. Ansonsten wird man von den Pfauen bedrängt und von den Hasen gejagt. Jawohl, die Hasen auf Lokrum sind Jäger und nicht Gejagte! Womöglich liessen sich Monty Python an diesem Ort zu ihrer Bestie inspirieren...

Hier noch ein paar Eindrücke von Lokrum:

Im April war ich für zwei Wochen in Bosnien und Kroatien in den Ferien. Eigentlich hatte ich nicht geplant, darüber gross zu schreiben, aber auf mehrfachen Wunsch zur Abwechslung wieder ein paar Bilder und Erzählungen statt Gemecker über dysfunktionale IT.

Die Anreise erfolgte per Flugzeug nach Split und von dort weiter mit dem Bus. Der Busfahrer erfüllte schon alle prototypischen Vorurteile über "Jugos": Erst kam er viel zu spät zur Arbeit, danach war er auch eher mässig auf die Strasse konzentriert. Dazu verschlief er jede Ampel und würgte zuletzt noch den Motor ab... Später gab er dafür um so mehr Gas. Da war ich doch froh, mich in der einzigen Sitzreihe mit Sitzgurten niedergelassen zu haben.

Erst ging es nach Mostar. Die Stadt ist berühmt für ihre Brücke aus dem Mittelalter, welche im Jugoslawienkrieg zerstört wurde. Unterdessen ist die Brücke wieder aufgebaut und stellt wieder das Wahrzeichen der Stadt dar. Der Stadtkern ist eine erstaunlich gut erhaltene mittelalterliche Stadt, die vor kultureller Vielfalt strotzt. Neben bosnisch-muslimischen und türkischen Einflüssen finden sich auch kroatische und serbisch Einflüsse. Dies manifestiert sich nicht nur an einer bunten Mischung aus Moscheen und Kirchen, sondern auch in einer vielfältigen profanen Architektur und abwechslungsreichen Speisekarten. Besonders Fleisch steht hoch im Kurs und die dortigen Cevapi sind nicht nur preislich attraktiv sondern waren auch die besten auf der ganzen Reise.

Da die Altstadt sehr klein ist und sich praktisch der ganze Tourismus rund um die Brücke konzentriert, erscheint die Stadt auf den ersten Blick überlaufen. Je weiter man sich jedoch von der Brücke entfernt, desto weniger Touristen finden sich. Für einen schönen Ausblick lohnt sich ein Trip auf den Wallfahrtsberg Humu. Wer etwas mehr Zeit mitbringt, kann auch dem Fluss Neretva entlang in Richtung Kroatien Ausflüge zu diversen Attraktionen wie einem ehemaligen Derwisch-Kloster oder Wasserfällen machen. Für die Abendunterhaltung bietet sich das örtliche Pub an, welches sich mit lokalem Craft-Bier und Bluesrock-Livemusik empfiehlt.

Die grossen Schäden aus dem Krieg sind leider nach wie vor vorhanden. Viele Häuser wurden wieder aufgebaut, aber dennoch stehen viele Ruinen. In vielen Häusern findet man Einschusslöcher. Interessanterweise oft auch in sanierten Gebäuden, so dass sich die Frage stellt, ob diese als Denkmal beibehalten wurden.


Interessant ist auch der Pflanzenbewuchs. In vielen Parks wächst primär Rosmarin. Dieser säumt ganze Wege und Wände und versprüht einen angenehmen Geruch.

Mir ist ein altes Samsung Galaxy S2 in die Hände gekommen, das für einen potentiellen Empfänger tauglich gemacht werden sollte. Bislang war bereits ein etwas in die Jahre (oder doch nur Monate?) gekommenes Cyanogenmod installiert. Aber Cyanogenmod ist tot, darum soll auf jeden Fall aktuellste Software installiert werden. Da kommt fast nur LineageOS in Frage (v.a. auch da ich damit gute Erfahrungen auf S3 und S5 gemacht habe). Da der Empfänger noch empfindlicher auf seine Privatsphäre achtet als ich, habe ich die Google-Apps weggelassen. Diese zu installieren benötigt aber nur einen weiteren Befehl und zwei Klicks mehr in der Recovery.

Leider war die Installation nicht ganz einfach, da die /system-Partition erstens nur 500MB gross ist (das ist zu klein, LineageOS verlangt mindestens 600MB), zweitens einen Defekt hat und drittens alle im Internet gefundenen Anleitungen zur Installation und Repartitionierung falsch sind, insbesondere die offizielle Anleitung von LineageOS. Ausserdem sind die meisten Anleitungen von Windows-Schafen geschrieben und nutzen Odin, während mir unter Linux Heimdall zur Verfügung steht.

Als Voraussetzung für diese Anleitung setze ich voraus, dass der Leser mit TWRP bereits vertraut ist. Ausserdem gilt ganz klar: Anwendung auf eigene Gefahr!

Beim i9100 sind ein paar Spezialitäten zu beachten, so ist das Recovery-Image in das Kernel-Image integriert.

So hat's bei mir funktioniert:
Erst sichergehen, dass auf dem Computer die aktuellsten Versionen von heimdall und adb installiert sind.
Download von PIT-Dateien (eine Art Partitionstabelle für Samsung-Geräte) von hier
Download von TWRP (Custom Recovery) von hier
Download des aktuellsten LineageOS-Build von hier
Ggf Download des su-addons und/oder gapps, wenn benötigt.
Aus lineage-14.1-*-nightly-i9100-signed.zip muss die Datei boot.img extrahiert werden.
Aus Pit_files.rar muss die gewünschte PIT-Datei extrahiert werden, ich habe I91001GB_4GB.pit (1GB /system, 4GB /data) verwendet.

Boot des Telefons in den Download-Modus mittels VolDown-Home-Power (Bestätigen mit VolUp). Anschliessend das USB-Kabel anschliessen.
Upload des neuen PIT-Files und flashen der Recovery mittels:
heimdall flash --repartition --pit I91001GB_4GB.pit --RECOVERY twrp-3.1.0-0-i9100.img --KERNEL boot.img --no-reboot

Danach das Telefon ausschalten, das USB-Kabel ausziehen, kurz die Batterie entfernen (ansonsten liess es sich bei mir nicht wieder booten), Batterie wieder einfügen.
Start des Telefons in den Recovery-Modus mittels VolUp-Home-Power
TWRP sollte nun starten. In TWRP den Menüpunkt "Wipe" -> "Advanced Wipe" -> "System" -> "Repair or Change File System" -> "Resize File System". Bei Erfolg auf "back" klicken und in der Übersicht auf "Change File System" -> "ext4". In der Übersicht wird die Dateisystemgrösse falsch angezeigt, evtl sogar als 0 Byte. Dies ignorieren. Nach erfolgter Reformatierung auf "back" klicken. In der Übersicht sollte jetzt korrekt 1007MB als Dateisystemgrösse angezeigt werden. Dasselbe Spiel für "Data" und "Internal Storage" wiederholen. Es können dabei viele rote Fehler angezeigt werden, dass Partitionen nicht eingebunden werden können. Dies kann (hier) ignoriert werden.
Nun das Telefon wieder ausschalten, Batterie raus und wieder rein, und erneut in den Recovery-Modus booten.
in TWRP erneut auf "Wipe" -> "Advanced Wipe" und einen gleichzeitigen Wipe von Dalvik, Cache, System, Data und Internal Storage durchführen. Wenn keine roten Fehlermeldungen erscheinen, kann der Flash-Vorgang beginnen. Ansonsten muss so lange mit der Reformatierung herumgespielt werden, bis es klappt.

Nun das USB-Kabel wieder anschliessen und mittels adb die zu installierenden zip-Dateien hochladen:
adb push lineage-14.1-*-nightly-i9100-signed.zip /sdcard0/
Wichtig! Der interne Speicher heisst /sdcard0/, nicht /sdcard/, wie in vielen Anleitungen behauptet!

In TWRP nun auf Install gehen und die zip-Dateien gemäss handelsüblicher Anleitungen flashen. That's it. Uff. Ja, ist kompliziert und viel unnötiger Aufwand.

Update: Ein Leser weist mich auf diese hervorragende Anleitung hin... für Windows

Update: Ein weiterer Leser gibt noch zwei Tipps mit:
1. Wenn es mit dem Download der PIT-Datei nicht funktioniert, anderes USB-Kabel, bzw. anderen USB Port benutzen. Den Tipp gab's an verschiedenen Stellen und hat mir geholfen.

2. Ich habe es dann ums verrecken nicht geschafft, per "adb" etwas auf's Handy zu schieben. Ich habe es dann letztendlich auf eine Micro-SD karte kopiert, die ins Handy gesteckt und von dort installiert.

Heute wurde mir ein Paket geliefert, worin sich ein Server (geschäftlich) in Einzelteilen befand. Nachdem ich mich durch den Verpackungswahn durchgeackert hatte, konnte ich diesen assemblieren und für die Inbetriebnahme vorbereiten.

Als erstes beim Öffnen der riesigen Kartonschachtel entfernte ich eine Unmenge Luftpolster. Diese füllten die Kiste zu mehr als der Hälfte.

Daneben fiel natürlich noch jede Menge weiterer Müll an, der aber teilweise schwerer zu vermeiden ist, als die Luftpolster. Dennoch ist es der schiere Verhältnisblödsinn, dass ich einen Server, der assembliert mindestens ein Dutzend Mal in der Kiste platz gefunden hätte, in so einer riesigen Verpackung geliefert bekomme.

Aber zum Glück ist der Klimawandel ja nur eine Lüge (sagt ja sogar der neue US-Präsident, also muss es wahr sein) und Erdöl ist eine unendliche Ressource, womit wir beliebig viel Plastik produzieren können.

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)

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.

Mit Update auf den Backport-Kernel 4.6 war meine Soundblaster-Karte nach Start des PCs nur noch sporadisch vorhanden. Stattdessen war in aller Regel nur noch das USB-Headset vorzufinden. Ein Blick in dmesg zeigte wieder einmal desaströses:

snd_emu10k1 0000:04:06.0: cannot find the slot for index 0 (range 0-1), error: -16

Da ich die Soundblaster als primäre Systemsoundkarte nutzen will, wird diese per Konfiguration auf slot/index 0 gezwungen. Aus irgend einem Grund ist slot 0 aber plötzlich bereits belegt...

Bislang habe ich die Reihenfolge meiner Karten über einen Eintrag in der Datei in /etc/modprobe.d/audio.conf geregelt:

options snd_emu10k1 index=0
options snd_usb_audio index=1

Die Reihenfolge muss neuerdings über einen weiteren bzw alternativen Eintrag festgelegt werden:

options snd slots=snd_emu10k1,snd_usb_audio

Siehe hier (innerhalb der Seite nach slots= suchen, die Anchor-Links sind kaputt). Ohne diese Einstellung hätte sinnloserweise die USB-Soundkarte höchste Priorität.

Hach ja, es würde mir ja sooo langweilig werden, wenn der Kack "einfach so(tm)" weiterlaufen würde.

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.

Gestern hat das Unfairphone zwar nochmals ein Software-Update erhalten, das zwar an der Oberfläche kratzt (z.B. Bildschirmflackern behebt oder den sinnlosen Privacy Indicator angeblich endlich deaktivierbar macht), aber die richtigen Probleme (fehlende Konfigurationsmöglichkeiten, fehlender Privacy Guard, fehlende Unterstützung für Dateisysteme) natürlich nicht behebt. Aber das ist dennoch zu spät, denn heute hat mir der Pöstler Ersatz geliefert. Diesmal ein von im Vergleich zum Unfairphone nicht ganz so glücklichen Chinesen zusammengeklebtes Galaxy S5. Warum so ein altes Gerät? Nun, im Prinzip ist es dasselbe wie das Unfairphone, nur in irreparabel, leicht und ohne zweiten SIM-Slot. Ansonsten ist die Hardware ziemlich identisch. Und: Es gibt eine recht solide Unterstützung durch CyanogenMod!

Gemäss Anleitung ist die Installation so kinderleicht wie beim S3. Doch der Teufel liegt wie immer im Detail. Erst startet man das Gerät mittels VolDown-Home-Power im Download-Modus und installiert ein Recovery-Image:

heimdall flash --RECOVERY twrp-3.0.2-1-klte.img --no-reboot
Heimdall v1.4.0
[..]
ERROR: Failed to download PIT file!

Muh! Wäre ja zu schön, wenn es auch nur ein einziges Mal einfach wäre!

Also muss als erstes Heimdall auf die letzte Version von github aktualisiert werden. Wie bei all meinen technischen Einträgen wird Debian als Basis verwendet. Bevor nun irgend ein Troll meint, na klar, mit der Uralt-Version aus Debian ist das auch kein Wunder: den Spruch kann man sich hier sparen, da auch die letzte offiziell veröffentlichte Version von Heimdall (1.4.1) nicht ausreicht. Es muss zwingend die Version aus dem git-Repository sein!

aptitude install build-essential cmake libusb-1.0-0-dev qt5-default libgl1-mesa-glx libgl1-mesa-dev
git clone https://github.com/Benjamin-Dobell/Heimdall.git
cd Heimdall
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make
cd bin

Nun kann erneut gemäss Anleitung versucht werden zu flashen:

./heimdall flash --RECOVERY /path/to/twrp-3.0.2-1-klte.img --no-reboot

D.h. man startet die Recovery mittels VolUp-Home-Power. Als kleinen Umweg habe ich mittels des gestarteten Recovery erst ein Backup erstellt und dieses mit ADB auf den Desktop-Computer kopiert:

adb pull /sdcard/TWRP TWRP

Danach kann man aber wirklich gemäss Anleitung weitermachen, ein möglichst minimales Google-Apps-Paket installieren und sich an einem relativ schlanken, funktionalen Telefon mit verstärktem Schutz der Privatsphäre erfreuen.

Und das Unfairphone? Wird wegen Nichtgebrauchs verkauft. Und das S3? Wird zur Bastelplattform umfunktioniert.

Um Kontakt nach Fernost zu halten, bestand die Notwendigkeit einer Messenger-Lösung, die auf Mobilgeräten und Desktops (und zwar idealerweise als Plugin für Pidgin) läuft, Videotelefonie beherrscht und nicht von Microsoft stammt. Somit fällt Skype weg, da unterdessen zum Evil Empire aus Redmond zugehörig. WhatsCrap fällt auch weg, da nicht (legal) abseits eines einzelnen Mobilgeräts nutzbar. Viber fällt auch weg, da von keiner der bestehenden Parteien genutzt. XMPP hat seine lieben Probleme mit der Videotelefonie (und wird ausserdem nur von mir, nicht aber den Gegenparteien genutzt... seufz...).

Die Desktop-Anforderung ist für mich ein zwingendes Argument, da mir die Fummelei auf dem Telefon einfach zu mühsam ist. Ausserdem will ich nicht alle paar Sekunden die Hände von der Tastatur nehmen und das Gerät wechseln. Der Wechsel zwischen produktiver Arbeitsumgebung und Messenger ist gerade noch akzeptabel.

Die Notlösung hierfür heisst "Line Messenger" aus Korea, ist in Japan super populär und die Verwendung unter Linux selbstverständlich ein Gefrickel ohne offizielle Absegnung. Aber immerhin gibt es ein inoffizielles Plugin für Pidgin. Dessen Installation funktioniert relativ gut gemäss Anleitung auf der verlinkten Seite (code_name bei Debian ist stable, testing oder unstable, bei Ubuntu der jeweilige Release-Name, d.h. trusty, vivid oder wily). Ein paar Worte zur Einrichtung wären aber nicht verkehrt gewesen...

Zuerst muss man Line auf einem Mobilgerät installieren, ein Konto erstellen und damit Online gehen. Als nächstes muss eine Email-Adresse verknüpft werden, das macht man durch Klick auf das Icon [...] rechts oben, dann die Einstellungen (das Zahnradsymbol gleich unter [...]), "Account" und "Email Account Registration". Dort trägt man eine eigene Email-Adresse ein und vergibt ein Passwort dafür. Wichtig: Keinesfalls das Passwort des Email-Kontos angeben! Man erhält nun eine Email mit einem Verifikationscode, welchen man in der App eingeben muss.
Zuletzt muss man auf Privatsphäre verzichten und unter "Chats & Voice Calls" die Option "Letter Sealing" deaktivieren. Dies ist die Ende-zu-Ende-Verschlüsselungsoption von Line, die purple-line leider noch nicht unterstützt. Andererseits handelt es sich bei Line um eine rein proprietäre Anwendung, daher gilt eh jede dort implementierte Verschlüsselung bestenfalls als "Security By Obscurity" ohne nachweisbaren Wert!

Nun startet man Pidgin mit installiertem Line-Plugin. Unter Accounts -> Manage Account -> Add... muss folgendes eingetragen werden:
Protocol: Line
Username: Die mit dem Line-Konto verknüpfte Email-Adresse
Password: Das in der App gesetzte Passwort zu dieser Email-Adresse
[x] Remember password
Nach Klick auf Add wird das Konto hinzugefügt und verbunden. Beim ersten Verbindungsversuch poppt ein Fenster mit einem Verifikationscode auf, der innert drei Minuten in der App eingetragen werden muss. Es dauerte bei mir jedoch rund eine Minute, bis das entsprechende Popup auf dem Mobilgerät erschien.

Anschliessend ist Line auch vom Desktop-Computer aus chatbereit. Es gibt jedoch einige Einschränkungen des sich in in sehr langsamer Entwicklung befindlichen Plugins: neben der fehlenden E2E-Verschlüsselung ist ausschliesslich Text-Chat möglich, d.h. keine Audio- oder Videotelefonate. Für diese muss weiterhin auf die mobile App zurückgegriffen werden. Abbrüche der Internetverbindung werden nicht erkannt und man bleibt scheinbar verbunden. Als Presence-Status gibt es ausschliesslich die Wahl zwischen Online/Available oder Offline (kein Away). Bilder können nicht verschickt, sondern nur empfangen werden. Diese werden dann auch nur angezeigt, wenn sie einzeln empfangen werden. In Text eingearbeitete Icons werden nicht korrekt dargestellt.

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.

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

Als letzte neue Destination auf der Reise ging es auf's berühmt-berüchtigte Bali. Nachdem ich den ersten Tag mit Planung und Faulenzen verbracht hatte, ging es darauf rund um die Insel. Über mein Hotel konnte ich einen guten Deal für ein Auto mit Fahrer für zwei Tage aushandeln. So führte der erste Tag als erstes zu Reisterrassen. Von der Höhe her können sie zwar keineswegs mit Sa Pa oder Banaue/Batad mithalten. Aufgrund der vielfältigen Landschaft und dem bereits kräftig wachsenden Reis sind sie aber dennoch sehr sehenswert.

Weiter ging es bis zum Mount Batur, einem aktiven Vulkan im Nordosten der Insel. Leider versteckte sich der Batur hinter einer dichten Wand aus Regen und Wolken. So wird man wieder daran erinnert, dass eigentlich immer noch Regenzeit herrscht. Nur mit viel Geduld liess er sich hervorlocken. Dafür liess ich mich dann bis zum Kratersee herunterfahren, wo eine heisse Quelle zum Baden einlädt. Das Spa ist zwar schön gestaltet, aber nur bedingt entspannend, da man entweder permanent angefragt wird, ob man eine Massage möchte oder sich in den überbelegten Pool mit kreischenden Kindern begeben muss...

Weitere Zwischenstopps waren der mässig spektakuläre Tirta Empul Tempel und eine Kaffeeplantage. Und zwar nicht irgend eine, sondern DIE Plantage, wo der berühmte "Katzenkaffee" hergestellt wird. Die Kaffeebohnen werden von Fleckenmusangs (die keine Katzen sondern nur katzenartige Raubtiere sind) gefressen und unverdaut wieder ausgeschieden. Da die Viecher nur perfekt gereifte Kaffeekirschen fressen, ergibt dies qualitativ hochwertigen Kaffee. Da erst der Musangkot mühsam zusammengesucht und danach die Bohnen gereinigt, geschält und geröstet werden müssen, ist dieser Kaffee sehr exklusiv und entsprechend abartig teuer. Neben dem Verfahren zum Rösten von Kaffee lernte ich auch über das Rösten von Kakao.

Am nächsten Tag war Tempeltour angesagt, so ging es erst zum Uluwatu, der auf einer Landspitze liegt, die von kräftigen Wellen umspült wird. Von dort führte die Fahrt weiter zum Tanah Lot Tempel, der auf einem kleinen Inselchen liegt und jede zweite Postkarte von Bali ziert. Von dort liess ich mich zum Strand von Kuta fahren, der für seine Sonnenuntergänge sehr berühmt ist. Leider zogen im Verlauf des Nachmittags immer dichtere Wolken auf und erstickten so jeglichen Ansatz von rot in undurchdringbarem grau.

Nun war aber genug des Sightseeings, es sollte mal wieder ins Wasser gehen... mit viel Mühe schaffte ich es, einen Tauchlehrer zu finden, der mich in Sidemount-Tauchen (also Tauchen mit Tank an der Seite statt am Rücken) ausbilden kann. In Lombok, Komodo und Bali habe ich zusammen über ein Dutzend Tauchschulen angefragt, die entsprechende Kurse auf ihrer Homepage listen. Die üblichen Antworten waren "im Prinzip ja, aber momentan ist der Instruktor nicht verfügbar oder das Equipment in Revision bzw auf einer anderen Insel, oder wir haben wohl einfach keine Lust". So verbrachte ich einen Tag mit Theorie im Klassenzimmer und Übungen im Pool, bevor es am nächsten Tag zur praktischen Anwendung ins Meer ging. Die Tauchgänge direkt vor der Küste von Sanur waren zwar nur mässig beeindruckend von der Unterwasserwelt her, aber immerhin gab es diverse Wasserschlangen als Highlight zu sehen. Daneben hat mir auch die neue Variante zu tauchen sehr zugesagt. Es gibt zwar auf der einen Seite einiges mehr zu beachten, vereinfacht aber auf der anderen Seite viele andere Dinge.

Wenn schon keine pazifischen Inseln, dann halt ein anderes Ziel, das schon lange auf der Liste steht: Komodo. Für Nicht-Taucher ist die Gegend wohl primär bekannt für die Drachen, die Komodo-Warane. Taucher wissen ebenfalls um die tolle Unterwasserwelt mit ihren starken Strömungen, die teilweise deutlich heftiger und unberechenbarer als in Raja Ampat sind. Beides lässt sich auch prima kombinieren und so fragte mich der Divemaster am Vorabend vor der ersten Ausfahrt, ob ich auch die Drachen sehen will. Natürlich! So kam ich schon am ersten Tauchtag zum Vergnügen eines Landausflugs auf Rinca (ausgesprochen Rintscha, nicht Rinka), die besser erreichbar und kleiner ist als Komodo, wodurch die Wahrscheinlichkeit einen Drachen zu sehen steigt.

Tatsächlich wimmelt es auf der Insel nur so von den Viechern. Daneben gibt es auch Wasserbüffel, Affen, Rehe, Wildpferde, Wildschweine, diverse Vogelarten, Salzwasserkrokodile (die sich zum Glück versteckt hielten)... und eine fantastische Landschaft mit Mangrovenwäldern an den Küsten und tollen Ausblicken auf den Hügeln. Die Ausflüge finden stets in Begleitung eines Rangers statt, der mit einem Stock bewaffnet allfällig angriffige Drachen abwehren soll. Zum Glück liegen die Viecher in der Mittagshitze aber einfach nur regungslos da und posieren für Fotos. Mit drei Metern Länge und 70kg Gewicht sind sie schon recht eindrücklich anzusehen.

Als sportliche Betätigung und Höhentraining beschloss ich nach dem Mount Kinabalu vor drei Jahren erneut einen Berg in Südostasien zu besteigen. Auf Lombok liegt der aktive Vulkan Rinjani, welcher doch die beachtliche Höhe von 3726m aufweisen kann.

Leider beschloss meine brandneue Kamera in der Nacht vor dem Aufstieg das Zeitliche zu segnen und nur noch lustig mit der Status-LED zu blinken, wenn man sie einzuschalten versucht. Daher gibt's hier vorerst nur minderwertige Fotos von der Handykamera.

Für verhältnismässig viel Geld kaufte ich mich in eine geführte Tour mit Rundumsorglospaket ein. Am Sonntag Morgen um 5 (also pünktlich zum Ruf des Muezzin) wurde ich abgeholt und ins Trekking-Center gebracht, wo ich meine Trekkingpartner und den Guide traf. Nach Registrierung und Einkäufen ging es gegen 10 dann endlich los und wir begannen den Aufstieg auf einer Höhe von ca 1100m. Schon nach kurzer Zeit stand die Mittagspause auf dem Programm, in der uns Träger und Guide mit hohem Aufwand ein Nasi Goreng frisch zubereiteten. Frisch gestärkt ging es dann weiter bis zum Basecamp auf 2700m, welches wir durch viele Pausen unterbrochen erst gegen 18:00 erreichten. Da der Berg erst vor zwei Tagen nach der Regenzeit für die Besteigung freigegeben worden war und unsere Träger dementsprechend noch nicht trainiert waren (die armen Kerle müssen immerhin rund 30kg für uns buckeln), kamen wir viel langsamer voran als erhofft. Auf dem Berg wurden wir nochmals bekocht, was aufgrund der Höhe enorm lange dauerte, so dass wir gegen 21:00 endlich auch ein Abendessen erhielten.

Am nächsten Morgen ging es schon um 3 wieder los, nach einem kleinen Snack begannen wir auch die letzten 1000 Höhenmeter zu bezwingen. Da ich unbedingt den Sonnenaufgang vom Gipfel aus sehen wollte, stieg ich mit grossen Schritten voran. Leider reichte es doch nicht, das Ziel verpasste ich um ca 5 Minuten. Dafür bot sich ein spektakulärer Ausblick in den Krater, auf den See und den innenliegenden Krater des Barujari.