Homebanking unter Linux

Seit geraumer Zeit nutzen meine Frau und ich ein Haushaltsbuch auf App-Basis, welches uns eine Auswertung unserer Einnahmen und Ausgaben nach Kategorien ermöglicht. Das ganze klappt auch recht gut mittlerweile. Wer sich dafür interessiert: Die App heißt „Unser Haushaltsbuch“, von einem deutschen Entwickler, es werden keine Online-Services genutzt, zum Synchronisieren von mehreren Nutzern kann man ein verschlüsseltes Sync-File bei Google Docs ablegen.

Was das Tool nicht nicht kann: einen Überblick über unsere Konten geben, am besten mit einer Langzeitanalyse. Das ist auch nichts, was ich an die Sparkasse oder Data Buhl und Co. in die Cloud auslagern wollen würde. Und dafür jedesmal eine VM oder ein Windows hochfahren finde ich ein wenig mit Kanonen auf Spatzen geschossen.

Prinzipiell ist Finanzsoftware unter Linux ähnlich stiefmütterlich behandelt wie einst Spiele unter Linux und auch wenn ich kein Java-Freund bin: Die Software für die ich mich entschieden habe, läuft und liefert einfach, was ich haben will: Zahlen und Diagramme.

Screenshot: willuhn.de

Nach einiger Suchererei nach Anwendungen, die ähnlich wie WISO MeinGeld oder StarMoney mir meine Kontenhistorie lokal verfügbar machen, bin ich schließlich bei Hibiscus gelandet. Das ganze ist ziemlich rund, wenn man ein paar kleine Copy-Paste-Aktionen und ein bisschen Doku lesen nicht abschreckend findet. So habe ich unsere kompletten Konten zusammengefasst und kann jetzt auch bequem alle Umsätze auf dem heimischen Rechner sehen, filtern, kategorisieren und z.B. einen generellen Trend der Kontenentwicklung erkennen etc.

The Road to Raspbian Jessie #2

Weiter geht es mit der Übernahme der Konfiguration der Dienste auf den neuen „Server“. Fangen wir an mit Bitlbee.

Part 3: Bitlbee

Bitlbee ist dabei gleich die größte Herausforderung, denn der Dienst läuft auch mit einem eigenem User, der zusätzlich zu den „normalen“ Daten in /etc gleichzeitig auch Dateien mit eigenen Konfigurationen. Die werden deswegen so verwaltet, weil sich mehrere User an dem Dienst anmelden, ihre Konfiguration direkt von dem Dienst verwalten lassen.

Diese Dateien liegen in /var/lib/bitlbee/ und gehören mit sehr eingeschränkten Userrechten dem bitlbee-Dienstaccount.

D.h. auf dem alten Rechner wechselt man in den Root-Account des Quell-Rechners und kopiert mittels scp oder mc und SFTP-Verbindung in einen temporären Ordner auf dem Zielrechner und von dort dann mit dem Root-Account in das richtige Zielverzeichnis. Rechte setzen mit chmod und chown, fertig.

So sollten die Rechte dann aussehen:

root@raspberrypi:/var/lib/bitlbee# ls -la
total 24
drwx------  2 bitlbee bitlbee 4096 Oct 18 14:49 .
drwxr-xr-x 46 root    root    4096 Oct 18 14:10 ..
-rw-------  1 bitlbee bitlbee  521 Sep 17 18:34 USERNAME.otr_fprints
-rw-------  1 bitlbee bitlbee 3949 Sep  1  2013 USERNAME.otr_keys
-rw-------  1 bitlbee bitlbee 4688 Sep 17 18:34 USERNAME.xml

Part 4: OpenVPN

OpenVPN ist ein bisschen einfacher, installieren und die Daten aus /etc/openvpn rüberkopieren. Rechte anpassen, Dienst neustarten, fertig.

Part 5: Weechat

Weechat wird vom User direkt ausgeführt. Damit reicht es, die Konfiguration aus dem User-Verzeichnis rüberzukopieren.


