Petit partage de position entre amis

Ne vous laissez pas intimider par le tag Geek de ce billet, le début est censé être grand public, et peut-être même intéressant, même si je descendrai ensuite dans les détails bassement techniques de ce que j'ai mis en place.

Le besoin

J'utilise depuis un certain temps un moyen de transport considéré comme dangereux. J'écris « considéré », parce que si je concède volontiers l'existence du danger, j'ai l'impression que la différence de danger par rapport aux autres moyens de transport est largement surestimée, à la fois par sous-estimation du danger de la voiture et par sur-estimation du danger de la moto.

Bref, si j'ai fait le travail sur moi pour être à peu près à l'aise avec ce danger, mon entourage ne l'a pas (encore ?) fait, et il reste une certaine inquiétude chez eux lorsque j'enfourche ma machine.

Dans l'espoir d'aider à réduire cette inquiétude, j'ai eu l'idée d'utiliser le traceur personnel téléphone portable avec lequel je pars pour partager en temps réel ma position géographique avec ledit entourage, pour qu'ils sachent où j'en suis et que je me déplace encore normalement.

L'idée m'est venu du souvenir d'une connaissance, il y a plusieurs années, qui trouvait génial Google Latitude, parce qu'au lieu de s'inquiéter du retard de sa femme, il a pu voir directement qu'elle était coincée dans un embouteillage.

À la suite de cette idée, j'ai repensé à tous les cas similaires dans lesquels ça pourrait être utile. J'ai l'habitude des SMS disant que je suis bien arrivée chez moi après un trajet en voiture, ou que je suis en train de partir, mais les bouchons franciliens introduisent tellement de variabilité dans les temps de trajet que le correspondant ne peut pas trop savoir à quel moment ce n'est pas normal de pas me voir arriver ou ne pas recevoir de SMS.

Je connais des gens qui n'ont pas peur de faire un SMS au volant ou d'appeler, pour prévenir des difficultés routières, mais ce n'est pas du tout mon cas, même immobilisée dans un embouteillage.

Alors que si à la place, il y avait une page web, simple d'utilisation, à laquelle les gens pourraient accéder pour savoir où je suis, et éventuellement à quelle vitesse je progresse, mes proches pourraient à loisir estimer à quelle heure je vais arriver, ou vérifier que mon trajet se passe sans encombre.

Cela étant, même si Google Latitude existait encore, je ne suis pas fan du tout d'envoyer ma position géographique à n'importe qui, surtout dans un contexte de capitalisme de surveillance, donc je préfèrerais héberger moi-même toute l'infrastructure nécessaire pour le faire, tout en gardant l'utilisation facile pour mon entourage.

On pourrait arguer que le système de surveillance actuel est tel que partager ma position géographique avec une multinationale ou une autre n'est pas leur donner quelque chose qu'ils n'ont pas déjà. Je respecte cette idée, mais je fais quand même mon truc chez moi sur mon serveur, c'est un choix personnel.

Choix logiciels

S'il semble exister une pléthore d'applications Android pour suivre à la trace son propre téléphone, qui offrent chacune une compatibilité plus ou moins large avec divers serveurs, les choses sont beaucoup plus limitées côté serveur, surtout si je veux garder toute l'infrastructure sur des machines qui m'appartiennent. Parmi toutes ces app' je vais cependant relever OsmAnd, que j'utilise déjà pour enregistrer mes trajets (et pouvoir revisiter les endroits où je me suis trompée).

Au niveau serveur, il semble se dégager deux solutions principales : Owntracks et Traccar.

A priori, comme ça, Traccar a l'air plus ancien et établi, capable de récupérer des données de tout plein d'appareils. D'ailleurs OsmAnd peut lui envoyer la position pendant l'enregistrement de traces GPS. En revanche, son interface a l'air plus rigide, et surtout c'est un bazar en Java, ce qui rend son déploiement et son entretien très pénibles.

