owntracks / recorder Goto Github PK

Currently a single user/dev combination can be specified. We need to be able to plot track of, say, two friends.

GW: look up topic, and if found in lmdb, rename TID on the fly in JSON before committing to storage.

As expected, TLS is what breaks first.
I connect the iOS owntracks app in Private mode with activated TLS and authentication, so I have that going for me - which is nice.
MQTT setup was done using https://github.com/padelt/docker-owntracks-private-mqtt-broker , so mosquitto 1.4.2 is listening.
When recorder is connecting, it logs this:

2015-09-18 16:14:22,603 DEBG 'mosquitto' stdout output:
1442592862: OpenSSL Error: error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown
1442592862: OpenSSL Error: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure
1442592862: Socket error on client <unknown>, disconnecting.

2015-09-18 16:14:32,633 DEBG 'mosquitto' stdout output:
1442592872: New connection from 178.201.xxx.xxx on port 1883.

Recorder repeatedly logs this:

Sep 18 16:12:21 pa15.local ot-recorder[4327] <Info>: MQTT connection: rc=8 [A TLS error occurred.]. Sleeping...

Config in /usr/local/etc/ot-recorder.sh is:

export OTR_HOST="my.host.name"     # MQTT hostname
export OTR_PORT="1883"     # MQTT port (set to 8883 for TLS and define OTR_CAFILE)
export OTR_USER="client2"           # broker user name
export OTR_PASS="whatever"            # broker password
export OTR_CAFILE="/Users/pa/owntracks/ca.crt"      # PEM CA certificate chain for broker

opts="${opts} --http-host 127.0.0.1 --http-port 8083 -D"

exec "/usr/local/sbin/ot-recorder" ${opts} "owntracks/#"

The CA certificat is what signed the mosquitto-server-certificate.

Mosquitto's config is basically this:

id_file /var/run/mosquitto.pid

persistence true
persistence_location /volume/data/

user mosquitto

port 1883

log_dest file /volume/log/mosquitto.log
log_dest stdout

cafile /volume/config/tls/ca.crt
certfile /volume/config/tls/server.crt
keyfile /volume/config/tls/server.key
require_certificate false

allow_anonymous false
password_file /volume/config/clients/passwd

How can I debug the actual cause of the failure?

I assumed that recorder takes the OTR_CAFILE contents to validate the certifcate presented by mosquitto. recorder does not get any certifcate itself, so it will not send one to mosquitto. That should be fine with mosquitto, since require_certificate is false.

Help!?

Everything seems to be fine in 0.4.2 except when I try to access the live map.

Here's the relevant log:

ot-recorder[22361]: starting
ot-recorder[22361]: connecting to MQTT on localhost:1883 as clientID ot-recorder-raspberrypi-22361 without TLS
ot-recorder[22361]: HTTP listener started on 0.0.0.0:8083
ot-recorder[22361]: Subscribing to owntracks/# (qos=2)
ot-recorder[22361]: http: GET /index.html
ot-recorder[22361]: http: GET /table/js/jquery-1.11.3.min.js
ot-recorder[22361]: http: GET /table/js/mustache.js
ot-recorder[22361]: http: GET /table/js/moment.min.js
ot-recorder[22361]: http: GET /api/0/last
ot-recorder[22361]: http: GET /favicon.ico
ot-recorder[22361]: http: GET /last/index.html
ot-recorder[22361]: http: GET /last/functions.js
ot-recorder[22361]: http: GET /last/websock.js
ot-recorder[22361]: http: GET /last/pista-micro.png
zsh: segmentation fault  /usr/local/sbin/ot-recorder --http-host 0.0.0.0 'owntracks/#'

Going back to release tag 0.4.1 fixes the problem.

I suspect there's something relevant in websock.js but I'm not able to track it down unfortunately.

One of these?

• touch a file with timestamp of last received message
• Open listening socket which prints "I'm alive"

We need to be able to monitor whether recorder is still alive.

We want to enable listings (date, address, etc)

Currently waypoints and events are missing from stdout. They are recorded to store (.rec) fine.

Please add waypoints and events logging to stdout.

so, not from tst to tst, but last, say, 50 points? If so, we need to be able to read files backwards. Any takers for writing a "reverse fgets() in C? :-)

If you run make install then the wdocs directory gets copied into DOCROOT such that you end up with (in the default case):

/var/spool/owntracks/recorder/wdocs/wdocs

otherwise it's impossible for the client to identify an array element (location)

so that we can daemonize ot-recorder and/or run it under whatever

store/ghash/XXX/u39m40c.json with XXX being first 2 or 3 ghash letters

7 is too high for high-volume publishes because we quickly run over the 2500 GOOG quota limit
6 or less is too imprecise for certain users.

for --user and optionally --device
should do a tail -f kind of thing

Reported by Ben.

currently get a full map of the world and have to manually zoom into my town to see where each device is - would be great if the map would auto-zoom to best show all devices

A reserved username, device combination (ping, pong) will store last/ but not rec/ so that we can use this to test round-trip connectivity from outside (a.k.a. is the recorder still alive and kicking).

We should possibly add statistics somehow for large installations (number of Greenwich devices), not for small-scale installs (e.g a couple of OwnTracks devices)

The change introduced in #46 is unsatisfactory: map zooms at every publish, so it's not possible to zoom to user's preferred view.

We'll probably introduce a GET parameter for this.

This will allow us to ease CSV output and take advantage of fields also for JSON output.
If so, add warning to manual that GeoJSON output format requires lat, lon (which ought to be obvious..)

We now have lmdb named databases, so we can quite easily do this: a configurable Lua script or code on a per/topic basis, eg. to handle particular "events". For example

owntracks/jane/phone/event <lua program here>

which gets passed the topic and a Lua table of the payload.

as well as generated clientID (for debugging)

Using "=" doesn't work:

Correct:
ocat --dump luadb

Issue #31 disclosed a bit of lousy code which has to be completely overhauled. While all incoming _types were handled (i.e. stored), only location messages were being given the geo, hook, etc. treatment. This is completely wrong and must be reworked.

• hiredis

People should be able to test the recorder

maybe also --load-ghash

for "monitoring", what else? :)

The sscanf can crash

Any takers to assist me in doing this (in particular .deb)?
I've started on a .spec (in etc/)

tooltip is wrong

Something like

... --fields lat,tst,lon

If for some reason location messages don't arrive to Recorder in the order of their timestamps, then Recorder also serves them out-of-order in the polyline API etc. I think that Recorder should either store the messages ordered by timestamp or sort them before building the polyline.