Mosquitto MQTT-Broker im Uberspace installieren

Vorbemerkung

Der ursprüngliche Artikel stammte vom 1. August 2015, etwas weniger als ein Jahr später hat sich die Sache allerdings weiterentwickelt, daher habe ich den Artikel umdatiert und neu veröffentlicht. Das Wichtigste zuerst: Die Sache funktioniert, sauber sicher und stabil. Der ganze nachfolgend erträumte Funktionsumfang ist noch nicht erreicht, aber daran kann man ja noch arbeiten.

Vision

Wir alle bewgen uns viel durch die Welt, häufig nicht alleine. Und Karten sind ein fantastisches Medium, um solche Bewegungen auf einer sphärischen Fläche festzuhalten und darzustellen. Zwei interessante Fragen/Problemstellungen/Aufgaben tauchen dabei häufiger auf:

  1. Wo bin ich überall schon mal gewesen?
  2. Wo bin ich jetzt grade, wohin bin ich unterwegs, wie bewege ich mich fort und wann komme ich an? (Insbesondere, wenn man sich mit jemandem treffen möchte)
  3. (Spielen! Jedes Mal, wenn ich über diesen Komplex nachdenke, drängt sich der Gedanke auf, dass man daraus ein fantastisches (Gelände-/Real-)Spiel basteln könnte, etwas in der Art einer Schnitzeljagd oder Geocaching in Verwandschaft zu Scotland Yard oder Mister X, vielleicht sogar mit Carmen Sandiego. Auch Deutschlandreise oder Globetrotter kommen einem in den Sinn. Große Metropolregionen wie das Ruhrgebiet, in dem ich wohne, bieten sich dafür natürlich an, aber auch im Rahmen einer Jugendfreizeit ließe sich das sicher gut nutzen. Siedler- oder andere Segelspiele haben wir ja schonmal auch ganz offline hinbekommen. Andere haben sowas auch schon gemacht: z.B. auf dem 31C3 und vorher wurde in der Freakshow davon berichtet. Ingress trifft einen ähnlichen Nerv)

Ziel wäre also, die Position von mehreren Leuten zu erfassen, verfolgen, aufzuzeichnen und (auch im Verlauf, also als Spur) darzustellen, eventuell in Beziehung zu setzen mit einander oder anderen Daten (Wetter, Verkehr, ÖPNV), zusätzlich noch Ziel/Zwischenziele, Route, Verkehrsmittel, Voraussichtliche Ankunftszeit, passende Wikipedia-Artikel etc.
Das würde erstmal die Grundanforderungen abdecken, sich mit anderen Menschen besser absprechen zu können und auch im Nachhinein sehen zu können, wo man war.
Wenn es dann noch zusätzlich Berechtigungs-Einschränkungen gäbe (alle senden ihre Position, aber nicht jeder kann immer die Positionen aller anderen einsehen), käme man der Spiel-Nutzung näher.

Möglichkeiten

Es gab mal einen Dienst namens Google Latitude, der ungefähr in die Richtung ging, er ist mittlerweile in Google+/Maps (Timeline) aufgegangen, in Facebook, FourSquare/Swarm, Apples Find My Friends oder waze finden sich ähnliche Ansätze. Sehr nah an meine Vorstellung der Umsetzung kommt Glympse, gegenüber den anderen genannten Diensten benötigt man zum Angucken kein Konto und die Freigabe ist zeitlich beschränkt.

Aber einen Nachteil haben sie alle: Sie sind ein großer Eingriff in die Privatsphäre, man gibt Kontrolle ab, man muss (überwiegend sehr großen) Firmen trauen, die im Ausland und damit anderen Jurisdiktionen sitzen, von denen man abhängig und denen man ausgeliefert ist. Kurz: Sie sind nicht  offen, noch frei.

Also sind sie keine echte Option. Ein paar gäbe es da aber schon schon: OsMo/OsmAnd, Userhash Location Reporting, Gps Cell Phone Tracker, Trackserver. Es gibt auch eine schöne Übersicht von Diensten mit Vergleich. So recht schien mir aber keins davon zu passen. Zwischenzeitlich trug ich mich mit dem Gedanken, selbst was auf reiner Browser/Javascript-Basis zu entwickeln, was eventuell mit einem NodeJS-Server spricht: Sehr viel Aufwand, aber wäre ein Anlass zum Lernen.

Ansatz

Doch in dem Vergleich wird OwnTracks erwähnt (nicht zu verwechseln mit owntrack, dessen Idee ähnlich, Umsetzung aber nicht so nachhaltig zu sein scheint), dazu gibt es auch einen Artikel bei Cashy und einen von nullniveau. (Und noch ein paar hier und dort). Das scheint mir eine Lösung voll nach meinem Geschmack. OwnTracks selbst ist eine OpenSource-App (sowohl für iOS als auch für Android), die die Position ermittelt und per MQTT (Message Queue Telemetry Transport), einem offenen Publish-/Subscribe-Protokoll für die dezentrale Übermittlung kleiner Nachrichten wie Sensor-Messdaten über Verbindungen, die auch schonmal aussetzen können, verteilt. Passt also sehr gut, hat auch den aparten Vorteil, dass die Server-Seite unabhängig von dem Geo-Thema ist und in der Heimautomatisierungsszene (s. openHAB) Zuspruch findet, man ist also da nicht allzusehr in der Nische und läuft Gefahr, dass man sich übernimmt oder die Weiterentwicklung eingestellt wird. Es gibt einen Open Source-MQTT Message Broker (=Server) namens Mosquitto, der auch von den OwnTracks-Machern unterstützt und empfohlen wird.