De l'autre côté, Owntracks est très facile d'installation sur mon serveur, il donne une impression de légèreté par rapport à une JVM, et les pages qu'il présente sont plutôt jolies et utilisables. En contrepartie, il faut l'application correspondante sur le téléphone, et il n'a pas l'air tout à fait prévu pour faire ce que je veux faire.

J'ai l'impression qu'Owntracks est orienté « réseau social » comme Google Latitude, à partager sa position en continu. Je n'imagine pas du tout quel côté social ça peut avoir, mais manifestement il y a de la demande. Il semble y avoir aussi un certain nombre d'application d'automatisation suivant la localisation du téléphone, et je finirai peut-être par essayer ça.

Bref, j'ai essayé Owntracks sur mon serveur et sur mon téléphone, et ça s'est plutôt bien passé, donc je suis partie vers cette solution.

Voici un aperçu de ce que ça donne :

Il est possible d'afficher une ligne qui relie ces points au lieu des ponts eux-mêmes. Je pense que les points donnent une meilleure idée de la quantité transmise de données, et en plus la vue en point permet de cliquer dessus pour avoir une bulle avec l'heure du point et la vitesse courante (si le téléphone l'envoie), ce qui peut intéresser les gens qui me suivent.

Serveur Owntracks Recorder

À partir de là, je vais rentrer dans les détails bassement techniques de la mise en place de cette solution. Si vous n'êtes pas à l'aise dans les geekeries, vous pouvez vous arrêter ici dans ce billet.

En gros, pour faire simple, j'ai suivi l'exemple de Dan Langille, qui diverge assez peu de la documentation officielle.

J'ai installé ce serveur sur Rebma, qui est sous FreeBSD. Par souci de sécurité et de simplicité, je l'ai enfermé dans une sjail (merci Bsdsx !).

mkdir /srv/jail/s-ot-recorder
sjail /srv/jail/s-ot-recorder init
mkdir /srv/jail/s-ot-recorder/dev
mount -t devfs devfs /srv/jail/s-ot-recorder/dev
sjail /srv/jail/s-ot-recorder pkg install ot-recorder

Ensuite, lancement de la jail et initialisation du soft (qui gagnerait peut-être à être un peu moins pédestre) :

vim /etc/jail.conf
jail -c s-ot-recorder
mkdir -p /srv/jail/s-ot-recorder/home/ot-recorder
chown 243:243 /srv/jail/s-ot-recorder/home/ot-recorder
pw usermod -V /srv/jail/s-ot-recorder/etc/ -n ot-recorder -d /home/ot-recorder
vim /srv/jail/s-ot-recorder/usr/local/etc/ot-recorder/ot-recorder.conf
chown root:243 /srv/jail/s-ot-recorder/usr/local/etc/ot-recorder/ot-recorder.conf
jexec -U ot-recorder s-ot-recorder ot-recorder --initialize
vim /srv/jail/s-ot-recorder/usr/local/etc/mosquitto/mosquitto.conf

Et ensuite, avant de tout automatiser, lancer les serveurs à la main, pour vérifier que ça marche :

jexec -U nobody s-ot-recorder /usr/local/sbin/mosquitto -c /usr/local/etc/mosquitto/mosquitto.conf -d
jexec -U ot-recorder s-ot-recorder ot-recorder 'owntracks/#'

Pour voir à peu près ce qu'il se passe, Owntracks a la particularité de communiquer avec le protocole MQTT, mais je ne suis pas assez à l'aise pour gérer un serveur disponible sur le grand 'ternet. Du coup, je cache le serveur MQTT dans la même jail que le serveur Owntracks, que je lance ensuite.

J'ai gardé la configuration par défaut du serveur MQTT :

# cat /srv/jail/s-ot-recorder/usr/local/etc/mosquitto/mosquitto.conf
pid_file /var/run/mosquitto.pid
user nobody
port 1883
cafile /usr/local/share/certs/ca-root-nss.crt

Au niveau du serveur Owntracks, j'ai seulement activé l'interface HTTP :

# grep '^[^#]' /srv/jail/s-ot-recorder/usr/local/etc/ot-recorder/ot-recorder.conf
OTR_HTTPHOST="localhost"
OTR_HTTPPORT=8083

Et le plus gros morceau, le fragment de configuration de nginx :

    server {
        listen 80;
        server_name owntracks.instinctive.eu;
        return 301 https://owntracks.instinctive.eu$request_uri;
    }

    server {
        listen 443 ssl;
        server_name owntracks.instinctive.fr;
        server_name owntracks.instinctive.eu;

        if ($time_iso8601 ~ "^(\d{4})-(\d{2})-(\d{2})") {
            set $year $1;
            set $month $2;
            set $day $3;
        }

        access_log /var/log/nginx/$year-$month-$day-owntracks.log main;

        location /.well-known/acme-challenge/ {
            default_type "text/plain";
            root /acme;
        }

        # Proxy and upgrade WebSocket connection
        location /ws {
            auth_basic              "OwnTracks pub";
            auth_basic_user_file    /usr/local/etc/nginx-ot.htpasswd;
            rewrite ^/(.*)    /$1 break;
            proxy_pass      http://172.30.1.9:8083;
            proxy_http_version  1.1;
            proxy_set_header    Upgrade $http_upgrade;
            proxy_set_header    Connection "upgrade";
            proxy_set_header    Host $host;
            proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location / {
            auth_basic              "OwnTracks pub";
            auth_basic_user_file    /usr/local/etc/nginx-ot.htpasswd;
            proxy_pass      http://172.30.1.9:8083/;
            proxy_http_version  1.1;
            proxy_set_header    Host $host;
            proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header    X-Real-IP $remote_addr;
        }

        # OwnTracks Recorder Views
        location /view/ {
            auth_basic              "OwnTracks pub";
            auth_basic_user_file    /usr/local/etc/nginx-ot.htpasswd;
             proxy_buffering         off;            # Chrome
             proxy_pass              http://172.30.1.9:8083/view/;
             proxy_http_version      1.1;
             proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
             proxy_set_header        X-Real-IP $remote_addr;
        }
        location /static/ {
            auth_basic              "OwnTracks pub";
            auth_basic_user_file    /usr/local/etc/nginx-ot.htpasswd;
             proxy_pass              http://172.30.1.9:8083/static/;
             proxy_http_version      1.1;
             proxy_set_header        Host $host;
             proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
             proxy_set_header        X-Real-IP $remote_addr;
        }

        # HTTP Mode
        location /pub {
            auth_basic              "OwnTracks pub";
            auth_basic_user_file    /usr/local/etc/nginx-otpub.htpasswd;
            proxy_pass              http://172.30.1.9:8083/pub;
            proxy_http_version      1.1;
            proxy_set_header        Host $host;
            proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header        X-Real-IP $remote_addr;

            # Optionally force Recorder to use username from Basic
            # authentication user. Whether or not client sets
            # X-Limit-U and/or uses ?u= parameter, the user will
            # be set to $remote_user.
            proxy_set_header        X-Limit-U $remote_user;
        }
    }

En bref, j'ai pris la configuration officielle, sans ajouter de chemin vu que le sous-domaine est dédié, et j'ai juste forcé la communication HTTPS et ajouté une Basic Authentication pour que ce ne soit pas ouvert au monde entier.

Il y aurait des choses à noter pour l'ajout d'un sous-domaine à mes scripts Let's Encrypt, mais je n'ai pas encore trouvé comment faire ça proprement, mon historique est un peu trop brouillon pour être publié.

Client Owntracks

Mon téléphone est le Kyocera Torque KC-S701 dont je vous ai déjà parlé, et dont l'âge commence à se faire sentir surtout par le fait qu'il est resté à Android 4.4 alors que de plus en plus d'applications réclament des versions plus récentes.

Je trouve que c'est la plus jolie indication de la durabilité de ce téléphone, mais ce n'est quand même pas super pratique au quotidien, en plus d'être source d'inquiétudes.

Bref, Owntracks fait partie de ces applications qui ont besoin d'Android 5.0 ou plus récent, que je ne peux donc pas trouver sur le Play Store de mon téléphone.

Je suis donc allée pêcher la version 1.2.7, qui serait d'après ce ticket la dernière à fonctionner sur mon téléphone.

Par souci de service public pour les besoins du présent billet, et pour être prête lorsque je changerai de téléphone, j'ai sorti ma tablette sous Android 7.0 pour essayer la dernière version (2.1.3).

En termes d'expérience utilisateur, pour mes besoins (donc sans rien utiliser du côté social ou automatisation), la seule différence entre ces deux versions est que la veille version est tout le temps dans ce qui est le mode Significant Location Change sur la nouvelle.

En dehors de cette chasse aux versions, je n'ai rencontré aucune difficulté particulière pour mettre en œuvre cette application, et l'image ci-dessus est une capture d'écran de mon navigateur de mon premier essai de cette application sur mon téléphone.

Je ne sais pas si c'était un coup de chance, ou s'il y a quelque chose de particulier aux déplacements motorisés, mais mes essais suivants à pied ont été beaucoup moins convaincants.

De ce que je comprends, dans le mode Significant Location Change, l'application demande au système d'exploitation de la réveiller lorsque la position change de 500 mètres ou tous les quarts d'heure, du moins dans les paramètres par défaut que je n'ai pas changés. Notez que dans la nouvelle application, il n'y a plus d'interface pour changer ces paramètres, il faut aller dans Configuration Management pour touiller les valeurs directement dans le JSON de configuration (locatorDisplacement et locatorInterval).

La nouvelle application apporte le mode Move, plus précis mais plus consommateur en batterie, où la position est demandée toutes les 30 secondes, et ça n'a pas l'air paramétrable.

Si j'en crois les mesures de consommation de l'Android sur ma tablette, le mode Move consomme en moyenne 115 mA quand il fonctionne. Je n'ai aucune idée de la réalité de cette valeur de courant, ni comment elle se traduit sur d'autres appareil, donc je vais considérer les Ampères comme une unité arbitraire de consommation électrique. Par rapport aux autres applications qui fonctionnent en arrière plan, ça me semble beaucoup, même si c'est peu par rapport à l'écran ou la veille 4G.

Mais parfois, il ne fonctionne pas, et aucune donnée n'est transmise au serveur. Le mode Significant Location Change fonctionne nettement moins souvent que le mode Move, mais quand il fonctionne il donne des points espacés d'environ 600 mètres, et il consomme 10 à 20 mA.

Une chose intéressante est que ces deux modes semblent tomber en marche beaucoup plus souvent lorsqu'il y a en même temps OsmAnd qui enregistre une trace GPS, aussi bien sur le téléphone que sur la tablette, comme s'il forçait des réveils du système de géolocalisation, qui le rendraient plus réactif pour Owntracks.

Client OsmAnd

Devant le manque de fiabilité de l'application Owntracks et sa consommation qui me semblait élevée en mode Move, j'ai eu envie d'essayer de faire communiquer OsmAnd avec mon serveur Owntracks.

Conceptuellement, la communication HTTP d'Owntracks n'est pas très compliquée : un bout de JSON qui est POSTé vers un URI donné avec une Basic Authentication.

Or, comme dit, OsmAnd est capable de communiquer avec Traccar, visiblement à coups de GET et quelques paramètres ajoutés dans la query de la requête. Je n'ai pas résisté à l'envie d'en chercher le code, mais c'est vraiment un GET codé en dur.

Je pense qu'il ne faudrait pas grand-chose pour POSTer à la place, donc peut-être qu'une âme charitable se penchera sur la question.

En attendant, je me suis fait un traducteur OsmAnd vers Owntracks qui accepte la requête GET et la traduit en POST, qui tourne dans la même jail (en espérant que je n'ai pas fait de gaffe qui va me compromettre mon serveur).

J'imagine que les esprits chagrins trouveront idiot d'utiliser le C pour faire un serveur web qui fait un petit traitement de chaînes de caractères avant de devenir client HTTP, alors que ça pourrait se faire en deux coups de cuiller à pot dans un langage de script quelconque.

Je leur ferai remarquer d'une part qu'il vaut mieux utiliser un langage sous-optimal que l'on connaît à peu près que de copier-coller du StackOverflow dans un langage plus adapté auquel on ne comprend rien ; et d'autre part que l'intérêt du système de base ultra-minimaliste des sjail est justement de ne pas avoir un interpréteur omnipotent sous la main.

Et puis moins de 400 lignes, commentaires et blancs compris, ce n'est pas loin d'être deux coups de pots de C.

Bref, une fois les petits soucis de traduction résolus (c'est quoi le délire de compter les millisecondes depuis l'Epoch UNIX ‽), ça l'avantage sur l'application Owntracks que ça marche extrêmement bien, et qu'une fois configuré je n'ai plus rien de particulier à faire pour partager les chemins que j'enregistre, et uniquement ceux-ci.

En revanche, côté consommation de batterie, je me demande si l'Android 7.0 de ma tablette ne se moque pas un peu de moi en prétendant pouvoir ventiler des dizaines de µAh par application.

J'ai pu mesurer une consommation moyenne de 90 mA pour OsmAnd qui enregistre mes traces GPS comme d'habitude, avec un point toutes les cinq secondes, sans aucun partage, et plus de 350 mA avec en plus un partage de la position toutes les cinq secondes. Mais ensuite, j'ai voulu voir le partage de position toutes les dix secondes, et je suis arrivée à environ 130 mA, mais en consommant vingt fois plus au retour qu'à l'aller.

Je pense qu'il faudrait faire plus de mesures pour pouvoir tirer une conclusion à peu près claire sur la consommation, mais ça me gonfle un peu de me trimballer avec la tablette (à moins d'en faire mon téléphone principal, en remplacement du Kyocera).

De toute façon, au point où j'en suis le surplus de consommation me dérange moins que la fiabilité aléatoire, donc je vais probablement rester sur l'enregistrement par OsmAnd quand quelqu'un d'autre que moi compte sur ce suivi, et peut-être tenter encore quelques expériences avec l'application Owntracks quand je suis seule.

Conclusion

Je m'attendais à ce que la mise en place d'une telle infrastructure soit une tâche titanesque, alors qu'en fait ça s'est extrêmement bien passé, aussi bien côté serveur que côté mouchard de poche téléphone.

Je suis aussi agréablement surprise par la simplicité de configuration de l'application et la simplicité d'utilisation de l'interface web du serveur, donc j'imagine tout à fait offrir ce servir à des proches qui voudraient que je les suive sur leur route.

Au point où j'en suis, il me reste plus qu'à peaufiner les invocations pour le lancement automatique de tous les services sur le serveur, et à réfléchir à une politique d'accès à ma position.

En gros, Owntracks Recorder permet de ne donner accès qu'à une partie des informations, et j'ai le choix entre fixer une plage temporelle déterminée, mais alors il faudrait que je reconfigure le serveur pour chaque voyage, ou fixer un intervalle de temps relatif (par exemple, les six dernières heures), mais alors il faudrait faire attention aux éventuelles indiscrétions si un proche se connecte en dehors des périodes prévues.

Commentaires

Pas de commentaire pour le moment.

Poster un commentaire

Nom ou pseudonyme :

Adresse e-mail (facultatif, ne sera pas publié) :

Site web (facultatif) :

Format de mise en forme : format historique Markdown restreint

Enregistrer ces informations dans un cookie

Commentaire (sera publié dans cette page, voir les conseils de mise en forme ci-dessous) :

Message personnel (ne sera pas publié) :

Mise en forme historique : pour mettre en valeur un mot ou un groupe de mot, tapez une étoile de part et d'autre, sans mettre d'espace entre l'étoile et le mot, comme ceci : *mise en valeur*. Pour insérer un lien, mettez le entre crochets, comme ceci : [http://instinctive.eu/].

Mise en forme markdown : voir le guide détaillé, en résumé c'est le Markdown traditionnel, sans HTML ni titres, mais avec les tables PHP-Markdown-Extra.

Attention : les balises HTML entrées dans les commentaires seront affichées telles quelles, et non pas interprétées.