Nächster Part: Apache / MySQL umziehen. MySQL kann aber auch überflüssig sein. Das schaue ich mir dann in Ruhe nochmal an.

The Road to Raspbian Jessie #1

Nachdem ich an verschiedenen Stellen schon mal las, dass ein direktes Upgrade von Raspian Wheezy auf Raspian Jessie nicht so ohne weiteres funktionieren würde, habe ich beschlossen, eine zweite SD-Karte zu kaufen (genauer: eine MicroSD mit Adapter, man weiss ja nie, ob einem nicht doch noch irgendwann ein Raspberry2 in die Hände fällt) und die Konfigurationen einfach zu kopieren. Glücklicherweise habe ich noch einen zweiten Raspberry zur Hand, dann muss ich auch nicht lange hin- und herstöpseln.

[grey_box]Der Artikel geht davon aus, dass ihr ein bisschen Ahnung im Bereich Linux habt, die Shell schon mal benutzt habt und gängige Befehle wie cd, mkdir und einen Texteditor (nano oder vim) in der Shell benutzen könnt.[/grey_box]

Außerdem tut das ganze gut, mein Gedächtnis wieder ein bisschen aufzufrischen, was ich mit meinem bisher so angestellt habe.

Sachen, die danach auf jeden Fall (wieder) funktionieren müssen: OpenVPN, Bitlbee, Weechat, byobu.

Part 1: Installation des Raspberrys

Man braucht eine SD-Karte, das Tool Win32DiskImager und Internet.

Zuerst wird das Raspian Jessie-Image auf der RaspberryPi-Seite heruntergeladen. Danach wird das Image ausgepackt und mit dem Win32DiskImager auf die SD-Karte gespielt. Ihr könnt auch das NOOBS-Tool nutzen, ist auch kein Problem, aber eigentlich ist das interessanter, wenn man andere Dinge ausprobieren mag.

Für Anfänger ist es vermutlich am einfachsten, den Raspberry via HDMI mit Strom, Keyboard, Maus und Kabel an den Fernseher oder einen Monitor zu hängen.

[green_box]Username und Passwort bei Raspian sind immer wie folgt:

