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…

Update: ot-recorder

Der ot-recorder klappt auch, wegen der Nachfrage in den Kommentaren hier noch ein kleiner Hinweis dazu. Ist leider aus Zeitmangel nicht ganz so ausführlich, aber besser wie nix:

Ich habe Version 0.6.5 vom 30. Mai 2016 ans Laufen bekommen und beziehe mich daher hier auf diese, würde mich aber nicht wundern, wenn auch eine neuere Version funktionieren würde. Vielleicht einfach mal ausprobieren. Leider weiß ich nicht mehr genau den Weg, den ich damals genommen habe, und kann daher nur Hinweise geben, keine Anleitung.

Man benötigt wohl auch noch die libconfig in Version 1.5 (möglicherweise geht auch hier die neuere 1.6?). Die kann man einfach runterladen, in ein Verzeichnis entpacken (in meinem Fall /home/$USERNAME/projekte/libconfig/libconfig-1.5), dann

ausführen und hernach

Das reicht schon, dann ist die Bibliothek dort verfügbar.

Es sieht so aus, als wären die nötigen Änderungen im Ordner von owntracks-recorder allesamt in der config.mk und dessen Kompilieren sollte danach klappen. Würde mich freuen von jemandem, der es ausprobiert hat, eine Rückmeldung zu bekommen. Also, meine config.mk hat folgende Änderungen:

($USERNAME jeweils von Hand ersetzen durch den eigenen Benutzernamen, die anderen Pfade jeweils auf eigene Gegebenheiten anpassen)

Nach dem Kompilieren müsste ./owntracks-recorder funktionieren. Allerdings gab es, wenn ich mich recht erinnere, noch kleinere Probleme, die Web-Oberfläche aufzurufen, die ich nie wirklich behoben habe, weil mir die Daten in den Verzeichnissen schon gereicht haben.

Ich hoffe, das hilft schonmal?

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:

• https://f-droid.org/wiki/page/Setup_an_FDroid_App_Repo
• https://f-droid.org/wiki/page/Installing_the_Server_and_Repo_Tools
• https://f-droid.org/manual/fdroid.html#Simple-Binary-Repository
• https://gitlab.com/fdroid/fdroidserver
• http://paulscott.co.za/blog/setting-up-a-private-android-appstore-with-fdroid/
• https://github.com/matlink/gplayweb#user-content-fdroid-compatibility

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.

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.

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

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 Bewgungen – Wissen 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

Moin! 🙂 Schön, dass Du diesen Artikel liest. Es ist der erste auf diesem meinem neuen Blog. Was genau ich hier vor habe, erzähle ich auf der Seite „Über“.

In der kommenden Zeit gibt es hier hoffentlich neue weitere Artikel. Also immer schön nachschauen kommen.

Cheers,
Friesenkiwi