planetknauer.net

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.

Normalerweise nutze ich die APU's mit pfsense oder opnsense als Firewall, aber diesmal soll ein etwas multifunktionaleres OS drauf, daher wie üblich: Debian.

Die Anleitungen lesen sich simpel. einfach Installer auf USB-Stick schreiben, USB-Stick rein, Serial-Kabel rein, anschalten, installieren, läuft.
Wie immer sind die Anleitungen gelogen. Es ist nie einfach. Es ist immer unnötig fucking kompliziert.

Erstes Problem: Der Installer lädt nicht. Es hängt nach ISOLINUX. Klar, der Installer kann kein Serial. Also: Netinstall-CD patchen, neu bauen, nochmals versuchen. Etwas Hilfe leistet dieser Github-Gist:
- Netinstall-Image herunterladen
- lokal mounten: mount -o loop debian-10.7.0-amd64-netinst.iso /mnt/temp/
- Arbeitsverzeichnis erstellen: mkdir iso-rework
- Kopieren: cp -r /mnt/temp/. iso-rework/
- Dateien bearbeiten: cd iso-rework/isolinux && chmod +w *.cfg
- in isolinux.cfg die Zeile SERIAL 0 115200 0 einfügen
- in txt.cfg die letzte Zeile ersetzen mit append gfxpayload=text console=ttyS0,115200 initrd=/install.amd/initrd.gz --- quiet
- wieder ins übergeordnete Verzeichnis zurückwechseln: ../..
- ISO neu bauen: xorriso -as mkisofs -rational-rock -joliet -joliet-long -full-iso9660-filenames -isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -partition_offset 16 -appid "Debian10.7" -eltorito-boot isolinux/isolinux.bin -eltorito-catalog isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o debian-10.7-amd64-netinst-serial-console-ttyS1-115200-8n1.iso iso-rework
- und nun den USB-Stick neu bespielen: dd if=debian-10.7-amd64-netinst-serial-console-ttyS1-115200-8n1.iso of=/dev/sdX bs=4M && sync

JETZT kann man das Ding einstecken und "einfach" booten.
Nächstes Problem: Konsolenoutput ist unleserlich. Lösung Teil 1: USB-Serial-Kabel nicht in einen USB-Hub sondern direkt in den PC stecken. Lösung Teil 2: Putty verwenden. Aber das lässt sich grafisch nicht konfigurieren (denn das wäre ja einfach), also muss man es von der Kommandozeile richtig aufrufen: putty /dev/ttyUSB0 -serial -sercfg 115200,8,n,1

Über Putty kann man nun schön beobachten, wie BIOS und Isolinux geladen werden und die Installationsauswahl angezeigt wird. Natürlich nicht "Graphical Installer" sondern "Install" (für Textinstallation) wählen. Das klappt bei mir jedoch nicht über serial... Ich brauche eine USB-Tastatur...

Nochmals von vorn. Und: Es lädt den Textinstaller. Doch kommen wir nun zum major fuckup des Tages, der mich extrem viel Zeit kostete, um mit Boot-Optionen zu experimentieren, es mit Debian 9 zu versuchen und sogar ein anderes APU zu probieren, um auszuschliessen, dass nicht ein Hardware-Defekt vorliegt:
Nun stecke ich in der Sprachauswahl des Installers und da geht wieder nichts mehr. Ich kann keine Sprache auswählen. Ich kann Tab, Space, Enter drücken, nichts passiert. Ich kann Eingaben über Putty versuchen, nichts passiert. Tatsächlich scheint dies ein bekanntes Problem von ein paar Laptops zu sein.
Irgendwann fand ich die brachiale Lösung: Nach Auswahl des Installers sofort die USB-Tastatur ausstecken, bevor der Kernel zu weit geladen hat. Dann über Putty weiterarbeiten.

Wieder einmal: Eine supereinfache Tätigkeit, zur völligen Perversion verkompliziert. Einfach, weil nichts "einfach" sein darf. One does not simply. Nicht wahr, Boromir?

oh-oh! Nachdem ICQ schon vor einigen Monaten das Protokoll mal wieder geändert hatte und dadurch mein XMPP-to-ICQ-Transport nicht mehr funktionierte, habe ich heute Morgen aufgeräumt und ICQ komplett entsorgt. Die verwendete Transport-Software pyicqt wird seit 11 Jahren nicht mehr weiterentwickelt, da besteht keine Hoffnung auf Wiederbelebung.

Zeit, ein Kapitel endgültig abzuschliessen. Und wieder einmal das Mantra zu wiederholen: Nutzt freie Protokolle!

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.

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.

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.

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

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

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

Wird der Laptop in den Ruhezustand oder Schlafmodus versetzt, verbindet OpenVPN nach dem Aufwecken nicht mehr und muss jeweils manuell neu gestartet werden, um den Tunnel neu aufzubauen. Das lässt sich doch sicher automatisieren? Natürlich, schliesslich wird auf dem Notebook Linux genutzt.

Unter Debian mit dem traditionellen SysV-Init geht das folgendermassen: Im Verzeichnis /etc/pm/sleep.d/ wird eine neue Datei 99openvpn erstellt und Ausführungsrechte mittels chmod +x 99openvpn gesetzt. Der Dateiinhalt lautet:

#!/bin/bash
case "$1" in
resume|thaw)
/etc/init.d/openvpn restart
;;
esac