Username: pi
Passwort: raspberry (Vorsicht mit dem Tastaturlayout, das ist in der Standard-Einstellung englisch, also müsst ihr ggf. raspberrz als Passwort eingeben[/green_box]

Erster Schritt nach dem Booten ist, mit STRG+ALT+F1 ins Terminal zu wechseln, sudo raspi-config einzugeben und als erstes das „Expand Filesystem“ zu drücken um das Dateisystem auf die Größe der Karte anzupassen, sonst habt ihr nur knapp 2GB verfügbaren Platz. Ich schalte dann auch gleich noch unter Boot-Mode auf die Option B1, das reduziert den Speicherverbrauch gleich mal ganz gut, weil kein Desktop geladen wird.

Dann passt man am besten auch gleich noch die Tastatur und Länder-Settings an.

Alternativ (hab ich dann leider später erst gesehen): Standardmäßig ist ein SSH-Server aktiv, das Einloggen geht auch direkt remote mit dem bereits erwähnten Usernamen / Passwort.

Part 2: Username anpassen

Ab hier bin ich dann komplett remote vorgegangen.

Ich persönlich mag den Standard-Account nicht, deswegen benenne ich den pi-Account immer um. Nixcraft hat dazu einen sehr guten Überblick dazu. Bis auf die UID-Änderung muss man alle Schritte als root#-User ausführen. Der Hinweis auf die /var und /tmp-Daten in den Kommentaren ist richtig, da tauchte bei mir nur das Verzeichnis /var/lib/lightdm/data/pi auf, das die richtigen Rechte, aber den falschen Namen hatte. Umbennen und gut ist.

Am einfachsten geht das, wenn man seinen SSH-Key in die Datei /root/.ssh/authorized_keys kopiert. Wenn ihr den Raspberry genauso frisch aufgesetzt habt, dann müsst ihr Verzeichnis und Datei erst noch erstellen. Das dann bitte direkt mit dem Root-Account. (Von dem bestehenden pi-Account mit sudo erstellen. Dann mit raspi-config den Bootmodus B1 wählen, rebooten lassen, per Putty einloggen und sich mit root@raspberrypi anmelden (dabei auf SSH-Key-Authentifizierung schalten).

Dann rebooten und voilá: Anmeldung ab jetzt mit den neuen Nutzernamen. Das Passwort kann man dann nicht mehr per raspi-config setzen, da das Tool nur für den User pi eingestellt ist. Dazu nutzt man nach der Anmeldung den Befehl passwd. Das erklärt sich selbst. Wer seine USB-Tastatur dafür nutzt und seine Locale noch nicht angepasst hat: Z und Y sind möglicherweise noch vertauscht.


[green_box]Beim nächsten Mal geht’s dann weiter mit der Übernahme der Konfiguration meiner genutzten Programme und Dienste.[/green_box]

Linux developers are used to being told ‘no’

Linux developers are used to being told ‘no’, then doing it anyway.

OMG! Ubuntu!

Ich kann immer noch nicht verstehen, wieso es Lovefilm & Co. nicht für Linux gibt. Wie man bei Steam und auch bei Android sehen kann, ist „runs on Linux“ nicht gleichbedeutend mit kostenlos. Und wie man auch sehr wohl in beiden Welten sehen kann, auch nicht gleichbedeutend mit der Abwesenheit von DRM.

Android hat das Konzept im Mobile-Sektor mit GPL-Wurzeln umgesetzt. Steam auch. Apple nutzt BSD, was auch eine Open Source Software ist. Im Fall von Apple wird davon im heutigen iOS und OSX vermutlich nicht mehr so viel sichtbar sein, aber sei es drum.

Allerdings: gerade beim Thema Abonnement-Dienste werde ich mir aber nicht wirklich einig  mit der FSF, die der Legitimität dieser Geschäftsmodelle extrem kritisch gegenübersteht. Ich habe keine Probleme mit dem Mieten von Zugang zu Musik oder Filmen. Erst recht nicht, wenn der Zugang mich nicht einschränkt, wie es bei DRM und gekauften Medien der Fall wäre. Denn wenn ich Dinge kaufe, bestehe ich auf Einhaltung des Erschöpfungsgrundsatzes. Und ich will das Produkt ohne Einschränkungen (DRM) nutzen können, konvertieren etc.

Ich bin froh, dass es Menschen gibt, in bestimmten Situationen eben nicht einfach damit abfinden, dass der Erfinder es nicht will. Und es dann einfach trotzdem machen, so dass es so wunderbare Projekte wie „Pipelight“ gibt. Die dann allen nutzen.

[yellow_box]Um das ganze nochmal klarzustellen: Ich befürworte DRM nicht, im Gegenteil. Ich sehe aber die Notwendigkeit, DRM (in welcher Art und Weise auch immer) für Verleihmodelle zu nutzen. Das bringt im Endeffekt auch Nutzern etwas. Und man muss es ja nicht gleich wie bei Systemen wie Origin übertreiben.[/yellow_box]

Mit dem VPN hinter eine Firewall

Ich mag VPNs. Vor allem das P darin. Und wenn man öfter mal in nicht vertrauenswürdigen Netzen unterwegs ist, ist das auch eine tolle Sache. Nun hat sich mein neuer Internet-Provider entschieden, dass ich nur IPv6 „richtig“, aber mit dynamischem Netzpräfix bekomme, IPv4 dafür nur über Carrier-NAT. Wenn ich zuhause sitze und surfe, ist das auch völlig egal. Die Adressumsetzung macht der Provider (so wie es früher meine Fritz!Box getan hat). Das Problem: die meisten DynDNS Provider können auch nach fast 10 Jahren Vorlauf kein IPv6. Und aus einem IPV4-Netz kommt man so einfach nicht an ein IPv6-Only-Netz.

Das Problem

Ich komme nicht mehr an meinen zentralen Messaging-Server, nicht an mein NAS, nicht an meinen Rechner zu hause und wenn ich in fremden (und offenen) WLAN-Netzen unterwegs bin: Keine sichere Verbindung zu nicht-https-Seiten. Und in offenen WLANs mit vielen Gästen traue ich im Zweifel auch nicht mal HTTPS. Da habe ich bisher meinen Raspberry via SSH verwendet.

Erster Anlauf: (auto-)ssh und Reverse Tunnel

Mein erster Ansatz war, einen vServer mit Reverse-Tunnels zu bestücken. Das hat geplappt, war aber insgesamt recht unflexibel und die Verbindung über den Reverse-Tunnel direkt auf den Raspberry war stellenweise einfach zu instabil, so dass keine stabile (direkte) Verbindung in mein Heimnetz (mit Zugriff auf das NAS) möglich war.
Sprich: habe ich vom Raspberry aus via

ssh -R 8080:localhost:22

eine Verbindung erstellt, und dann von (ganz) außen via

ssh vserver -p 8080

darauf zugegriffen, so war die Verbindung in der Regel deutlich instabiler als der Zugriff zum vServer via SSH. Der Zugriff vom vServer auf den Reverse-Tunnel auf den Raspberry war allerdings extrem stabil. Ich bin nicht sicher, ob das Problem nicht bei meinem Putty lag. Allerdings hat das ganze auch Nachteile, wenn es stabil läuft: Ich benutze immer mittels des vServers meinen Raspberry als Proxy. Das ist 1 „Hop“ mehr als notwendig sein sollte. Den vServer als 100Mbit/s-Proxy nutzen und nur den Verkehr ins lokale Netz über den Raspberry routen, das wäre die optimale Lösung. Daher: Ein echtes VPN muss her.

Zweiter Anlauf: OpenVPN, aber mit Anlauf!

OpenVPN. Bewährt, verbreitet, flexibel, unter Linux zuhause. Installation auf Raspian und dem dem Wheezy-vServer: ein einfachen apt-get install openvpn. VPN schön und gut, aber in einem klassischen steht ja der Server ganz oder einbeinig (DMZ) in dem Netz, in welches ich will, bei Unternehmen ist das in der Regel die Firewall, die so etwas anbietet. Astaro/Sophos und Securepoint bieten so etwas z.B. von Haus aus an.

Nun habe ich die Besonderheit, dass mein VPN-Server komplett außerhalb meines Zielnetzes steht, ich aber in das Netz hinter einem bestimmten Client (im Zielnetz) routen will. Die Anleitung „ServerNET zu ClientNET“ hat mich auch schon ein ganzes Stück weitergebracht. Ich konnte vom Raspberry (der Client im lokalen Netz) die VPN-Adresse des Servers pingen, der Server konnte die VPN-Adresse des Raspberrys pingen. Auch vom Server auf die LAN-IP des Raspberrys konnte ich pingen. Aber auf kein anderes Gerät.

Nach viel ausprobieren und gefrage, fand ich dann auf der OpenVPN-Seite die Antwort. Ich bin linuxmäßig bewandeter als in Netzwerktechnik. Ich in davon ausgegangen, dass wie beim NAT der Rückweg einer Verbindung auch bekannt sein sollte. Dem ist nicht so.Ich habe die Route ins 10er (VPN-) Netz dann in der Fritz!Box eingetragen und seitdem geht alles wie es soll. Inklusive Zugriff auf das lokale Netz vom vServer aus.

Nächster Schritt wird dann sein, den Zugriff vom Notebook und Handy soweit hinzubekommen, dass der Verkehr komplett über das VPN und bei Bedarf ins lokale Netz geroutet wird.

The last step, and one that is often forgotten

The last step, and one that is often forgotten, is to add a route to the server’s LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box (you won’t need this if the OpenVPN server box is the gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine (not the OpenVPN server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine, but then it wouldn’t know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24. The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway), make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine.

Similarly, if the client machine running OpenVPN is not also the gateway for the client LAN, then the gateway for the client LAN must have a route which directs all subnets which should be reachable through the VPN to the OpenVPN client machine.

OpenVPN HowTo

In meinem Fall hat die Route in der Fritzbox gefehlt, die Pakete an das 10er VPN über den Raspberry routet, der ja im 192er und dem 10er-Netz sitzt. Nun erreiche ich auch die lokalen Rechner über den VPN-Server.

Herzlich willkommen im Netz der Zukunft?

Eine Geschichte aus dem Internet des Breitband-MKK-Ausbaus mit dem klangvollen Untertitel: „Der Fluch der tanzenden Schildkröte“

Nicht, dass jetzt jemand denkt mein Internet wäre kaputt oder völlig unbrauchbar, das ist es nicht. Ich habe 27MBit/s Downstream und 2,6MBit/s Upstream zuhause. Und ich habe IPv6, bin damit also schon im Netz der Zukunft angekommen. Allerdings stößt mir dabei die eine oder andere Kleinigkeit sauer auf:

  1. Der Provider ist der Meinung, man dürfe / könne nur die von ihm bereitgestellte Fritz!box nutzen. Hatte ich bei Unitymedia auch, allerdings waren hier auch wenig sinnvolle Alternativen möglich.
  2. Für Privatkunden liefert der Provider nur DS-Lite aus. Dual-Stack wäre möglich, wird aber nur für Geschäftskunden gegen Aufpreis angeboten. Damit ist mein bisheriges Konstrukt für einen SOCKS5-Proxy und meine Kommunikationslösung mit Weechat und screen ziemlich für die Füße. Auch das (Open-)VPN nach Hause kann ich vergessen, da die ganzen DynDNS-Provider keine Unterstützung für IPv6
  3. Ein zweiter Telefonanschluss via Sipgate kann nicht eingetragen werden. Die Begründungen aus dem Support-Forum, die im Internet zu finden sind, sind mehr als fadenscheinig.

Insgesamt muss man damit sagen, dass die Bandbreite der Leitung zwar hält, was sie verspricht, aber leider der „Funktionsumfang“ der Leitung und der Fritzbox auf das Minimum beschränkt ist.

Da der Provider auf Nachfrage den Betrieb von Dual Stack verweigert – und das tut er generell für Privatkunden – und ein Wechsel in einen Business-Tarif erhebliche Mehrkosten (zuzüglich einem Extra-Aufschlag für Dual-Stack) bedeuten würde, war die Lösung zwangsweise die Anmietung von „Hardware“.

Zuletzt war mein Raspberry Pi das Gateway in mein Heimnetz. Da ich per IPv4 gar nicht mehr erreichbar bin (CGN sei Dank), habe ich mir bei TLDHost einen günstigen Mini-vServer auf Linux-Basis gemietet.

Mit AutoSSH baue ich mir einen bzw. zwei Tunnel vom Raspberry zum vServer und connecte mich auf diesen. Je nach Anforderung (ob ich z.B. ins Netz zuhause muss), kann ich damit auch meinen Tunnel für einen lokalen Proxy damit auch am vServer enden lassen (mit entsprechend größerer Bandbreite) oder direkt zu Hause auf dem Raspberry, mit Zugriff auf die Infrastruktur.

Das ist zwar praktischer/flexibler als mit DynDNS und (nur) der Leitung zuhause, erzeugt aber zusätzlich zum Regio-Tarif („Provinz-Strafgebühr“) weitere Kosten, die meinen Monatstarif damit insgesamt weiter hochschrauben. So hatten wir (und insbesondere ich) uns das ehrlich gesagt nicht vorgestellt, das mit dem tollen neuen schnellen Internet.

Und was das mit der Schildkröte betrifft: So doll ist die Animation nun auch nicht.