Einziger Wermutstropfen: OwnTracks ist zwar OpenSource, aber (noch) nicht im F-Droid-Repository zu finden, da es auf die proprietären Google Play Services zur Ortung zurückgreift. Kein Problem, das man nicht lösen könnte! 😉 (Allerdings ist die dafür notwendige Implementierung von Geofencing in LOST zur Zeit eingeschlafen.)

Die OwnTracks-App sendet und empfängt die Positionen und zeigt sie auf einer Karte an.
Der MQTT-Broker verteilt nur die Positions-Nachrichten aber zeichnet sie nicht auf, dazu gibt es mittlerweile ot-recorder (zuvor gab es schon das m2s-Backend bzw. auch mit Darstellung im Web den Nachfolger Pista. Um die Vision zu Erreichen, wäre außerdem der Einbau einer Authentifikation noch wichtig.

Mosquitto möchte ich gerne nicht auf einem Raspberry Pi installieren wie in der OwnTracks-Doku und allen anderen Anleitungen, die ich finden konnte, sondern in meinem Uberspace. Denn ich möchte die Position ja von Unterwegs aufzeichnen und einsehen, und ich möchte mein Netzwerk zuhause nicht nach Außen aufmachen. Das ist insofern problematisch, als die Anleitungen alle vom praktischen Weg „sudo apt-get“ ausgehen, der im uberspace logischerweise nicht funktioniert (keine sudo-Berechtigung). Also bleibt nur die andere Möglichkeit: Selbst kompilieren.

Umsetzung

Genug der langen Vorrede, werden wir etwas konkreter und kommen zur Umsetzung: Den Mosquitto-Broker im Uberspace kompilieren und starten.

Eine der Anleitungen beinhaltet das Kompilieren, aber als root, von der bin ich ausgegangen und habe sie dann ein wenig angepasst, um der User-Umgebung Rechnung zu tragen. Außerdem werden jetzt in der zweiten Version des Artikels direkt von Anfang an Websockets mit aktiviert und in der Konfiguration TLS verwendet.

Los geht’s:

Websockets

Geholfen haben mir zwei Artikel.

libwebsockets 1.6 ist die letzte explizit von mosquitto erwähnte Version und danach haben sich ABI-Changes ereignet, also nehmen wir die und kompilieren/installieren sie:

Damit wird heruntergeladen, ausgepackt, das buildscript erzeugt und dann ausgeführt. Danach liegen in lib/  die nötigen libraries, die man nach ~/lib  kopieren kann:

Jetzt geht es weiter mit  mosquitto selbst.

Mosquitto

Nun muss die config.mk angepasst werden, um die Websockets-Bibliothek erreichbar zu machen und zu linken

Also Folgendes jeweils an den richtigen Stellen in der Datei ändern:

Dann ändern, speichern und verlassen.

Es werden außerdem noch zwei header-Dateien gebraucht:

Weiter mit

Dabei passiert folgendes: Die Dateien werden kompiliert und unter $HOME/ in  entsprechenden Verzeichnissen (~/bin, ~/include, ~/lib, ~/sbin, ~/share) abgelegt, aber am Ende des Kompilierens erscheint der Fehler

Man kann auch erkennen warum: Die Dateien, die eigentlich in /etc/mosquitto landen sollen, berücksichtigen aus unerklärlichen Gründen den Prefix nicht, und auf das systemweite /etc-Verzeichnis haben wir natürlich keinen Zugriff. Ist aber auch nicht weiter schlimm, wir legen einfach eine eigene Konfigurationsdatei an, sie wird gleich editiert:

TLS

Doch zunächst müssen noch einige Vorbereitungen bezüglich des TLS getroffen werden. Der Server soll unter einer eigenen Domain erreichbar sein und es soll ein Zertifikat von Let’s Encrypt zum Einsatz kommen, das passt gut in die Uberspace-Architektur und wird auf den Mobilgeräten automatisch akzeptiert. Alternativ, insbesondere wenn man keine Domain hat oder dafür nur die normale Uberspace-Domain ($USER.$SERVER.uberspace.de) benutzen möchte, wäre es auch möglich, das Zertifikat selbst zu generieren/signieren (Weiteres dazu unter http://owntracks.org/booklet/features/tls/ und http://mosquitto.org/man/mosquitto-tls-7.html) und das dazu passende CA-Zertifikat auf den Geräten in das System zu importieren oder in der App anzugeben. Das macht die Einrichtung aber unnötig kompliziert und hat z.B. bei Android als Nebeneffekt zur Folge, dass die Bildschirmsperre mindestens per Muster deaktiviert werden muss (was ohnehin eine gute Sache wäre).

Nun also –  Im virtuellen User-Webroot wird ein Verzeichnis als Platzhalter angelegt:

Es ist sinnvoll, hier eine eigene, sonst nicht benutzte Subdomain zu vergeben, (der Name muss natürlich entsprechend angepasst werden) um das Let’s Encrypt-Zertifikat separat zu verwalten.

Die (Sub-)Domain muss dann im DNS angelegt werden, z.B. bei INWX, was ich nur empfehlen kann. Im Wiki von Uberspace gibt es noch genauere Informationen.

Es muss sichergestellt sein, dass die Server von Let’s Encrypt unter der Domain auch wirklich den Uberspace-Server erreichen, also am besten nochmal von außen probieren, z.B. eine Test-Datei aus dem Platzhalter-Verzeichnis herunterzuladen.

Wenn Let’s Encrypt bisher noch nicht im Einsatz war ist es an der Zeit (den Uberspace-Wiki-Eintrag zu lesen und dann) für

Jetzt, oder falls Let’s Encrypt schon im Einsatz war findet sich unter ~/config/letsencrypt/cli.ini eine Konfigurationsdatei, in der alle Domains eingetragen sind. Die wird nun kopiert, bearbeitet (also alle Domains außer der für Mosquitto entfernt) und zum Erzeugen der Zertifikate benutzt:

Die Zertifikate werden nun für mosquitto kopiert. Im Prinzip könnten sie auch aus dem .config-Ordner heraus verwendet werden, aber so hat man alles zusammen. Geschmackssache:

Konfiguration

Es sind zwei offene Ports in der Firewall nötig, die bekommt man durch doppeltes Aufrufen von

Die dabei ausgegebenen Ports merken und gleich benutzen, denn jetzt geht es an’s Einstellen in der vorhin angelegten Konfigurations-Datei. Eine Hilfe dabei war ein Artikel:

Hier im Beispiel ist der normale MQTT-Port (Standard 1833/8883) auf 61883 und zusätzlich ein Websockets-Port (Standard 9002) auf 61884 konfiguriert, beide geschützt mit TLS. Aufgelistet sind hier alle Änderungen im Verhältnis zur Standard-Konfiguration. Die müssen in der Datei jeweils an den entsprechenden Stellen vorgenommen werden. Also nicht einfach alles reinkopieren. Außerdem müssen die $HOME-Variablen manuell aufgelöst werden, also stattdessen direkt/home/username hinschreiben.

Starten und Testen

Es kann fast losgehen, dazu müssen wir aber noch das Verzeichnis, in dem die frisch kompilierte Mosquitto-Bibliothek liegt, in den LD_LIBRARY_PATH aufnehmen, damit beim Ausführen des Binarys gleich auch darin nach ihr gesucht wird:

$HOME/lib/ wird an den bisherigen Pfad angehängt und dann wieder in der Umgebungsvariablen gespeichert (der Doppelpunkt ist das Trennzeichen), danach wird sie ausgegeben. Damit das fortan automatisch beim Einloggen geschieht, ergänzen wir die erste Zeile in der .bashrc:

Und jetzt braucht man vier Konsolen-Fenster:

1. Der Broker. Hier sollten zum Start ein paar Meldungen erscheinen:

2. Das Log. Auch hier sollten bei den folgenden Aufrufen einige Meldungen erscheinen:

3. Der Subscribe-Client. Er sollte beim nächsten Aufruf die gesendete Nachricht anzeigen:

4. Der Publish-Client:

Ein  uberspace-list-ports -l  zeigt außerdem die jetzt offenen Ports mit dem horchenden Mosquitto-Server:

Als nächsten Schritt kann man jetzt die OwnTracks-App mit dem Broker verbinden. Das sollte sich ebenfalls in den Logs und im Subscribe-Client niederschlagen, außerdem müsste in Luxembug ein User angezeigt werden.

Die Websocket-Verbindung kann man direkt hier testen: http://www.eclipse.org/paho/clients/js/utility/index.html
Oder einen dieser MQTT-Websocket-Clients klonen und konfigurieren:
https://github.com/eclipse/paho.mqtt.javascript.git
https://github.com/jpmens/simple-mqtt-websocket-example
https://github.com/owntracks/contrib

Daemontools

Zur besseren Kontrolle des Brokers übergibt man ihn in die Obhut der  deamontools (die zum Testen gestartete Instanz in der „1. Konsole“ muss natürlich vorher per Strg+C beendet werden):

In dieses Skript kommt nun (den Usernamen ersetzen):

Zum Abschluss wird das Skript ausführbar gemacht, aktiviert und der Daemon gestartet:

Ein abschließendes

sollte nun den Mosquitto-Superviser und den eigentlichen Broker zeigen.

Das war’s, alles geht! 🙂

Achtung, mit dieser Konfiguration gestattet der Broker alle Verbindungen und Subscriptions! Eine ACL würde Abhilfe schaffen…

Bliebe noch,  den ot-recorder und ein Authentifikations-Backend einzurichten. Mal schauen, wann das kommt…

Ein eigenes Android-App-Repsitory (F-Droid) auf dem Uberspace

Vorbemerkungen

Ein Android-Smartphone ist erst mit zusätzlichen Apps so wirklich nützlich. Wenn auf dem Gerät ein Cyanogenmod (oder ein anderes Betriebssystem ohne die Google-Apps wie den Play Store) läuft und man aus Prinzip keine Abhängigkeit zu Google schaffen möchte, dann muss man sich eine andere App-Quelle suchen. Amazon (oder ähnliche) ist da auch keine echte Alternative. Die gibt es allerdings in F-Droid. Das Projekt betreibt nicht nur einen eigenen Katalog von Apps (nur Open Source, keine Anmeldung nötig) und stellt den dazugehörigen Client bereit, sondern ebenfalls die Server-Software. Im Client kann man außer dem Standard-Repository auch weitere hinzufügen, z.B. Öffi oder GuardianProject. Oder eben sein eigenes wenn man eins hat. Darum, sein eigenes F-Droid-Repository aufzusetzen, und zwar bei uberspace, soll es in diesem Eintrag gehen.

Doch warum sollte man das tun wollen? Im „offiziellen“ F-Droid-Repository gibt es doch schon alle möglichen Apps? Eine schöne Zusammenstellung der „besten“ Apps findet man z.B. bei Droid-Break:

  1. Manche Apps sind leider nicht Open Source und daher auch nicht bei F-Droid zu finden (z.B. QuickPic, die Uni-App, die Olympus-Kamera-App etc.). Man kann sie z.B. über einen App-Downloader auch ohne Google-Konto herunterladen (in der letzten Zeit klappt es nicht mehr richtig), aber der noch etwas bessere Weg könnte ein Kommandozeilen-Play-Store-Client, evtl. auch zusammen mit Weboberfläche sein. Das könnten der 3. und 4. Schritt werden…
  2. Wenn man Android-Apps selbst entwickelt oder vorhandene verändert/erweitert kann es helfen, diese als Entwickler-Versionen per Repository auch an mehrere Leute/Geräte verteilen zu können, bevor sie es in den offiziellen Store schaffen. Konsequenterweise würde man evtl. sogar alle Apps lieber selbst automatisch und regelmäßig aus dem aktuellen Quellcode kompilieren, dazu wäre eine Art Build- oder Continuous Integration-Server wie Jenkins praktisch (Schritt 2).

Zunächst mal ist das Ziel (der 1. Schritt) aber ein „einfaches“, sogenanntes „Simple Binary Repository“, das einfach vorkompilierte (z.B. auf dem Entwicklungs-Laptop) .apk-App-Dateien verteilt.

Man könnte auf den Gedanken kommen, soetwas einfach im heimischen Netzwerk auf einem Raspberry einzurichten. Leider geht das aber nicht, da im Raspberry ein ARM-Prozessor läuft und es das Android-SDK aus irgendwelchen skurrilen Gründen nicht für ARM gibt. Skurril deshalb, weil immerhin die meisten Smartphones selber einen ARM-Prozessor haben. Apps muss man daher auf einer x86-Plattform Cross-compilen. Das Android-SDK wiederum braucht der F-Droid-Server, um die Meta-Daten aus den APK-Dateien auszulesen und im Repository bereitzustellen.

Zunächst noch zum Setup: Das Paket „fdroidserver“ ist hauptsächlich in Python geschrieben und nutzt das Java-SDK (JRE reicht nicht) und das Android-SDK als Abhängigkeiten.

Die Python-Skripte generieren die notwendigen Ordner- und Datei-Strukturen, die dann aus dem normalen Webroot eines üblichen Web-Servers wie NGinx (oder, im Falle von uberspace) Apache ausgeliefert werden.

Die anderen Anleitungen zum Einrichten des Servers gehen (wie so häufig) von root-Rechten auf dem Server aus, die hat man aber bei uberspace natürlich nicht zur Verfügung. Ein „apt install fdroidserver“ klappt also nicht, man muss ein paar Anpassungen vornehmen.

Die Dokus, die mich auf dem bisherigen Weg begleitet haben, gibt es hier:

Leider sind die nicht alle ganz konsistent, widersperchen sich ein wenig oder ergänzen jeweils nur einige kleine Hinweise. Ich habe auch auf den „virtualenv„-Aspekt verzichtet, weil er mich beim Testen eher verwirrt hat und ich keinen schlagenden Vorteil sehe.

Nun also per Hand, von Anfang an:

Ein Arbeitsverzeichnis anlegen und dahin wechseln:

Java

Das Java-SDK ist bei Uberspace nicht installiert, für diesen Anwendungsfall (Entwicklungsumgebung und Laufzeitumgebung für kleine Kommandozeilenprogramme) kann man es aber – auf eigene Quota – nachziehen.

Die Methode (Oracle macht es etwas umständlich) hat sich zwischenzeitlich schon wieder ein wenig verändert und man muss bei Oracle auf der Website zuvor die aktuelle Version nachschauen (Dateiname anpassen) :

Für das OpenJDK scheint es leider keinen offiziellen Tarball zu geben, sondern nur fertige Plattform-Pakete (wiesu denn blus?), die man per Paket-Verwaltung installieren müsste.

(Nebenbei: Die Uberspace-Server haben – kaum überraschend – Prozessor und Kernel mit 64 Bit Wortbreite, das kann man auch auf der Kommandozeile herausfinden)

Android

Auf der offiziellen Website ganz unten den Pfad zum aktuellen SDK besorgen und herunterladen (Version anpassen):

Jetzt müssen ein paar Umgebungsvariablen angepasst werden:

und folgende Zeilen einfügen:

Nach dem Speichern (Strg+O, Strg+X) die Variablenänderungen neu einlesen mittels

dann mit Hilfe des SDK Managers die zusätzlichen Tools und Plattformen herunterladen:

Dort die Nummern merken für die SDK Tools, die Platform-tools, die Build-tools (jeweils nur die höchste Version/Revision, abgesehen von RCs) und die SDK Platforms API 20 und 22 und diese dann an den folgenden Filter-Parameter übergeben:

(etwas mehr Information dazu und noch vertiefende Anmerkungen)

64 Bit Build-Tools

Jetzt kommt der große Trick an diesem Setup: Zu diesem Zeitpunkt würde ein

im Repository-Verzeichnis (s.u.) zum Scheitern führen:

Das Programm aapt liegt zwar am angegebenen Ort, gibt aber bei direktem Aufrufen folgende Rückgabe:

Das liegt wohl daran, dass es für dieses Programm keine (offizielle) 64-Bit-Version gibt. ?!?! 32 Bit ist schon seit einer gefühlten Ewigkeit obsolet (um mal die Jungs von Uberspace zu zitieren), aber die entsprechende Issue bei Android/Google steht auf „WorkingAsIntended“. Hier ist also wenig schnelle Abhilfe zu erwarten.

Theoretisch könnte man zwar Kompatibilitäts-Bibliotheken (mit Dropdown oben rechts zu Linux wechseln) auf dem Server installieren:

Aber auch mit Hundeblick ließen sich die Uberspace-Admins nicht ausnahmsweise erweichen. Was ich verstehen kann, denn man möchte sich sein Setup ja nicht mit altem Kram zukleistern, „der einen riesigen Ratenschwanz an Abhängigkeiten mit sich bringt“ (erneutes Support-Zitat). Naja, ’n Versuch war’s wert aber Prinzipien sind gut und müssen sein! 🙂

Außerdem erhöht das den Leidensdruck auf den User, die Sache doch noch irgendwie anders hinzubekommen. Da war doch beim Suchen irgendwo ein Link aufgetaucht…?

Ja! Tatsächlich gibt es ein Github-Repository, in dem sich jemand die Mühe gemacht hat, die Original Android-Build Tools so vorzubereiten, dass sie auf einem 64 Bit-System kompilieren. Welche Arbeit und Veränderungen genau das bedeutet hat, ist zwar nicht direkt ersichtlich, und die Grundlage sind die Android 4.1.2-Quellen, aber das sollte doch eigentlich keine Rolle spielen. Also los (wir befinden uns weiterhin in ~/projekte/android/):

Jetzt braucht es einen kleinen Moment, bis alles fertig kompiliert ist. Danach liegt das fertige 64 Bit-aapt in seinem Ordner. Kurzer Test:

spuckt keine Fehlermeldung, sondern den Hilfetext aus. Juhu!

Dann packen wir es mal in das SDK-Verzeichnis:

F-Droid Server

Und nun endlich auf zum Endspurt:

Dabei wird das offizielle Git-Repository geklont und mit dem Python-Paketmanager pip in Version 3 die Abhängigkeiten aufgelöst/heruntergeladen. Wichtig ist der –user-Schalter damit nicht versucht wird, die Pakete im schreibgeschützten globalen Pfad abzulegen. Nach ein bisschen warten und in der Konsolenausgabe sollte am Ende sowas stehen wie

Also weiter mit

das endet nach etwas Arbeiten und Ausgabe zwar mit

aber wer braucht schon Doku? 🙂 Offenbar beachtet hier leider das Install-Script nicht die --user -Option.

Legen wir nun im virtuellen WebRoot ein Verzeichnis „fdroid“ (eine Konvention) an, begeben uns dorthin und initialisieren ein F-Droid-Repository:

Es gibt zwar wieder einmal eine Fehlermeldung

aber das Wesentliche wurde erledigt, wie $ ls -lah  zeigt. Und den Fehler und seine Auswirkungen beheben wir gleich.

Repository

Jetzt legen wir zum Testen eine vorhandene .apk-Datei in das Repository

Dann muss eine kleine Anpassung an der config.py vorgenommen werden, damit F-Droid das JDK findet. Diese Stelle hat mich am meisten Zeit und Nerven gekostet, weil sie gut versteckt und mäßig dokumentiert ist. Macht man es nicht, bekommt man

Also weiter:

Hier müssen oben einige Zeilen einkommentiert und verändert werden (achtet auf die richtige Zahl, nicht ‚1.8‘, das ist eine fiese Falle)

Einbiegen auf die Zielgerade, das Repository erzeugen/aktualisieren:

sagt uns leider noch

Da ist ja der Fehler von vorhin, aber da das Repository nun fertig konfiguriert ist und das JDK findet, funktioniert die vorgeschlagene Abhilfe:

es wird ein neuer Signing Key und ein passendes Zertifikat erzeugt. Das sind Sachen, die man in Zukunft ruhig nochmal anpassen könnte, aber für’s Erste geht das schon in Ordnung. Der zweite Versuch mit

bringt uns

Das war’s! Es funktioniert. Auf dem Smartphone muss jetzt in F-Droid unter „Paketquellen“ eine neue Quelle eingerichtet werden. Als Adresse gibt man

https://$USER.$SERVER.uberspace.de/fdroid/repo

ein, aktiviert es, deaktiviert alle anderen und aktualisiert einmal die Quellen. Dann taucht es in der Liste als „My First F-Droid-Repo Demo“ auf und in der App-Liste wird die eine App (im Beispiel AntennaPod) aufgeführt.

Screenshot_20160422-132354 Screenshot_20160422-135023

Nutzung

Die Nutzung wird nun darin bestehen, fertige .apk-Dateien unter

abzulegen und dann in

das Kommando

aufzurufen.

Weitere Konfiguration

In der Datei

sind jetzt noch einige Konfigurationsoptionen, an denen man schrauben kann, die Sache mit den Keys sollte man sich durchaus nochmal anschauen (die Apps werden neu mit einem einheitlichen Repository-Key signiert) und auch das metadata/ -Verzeichnis bietet Ansatz-Punkte.

Dazu bietet es sich an, die oben verlinkten Artikel/Handbücher zu studieren, aber das ist ab jetzt dann nur noch „Standard“. Wahrscheinlich ist es auch nicht verkehrt, von Zeit zu Zeit ein Update der fdroidserver-Skripte, des Java- und des Android-SDK zu machen.

Viel Spaß mit euren eigenen F-Droid-Repositories und der neu gewonnenen Unabhängigkeit! Sollte dies hier jemandem genützt haben, freue ich mich sehr über einen Kommentar.

Ziemlich staubig hier

Vor etwa anderthalb Jahren habe ich dieses Blog aufgesetzt. Seitdem ist unfassbar viel passiert, in der Welt, in meiner Umwelt, in mir.

Ständig habe ich mir in der Zwischenzeit vorgenommen, endlich zu schreiben, habe dazu angehoben, Entwürfe angelegt, Notizen gemacht, nachgegrübelt. Dabei scheitert man ein wenig an seinen Ansprüchen: Alles soll direkt perfekt sein, ausgearbeitet, schlüssig, überzeugend, nicht angreifbar und nicht zuletzt komplett. Das ist natürlich Blödsinn, so funktionert es nicht. Einfach mal anfangen ist jetzt der Weg, den ich gehen möchte.

Ich hoffe so wenigstens alle 2-3 Wochen einen Artikel zu schreiben. Euch bitte ich um Kommentare und Kritik und bin gespannt auf eure Meinung.

Perfekt wird es nicht sein, ich plane eher, die Artikel ab und zu auch mal zu überarbeiten

Also: Los jetzt

Digitale Emanzipation

Emanzipation ist laut Wikipedia ein Akt der Selbstbefreiung mit dem Ziel, mehr Freiheit und Gleichheit zu erlangen. Das kann man in vielerlei Hinsicht erreichen und charakterisieren. Ich befasse mich in diesem Artikel mit der „digitalen“ weil die Welt, in der wir leben, nun mal immer mehr von Systemen durchdrungen und bestimmt wird, die von Computern gesteuert werden. Computer, also Rechner, übernehmen das Berechnen, wo man es früher mit den Fingern getan hat (lat. digitus: der Finger), im englischen heißt eine Ziffer „digit“. Einerseits geht es hier also um digitale Emanzipation, weil wir in einer digitalen Welt leben. Zweitens um eine Befreiung vom digitalen Umfeld, in das wir uns verstrickt haben. Und drittens um die Wiedererlangung von Gleichheit unter den Menschen.

Uiui, was? Naja, fangen wir mal klein an.

Ich habe eine Vorstellung davon, einen Wunsch, Traum oder Vision, wie und wohin sich die Erde und die Menschheit darauf entwickeln sollte. Allein kann ich das nicht erreichen. Aber ich kann dazu mit meinem Verhalten beitragen, und meine Überlegungen dazu mit anderen Menschen teilen, in der Hoffnung, dass  Sie darüber nachdenken, mit mir diskutieren, und wir eine gemeinsame Vision und einen gemeinsamen Weg entwickeln, dorthin zu gelangen.

So ein Weg ist lang und schwer, und es hilft, wenn man andere hat, die sich auf dem gleichen Weg befinden, damit man sich gegenseitig austauschen und unterstützen kann. Man kann ihn nicht an einem Tag mit einem riesen Sprung bewältigen, sondern nur durch viele kleine Schritte.

So weit die Allgemeinplätze. Wie geht’s los? Diese vielen kleinen Schritte möchte ich, während ich sie selbst gehe, hier erzählen, um euch dazu einzuladen, darüber mit mir zu diskutieren und sie selbst zu gehen. Einen kleinen Vorsprung habe ich schon, aber ihr könnt schnell aufholen.

Einige von den Schritten bringen Kosten (also Geld), Arbeitsaufwand (also Zeit), oder Veränderungen in dem Leben, wie man es bisher gewohnt war (also Qualität), mit sich. Übellaunige Zeitgenossen könnten das „Einschränkungen“ nennen.

Doch nicht alles sind technische Vorkehrungen, die man trifft, vieles auch einfach bewusstes Nachdenken oder geändertes Verhalten. Hier geht es jetzt erstmal um das technische. Die einzelnen Punkte möchte ich demnächst noch teilweise mit eigenen Artikeln genauer erläutern.

Was also sind die Schritte? Woll’n mal sehen:

  • Eine andere Suchmachsine – Finden ohne gefunden zu werden
    Kosten: Keine, Aufwand: Gering, Veränderungen: Gering.
    Die Google-Such ist das allumfassende und beherrschende Werkzeug, um im Internet Dinge zu finden. Doch speichert Google bei der Nutzung auch Informationen über euch. Warum also nicht einfach mal eine Alternative ausprobieren? Empfehlung: startpage.com zur Suche nach deutschsprachigen Inhalten, DuckDuckGo bei englischsprachigen nutzen und direkt oben im Browser-Suchfeld einstellen
  • Ein gutes Webhosting mit eigener Domain – Grundlage für vieles Weitere.
    Kosten: 1,50€ im Monat, Aufwand: Gering, Veränderungen: Keine.
    Hier geht es darum, sich einen Brückenkopf im Internet zu schaffen. Einen sicheren Hafen, dem man vertrauen und auf den man sich verlassen kann, der Anlaufpunkt von Außen (also für andere als man selbst) und Ausgangspunkt von innen (also für einen selbst) ist. Meine Empfehlung: Ein uberspace.
  • Selbst verwaltete E-Mail-Adressen – Weg von GMX, Google, Yahoo und den anderen. Kosten: Keine, Aufwand: Gering, Veränderungen: Gering.
    E-Mail ist das wichtigste und beste Kommunikationsmedium. Hierüber laufen nicht nur Newsletter, persönliche Nachrichten oder andere Dinge, die mancher vielleicht „unwichtig“ nennen würde. Es ist auch der Kanal für wichtige Dokumente, die Daten enthalten, die die Privatsphäre berühren und vor allem Passwörter: Wer Kontrolle über das Mail-Konto hat, kann in kürzester Zeit auch auf alle anderen Konten zugreifen, die Identität übernehmen und großen persönlichen und finanziellen Schaden verursachen. Meine Empfehlung: uberspace.
  • RSS-Feeds lesen – Den „richtigen“ Nachrichtenfluss sicherstellen.
    Kosten: Keine, Aufwand: Gering, Veränderungen: Keine.
    Nur aufgrund von Informationen können wir Entscheidungen treffen und uns Meinungen bilden. Also sollten wir auch sicherstellen, dass wir die Nachrichten lesen, die uns interessieren und nicht auf die beschränkt sind, die andere uns lesen lassen möchten.
  • Podcasts hören – In die Tiefe gehen.
    Kosten: Keine, Aufwand: Gering, Veränderungen: Keine.
    Ähnlich wie beim Lesen von Feeds geht es auch hier darum, an Informationen das zu empfangen, was einen selbst interessiert und betrifft. Podcasts können da häufig sehr umfangreich sein und in die Tiefe gehen. Und sie eignen sich besonders für Zeiträume, in denen man zwar beschäftigt ist (nicht lesen kann), aber zuhören kann, z.B. beim Bahn-fahren oder bei der Hausarbeit.
  • Ein freies Betriebssystem auf dem Mobilgerät – Vertrauenswürdige Grundlage
    Kosten: Keine, Aufwand: Mittel, Veränderungen: Mittel.
    Das Leben ohne Handy oder „Smartphone“ ist heute kaum noch denkbar. Es hat zwei Kameras, mehrere Mikrophone, GPS-Ortung, Sensoren für Ausrichtung und Beschleunigung, ist die Plattform für all unsere Kommunikation, ist ständig an und im Netz und wir haben es immer und überall dabei – eine optimale Überwachungswanze. Im Laden gekauft enthält es außer dem „rohen“ Betriebssystem noch sehr viel zusätzliche Software von Betriebssystem-Hersteller, Hardware-Hersteller, Netzbetreiber und Werbe/Vertragspartnern. Das sind sehr viele Akteure, denen man vertrauen muss, dass sie mit dem Handy nicht machen, was sie wollen. Es gibt hier keine perfekte Lösung, aber man kann die Situation zumindest verbessern. Ich empfehle Android Cyanogenmod.
  • Ein freies Betriebssystems auf dem eigenen Rechner – Vertrauenswürdige Grundlage
    Kosten: Keine, Aufwand: Mittel, Veränderungen: Mittel.
    Ganz ähnlich verhält es sich eigentlich auch mit dem (zumindest einstigen) „Hauptrechner“, Stand-PC oder Laptop. Die Empfehlung hier: Linux Mint
  • Überblick über seine eigenen BewgungenWissen und zeigen, wo man war
    Kosten: Keine, Aufwand: Mittel, Veränderungen: Gering.
    Hierbei geht es weniger um Veränderungen. Die meisten von euch werden sich über das Thema bislang wenig gedanken gemacht haben. Es geht eher um Fortentwicklung und Verbesserung. Google hatte mal einen Dienst namens „Latitude“, mit dem man seinen Standort an andere weitergeben konnte, das ist ein Aspekt, ein anderer ist Darstellung von Daten und Werten, die einen betreffen und ein dritter die Erzeugung von Karten, dia als Werkzeug für etwas dienen können.
    Meine Empfehlung: uMap selbst installieren und betreiben.

Ein Wort zu Apple, Google, Facebook, Microsoft, Dropbox

Bei einigen der oben angeführten Punkte ist man leicht versucht zu sagen: „Warum der Aufwand? Geht doch auch jetzt schon super!“, etwa bei E-mails oder Handys. Wenn „jetzt schon“ bedeutet, dass man sich Apple mit einem iPhone ausliefert, Google News als Informationsquelle betrachtet oder sich auf ein Microsoft Windows als Betriebssystem verlässt, dann bin ich da kein Freund von. Man vertraut damit, meist unbewusst, großen und mächtigen Konzernen. Teilweise zahlt man diesen Konzernen nicht mal etwas dafür. Die sind aber (nur!) ihren Aktionären verpflichtet, der Dividende, also ist man nicht der Kunde, sondern die Ware. Darüber hinaus kann man an der Gesetzeslage und Rechtsprechung ihrer Herkunftsländer durchaus seine Zweifel haben, die letzten Jahre haben uns dies gezeigt.

Und da ist man wieder bei der Unabhängigkeit und Freiheit, der eingangs erwähnten Emanzipation.

Das soll für den Anfang genügen. Ein paar weitere wichtige, aber eher fortgeschrittene Punkte, hier in Kürze, ich hoffe sie in Zukunft noch zu erweitern:

  • Eigenes SSL-Zertifikat
  • E-Mail-Verschlüsselung
  • Owncloud statt Dropbox
  • Freier Browser + Plugins
  • Raspberry Pi oder anderen Einplatinencomputer
  • Der Konzern Google (Nest, Maps, Boston Dynamics, Android, Gmail)
  • Friendica, StatusNet und pump.io
  • XMPP/Jabber
Karte

Geodaten speichern und darstellen mit uMap

Ziel der ganzen Sache ist, verschiedene Karten, die mit meinem Leben zu tun haben oder die Daten visualisieren, die mich interessieren, zu speichern, sammeln und darzustellen, z.B. Urlaube, CVJM-Freizeiten, Energieinfrastruktur in Deutschland, besuchte Orte, gereiste und mitgetrackte Routen usw.

Dazu will ich uMap benutzen, eine OpenSource-Software, die Django (mit dem GeoDjango-Modul) und Leaflet nutzt und auf django-leaflet-storage und Leaflet.Storage aufbaut. Im Hintergrund soll eine PostgreSQL-Datenbank mit der Erweiterung PostGIS dienen, dazu werden noch die Bibliotheken GEOS und PROJ.4 benötigt.

Bei meinem Hoster uberspace gibt es Anleitungen für PostgreSQL und Django (Python).

Bisher ist leider noch nicht alles geschafft, bisher funktioniert

  • Python/Django
  • PostgreSQL
  • GEOS
  • PROJ.4
  • gdal
  • PostGIS

Es fehlen

  • django-leaflet-storage
  • uMap

Was bisher geschah:

Python

PostgreSQL

GEOS

in $HOME/python/

PROJ.4

gdal

PostGIS

Weitere Vorbereitungen

 

Jetzt muss in der Datei $HOME/service/postgresql/run an der Variablen LD_LIBRARY_PATH vorne der Pfad $HOME/lib/: angefügt werden:

PostgreSQL neustarten:

django-leaflet-storage

 

uMap

pip install virtualenv

https://wiki.uberspace.de/development:python

https://bitbucket.org/yohanboniface/umap/wiki/Home

pip install virtualenvwrapper

in ~/.bash_profile folgende Zeile, dann entweder neues Terminal oder die Zeile auch direkt selbst im Terminal ausführen

source „$HOME/bin/virtualenvwrapper.sh“

 

 

 

Update:

Dank Rays Hinweis konnte ich PostGIS doch noch installieren und danach weitermachen. Die Problematiken, die ich damit hatte (configure: error: could not find proj_api.h you may need to specify the directory of a PROJ.4 installation using withprojdir) (und die der uberspace-Support leider auch nicht ohne weiteres lösen konnte), habe ich daher wieder aus dem Artikel entfernt.

 

rss-abo-10

Leicht Nachrichten lesen, die Dich interessieren

So, hier nun der erste echte Artikel, der die Kategorie „Anleitung“ eröffnet. Ich möchte Euch einfach, schnell und direkt nachvollziehbar zeigen, wie Ihr die Nachrichten lesen könnt, die Euch interessieren.

1 – Einleitung

rss-abo-12Dazu gibt es schon seit vielen Jahren die sogenannten RSS-Feeds. Das sind  spezielle Web-Adressen, bei denen von Website-Betreibern automatisch alle aktuellen Inhalte in einem bestimmten allgemeinen (man sagt auch „maschinenlesbaren“, im Gegensatz zum normalen nur „menschenlesbaren“) Standard-Format gesammelt werden. Das hat viele Vorteile, unter Anderem können diese Adressen von Programmen automatisch immer wieder abgerufen werden, die Euch dann darüber informieren, was es Neues gibt.

Ihr könnt natürlich auch immer selber auf die Websites gehen und dort die neuesten Nachrichten suchen, aber das ist nicht so bequem wie einfach alle interessanten Neuigkeiten zusammengefasst („aggregiert“), übersichtlich und einheitlich angezeigt zu bekommen.

 

2 – Vorteile

  • Ihr verpasst keine neuen Meldungen, insbesondere von Sites, auf denen sich vielleicht nicht so häufig etwas tut, so dass man sie nicht regelmäßig selbst besuchen würde.
  • Ihr stellt Euch selbst die Nachrichtenquellen zusammen, die zu Euch passen und müsst euch so nicht darauf verlassen, dass jemand anderes genau weiß, für was Ihr euch interessiert (was erstens unwahrscheinlich ist und zweitens auch beängstigend … aber dazu später mehr ;-)).
  • Ihr könnt Nachrichten Filtern, Durchsuchen und als „gelesen“ markieren.

3 – Vorbemerkungen

Es gibt viele Programme, mit denen Ihr RSS-Feeds „abonnieren“ (das kostet nichts!) könnt. Die werden häufig „Feed-Reader“ genannt. Einen habt Ihr aber ziemlich sicher sowieso schon: Euren Web-Browser. Ich zeige Euch jetzt hier, wie Ihr mit einem Add-On noch etwas mehr herausholen könnt und wie das im Einzelnen funktioniert.

Wie immer gilt: Das ist nicht die einzig seelig machende Lösung, sondern meine, die ich Euch empfehle und so aufbereitet habe, dass ich denke, dass sie für jeden verständlich und hilfreich ist und einen guten Start in das Thema darstellt. Bitte schaut Euch um, was es sonst noch für Möglichkeiten gibt und sucht Euch die heraus, die für Euch am besten funktioniert, denn darum geht es: um Euch!

Ich freue mich über Eure Kommentare und Hinweise, z.B. was für Programme Ihr benutzt.

4 – Erster Schritt: Plug-In installieren

rss-abo-2Ich habe in der letzten Zeit hervorragende Erfahrungen mit dem Firefox Plug-In „Digest“ gemacht, also ist das meine Empfehlung an Euch.

rss-abo-3Im Firefox-Menü oben links auf „Add-ons“ klicken, dann „Digest“ suchen und das gefundene installieren, nach Abschluss neu starten.

5 – Zweiter Schritt: Einen Feed abonnieren

rss-abo-8rss-aboNun könnt Ihr auf einer Site, die Feeds anbietet (und das sind mittlerweile sehr viele, zum Beispiel auch diese hier ;)), einen solchen abonnieren, indem Ihr oben rechts das Lesezeichen-Menü öffnet, und „Lesezeichen abonnieren“ auswählt (manchmal bietet eine Seite auch mehrere Feeds mit unterschiedlichem Inhalt an, dann müsst ihr hier den für euch passenden wählen).