Unter Systemen mit systemd ist das natürlich alles wieder anders, weil sich dort systemd um den Ruhezustand kümmert. Entsprechend braucht man ein anderes Skript an anderem Ort. Diesmal kommt das Skript nach /lib/systemd/system-sleep/ (der Ort kann bei anderen Distributionen abweichend sein) und heisst z.B. openvpn.sh. Auch hier werden wieder Ausführungsrechte mittels chmod +x openvpn.sh gesetzt. Das Skript enthält folgenden Inhalt:

#!/bin/bash
case "$1" in
post)
/bin/systemctl restart openvpn
;;
esac

Das war's, nun klappt's auch wieder mit OpenVPN. (Lösungsweg per Zufall inspiriert via thinkwiki, für systemd angepasst dank fedoraforum)

Zum Betrachten von Bildern auf den Desktop-Rechnern nutze ich das Programm geeqie, welches schnell, flexibel und mal mehr, mal weniger leichtgewichtig ist. Um unkompliziert eine Auswahl an Bildern aus einer grösseren Kollektion vorzunehmen, habe ich ein kleines Skript geschrieben, und geeqie darum erweitert. Die Idee ist, dass auf Tastendruck das aktuelle Bild in ein festgelegtes Verzeichnis kopiert werden soll. Mit dieser Kopie kann dann später weitergearbeitet werden (schneiden, verkleinern, verschicken...).

Dazu geht man folgendermassen vor:
In /usr/local/bin legt man eine Skript namens "geeqie-select.sh" mit folgendem Inhalt an:

#!/bin/bash
myfile="$1"
selections="$HOME/misc/selections"

oldpath=$(dirname "$myfile")
subdir=$(basename "$oldpath")

if [ ! -d "$archive/$subdir" ]; then
mkdir -p "$selections/$subdir"
fi

cp "$myfile" "$selections/$subdir/"

Die Zeile "selections" legt fest, wohin die ausgewählten Bilder gespeichert werden. Nicht vergessen, das Skript ausführbar zu machen (chmod +x).

Nun startet man geeqie und wählt im Menü "Edit -> Preferences -> Configure Editors" und klickt dort auf den Knopf "New". Dort fügt man folgende .desktop-Definition ein (unten noch den Namen von new.desktop zu z.B. geeqie-select.desktop ändern...):

[Desktop Entry]
Version=1.0
Type=Application
Name=Geeqie Select
Exec=/usr/local/bin/geeqie-select.sh %f
Categories=X-Geeqie;
OnlyShowIn=X-Geeqie;
X-Geeqie-Menu-Path=FileMenu/FileOpsSection

Dies erzeugt einen neuen Eintrag "Geeqie Select", welcher im geeqie-Menü unter "File -> Geeqie Select" erreichbar ist.

Nun muss noch ein Tastenkürzel definiert werden. Dazu wählt man "Edit -> Preferences -> Preferences" und wechselt dort aufs "Keyboard"-Tab. Nun sucht man in der Liste den Punkt "Geeqie Select" und weist ein noch freies Tastenkürzel zu. Fertig.

Nun kann man das vorher festgelegte Tastenkürzel drücken, und es wird eine Kopie im festgelegten Zielverzeichnis erstellt.

Eine Unschönheit gibt es allerdings, wenn die angezeigten Bilder in einem schreibgeschützten Ordner liegen, meckert geeqie, dass das Zielverzeichnis schreibgeschützt sei. Das ist natürlich falsch, lässt sich aber leider nicht verhindern.

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.

Egal, was man in /etc/profile.d/mycustomfile.sh definiert... Debian mit XFCE und lightdm liest es nicht ein. Dies ist offiziell so gewollt. Da gilt: korrekt konfigurieren. Da niemand so wirklich weiss, wie's geht, gilt: ausprobieren bis es klappt.

Der korrekte Weg:
erstelle eine Datei mit den nötigen export-Statements im Verzeichnis /etc/profile.d/ - wichtig ist, dass die Datei auf .sh endet. Aus Sicherheitsgründen sollte sie root gehören und auch nur durch root beschreibbar sein (chown root:root /etc/profile.d/* und chmod o-w /etc/profile.d/*). Der Dateiinhalt schaut dann z.B. so aus (der Rest meines Systems ist amerikanisch kolonialisiert mit en_US.UTF-8):

export LC_PAPER=de_CH.UTF-8
export LC_MEASUREMENT=de_CH.UTF-8
export LC_TIME=de_CH.UTF-8
export LC_MONETARY=de_CH.UTF-8
export EDITOR=vi

Als nächstes muss /etc/profile durch $HOME/.profile eingelesen werden. Dazu fügt man in die Datei folgende Zeile ein:

. /etc/profile

Damit auch grafische Anwendungen die Umgebungsvariablen mitbekommen, muss $HOME/.profile nun durch $HOME/.xsessionrc eingelesen werden. Wenn die Datei nicht existiert, kann man sie einfach mit folgendem Inhalt erstellen:

. $HOME/.profile

Somit hat man eine konsistente Profilumgebung in allen Konsolen und in grafischen Anwendungen.

Vorsicht, ~ für $HOME und source für . sind reine Bash-Aliase und dürfen nicht verwendet werden! Das ist die grosse Stolperfalle, welche es zu umgehen gilt und die so ziemlich überall unerwähnt bleibt (im Debian-Bugreport wie auch in diesem ansonsten hilfreichen Beispiel werden diese Bashismen verwendet)

Wichtig ist natürlich, dass die locale-Definitionen existieren. Unter Umständen müssen diese erst über den Befehl dpkg-reconfigure locales aktiviert und generiert werden.