Manchmal gibt es auch auf der Seite selber einen Link zum abonnieren, z.B. mit dem bekannten orangen RSS-Icon, den muss man dann nur anklicken.

6 – Dritter Schritt: Den Feed lesen

Das neue Symbol RSS-Knopf oben rechts in der Menüleiste zeigt euch immer aktuell an, wieviele neue Nachrichten es gibt. Wenn ihr es anklickt gelangt ihr in die Leseansicht:

rss-abo-9

In regelmäßigen Abständen schaut Digest nun automatisch im Hintergrund nach, ob es was Neues gibt. Falls ja, wird unten rechts kurz eine Benachrichtigung angezeigt, auch wenn Ihr den Web-Browser gerade nur im Hintergrund mitlaufen habt. So entgeht Euch keine Neuigkeit.

rss-abo-11

7 – So kann es aussehen

Hier noch eine kleine Auswahl aus den Feeds, die ich so mitlese. Insgesamt (nicht hier erkennbar) dürften es so um die hundert sein.

rss-abo-10

In der obersten Zeile, hinter „Alle Einträge“ sind noch zwei Knöpfe, die ich immer eingeschaltet habe, um die Übersicht zu wahren. Außerdem könnt Ihr sehen, dass auch Ordner und Unterordner kein Problem sind, die dann jeweils thematische Zusammenfassungen bieten.

Also surft los und abonniert Eure Lieblings-Neuigkeiten! Verein, Nachrichten, Wetter, Videos, Comics, Pressemeldungen, Fernsehprogramm, Blog-Einträge… alles kein Problem. Viel Spaß in der selbstbestimmten Meldungs-Welt!