websites/dennogumi
websites/dennogumi
1
0
Fork 0
Code Releases Activity

[ci skip] New draft

Browse source
This commit is contained in:
Luca Beltrame 2021-07-25 23:24:04 +02:00
parent 307ca8bfe6
commit 605847fe26
Signed by: einar
GPG key ID: 4707F46E9EC72DEC
1 changed files with 324 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

324
content/post/2021-07-25-setting-up-owntracks-recorder-and-oauth2-with-nginx-and-podman.md Normal file
View file

@ -0,0 +1,324 @@
---
categories:
- linux
- opensuse
comments: true
date: 2021-07-25 00:30:28+02:00
disable_share: true
draft: true
featured_image: /images/banner.jpg
omit_header_text: true
toc: true
tags:
- owntracks
- podman
- containers
- linux
title: Setting up OwnTracks Recorder and OAuth2 with nginx, oauth2-proxy and podman
---
One thing I always wanted to do when going on holiday is to track where I go, the places I've been, and see how much I've travelled around. This is true in particular when going to places where I walk around a lot (Japan stays at the top of the list, also for other reasons that are not related to this post). Something like viewing a map showing where you were, and where did you go, with optional export to KML or GPX to import into other programs like [Marble]().
To my knowledge, there are a number of proprietary solutions to this problem, but in this case I value these kind of data quite a lot, so they are out of the question from the start. And so, I began my search for something I could use.
I initially set up with [Traccar](https://www.traccar.org/) but the sheer complexity of the program (not to mention that I relied on some features from [a popular fork](http://traccar.litvak.su/) was off-putting. Also it did *far* more than what I wanted it to do, and the use case of the program was completely different from mine anyway. After a couple of unsuccessful tries, I left it to gather virtual dust on my server until I deleted it completely.
## A possible solution: OwnTracks
More recently (and more than once) I got interested in [OwnTracks](https://owntracks.org), which at least on paper promised exactly what I wanted. In particular, the web page mentioned
> OwnTracks allows you to keep track of your own location. You can build your private location diary or share it with your family and friends. OwnTracks is open-source and uses open protocols for communication so you can be sure your data stays secure and private.
Therefore that was worthy of investigation. Unfortunately, I found [the documentation](https://owntracks.org/booklet/) to be really sub par. Actually the program is *very* powerful and can do many things, but the guide is essentially a collection of topics rather than "how to do X". Thus, even simple tasks like a proper installation procedure were hard to grasp.
To give a simple explanation on how the whole thing works: OwnTracks collects location data from one's smartphone and submits information to a *recorder*, which is hosted wherever you prefer, which can then store, process and display the information. The Recorder can either use a protocol called [MQTT](https://mqtt.org/), widely used for IoT, or work through HTTP.
As the author of OwnTracks himself recommends HTTP when using the OwnTracks app on Android 6.0+, I didn't bother investigating MQTT and went straight to HTTP.
The rest of this post is how I set up everything.
## Installing the OwnTracks Recorder with Podman
As the OwnTracks application for smartphones can be acquired either from F-Droid or the relevant app stores, that was not a problem (the app is also FOSS, by the way, or I wouldn't have considered it). Then I turned my attention to the Recorder.
The Recorder is a C application which must be compiled manually, and that can have options disabled or enabled at compile time. To be honest I wasn't too keen in building it from source, so I looked at other ways to obtain it. I first searched for it in the [Open Build Service](https://build.opensuse.org), but as I didn't find it, I had to install it manually.
Owntracks has [its own Docker image](https://github.com/owntracks/docker-recorder) for the Recorder, but while I admit that containerization has its uses, I'm not too keen on having it controlled by a daemon that runs as root. And since I had a Docker daemon update that *broke many services* I used (the daemon would just crash on startup), I didn't want to add more to an already fragile system.
Enter [podman](https://podman.io/). Podman is another way of running containers, without any daemon running, and more importantly it can run them *rootless*. That means that you can run individual containers (or groups of them) as a non privileged user, which is better than having a daemon running as root. The various podman commands are also made to mimic Docker, and that eases adaptation.
The rest of this entry deals on how to install and set up the OwnTracks Recorder and authentication.
### Preparations
For this guide I used podman version **3.2.3**, installed through my distribution's package manager (`zypper` on openSUSE). Your mileage may vary with other versions.
First of all, I created a new user. I used `useradd` but any way is fine, for example thorugh YaST or other tools.
```shell
useradd --system -c "OwnTracks" owntrakcs --create-home
```
This is a *real* login, so that you can do things interactively. I set up a strong password and configured SSH to refuse any login from this user, to make sure it stays local only.
Before we proceed further, we have to set up *subuids* and *subgids* for our user, or podman will not function properly. The reason is that podman (by default, at least) when running rootless will use [user namespaces](https://opensource.com/article/19/2/how-does-rootless-podman-work) to map user and group IDs inside the container to other IDs outside the container itself (as an example, root inside your container will be seen as UID 100001 in the host system). These IDs are called subuids and subgids.
To make this work you have to assign ranges of subuids and subgids to your user to use, ensuring they *don't* overlap with anything existing in your system. At least in openSUSE Leap 15.2 the generation of these is not automatic, meaning you have to resort to `usermod` to do the job:
```shell
usermod --add-subuids <min-subuid>-<max-subuid> --add-subgids <min-subgid>-<max-subgid> <login>
```
Once that is done, you'll see something like this in `/etc/subuid` and `/etc/subgid`:
```
owntracks:100000:65536
```
That means that `owntracks` will use subuids (or subgids) starting from 100000 up to 65536 more. (`man subuid` and `man subgid` are your friends).
If we want to run containers at boot, we have to [enable lingering in systemd for the user](https://wiki.archlinux.org/title/systemd/User#Automatic_start-up_of_systemd_user_instances):
```shell
loginctl enable-linger owntracks
```
### Getting the container images
Once that is a done deal, we can finally switch to our user and retrieve the Docker images. OwnTracks has two images that can be used:
- `owntracks/recorder`, which is the actual Recorder application;
- `owntracks/frontend`, which is a fancy HTML/JS frontend to display data gathered from the Recorder.
Getting the images is straightforward, as the podman syntax closely mimics the one of Docker:
```shell
podman pull owntracks/backend
podman pull owntracks/frontend
```
Now that we have the images, we have to make sure to run them together and able to see each other, because the frontend requires a valid connection to the Recorder to be able to display information. In the Docker world, this is often done with `docker-compose`, but although [podman can be used with docker-compose]() it also has [its own way, called "pods"](https://developers.redhat.com/blog/2019/01/15/podman-managing-containers-pods) of keeping containers tightly knit together.
First, we create some directories to host the configuration and other container data:
```shell
mkdir -p owntracks/recorder/config owntracks/recorder/data owntracks/frontend/config owntracks/recorder/store owntracks/recorder/output
```
Then we create our pod. Note that *all* container:host port mappings need to be created here, or they won't work when adding individual containers:
```shell
podman pod create --name owntracks -p 127.0.0.1:8083:8083 -p 127.0.0.1:6666:80
```
This creates the pod *owntracks* and maps port 8083, the one used by the Recorder, to 8083 on the host (only from localhost). Likewise, port 80 on the frontend is mapped to port 6666 (the default is different, but I had something else listening there already).
At this point, we need to create a couple of files before starting the containers. Most importantly, you need to decide on which domain host the Recorder and the frontend. For this guide we will:
- Host both the Recorder and the frontend on the same domain (we will use `tracks.example.com`)
- The frontend will be accessible on the root of the domain, while the various parts of the Recorder will live in the `owntracks` subdirectory (`tracks.example.com/owntracks`).
We then create `owntracks/recorder/config/recorder.conf` with this content:
```bash
#(@)ot-recorder.default
#
# Specify global configuration options for the OwnTracks Recorder
# and its associated utilities to override compiled-in defaults.
OTR_TOPICS = "owntracks/#"
OTR_HTTPHOST = "0.0.0.0"
OTR_PORT = 0
OTR_HTTPPORT = 8083
```
The important bit here is `OTR_PORT`. Setting it to 0 disables looking for a MQTT broker, which I was not interested in running. If it is non-zero, it will try to connect to that port and startup will fail if there is no service running. There are plenty of other configuration options: consult [this list](https://github.com/owntracks/recorder#configuration-file) for more information.
For the frontend, we create instead `owntracks/frontend/config/config.js`:
```js
window.owntracks = window.owntracks || {};
window.owntracks.config = {
api: {
baseUrl: "https://tracks.example.com/owntracks/",
},
};
```
`baseUrl` is where your Recorder lives (see above). It can also be somewhere else entirely if need be. Like with the Recorder, there are [many more configuration options](https://github.com/owntracks/frontend/blob/master/docs/config.md) to explore.
### Starting the containers
It is now time to start the actual containers, and for this we use `podman run`. First we start the Recorder, mapping the folders we have created earlier:
```shell
podman run \
--pod owntracks \
-d \
--rm \
--name ot_recorder \
-v /path/to/owntracks/recorder/config:/config \
-v /path/to/owntracks/recorder/store:/store \
-v /path/to/owntracks/recorder/output:/output \
owntracks/recorder
```
As you can see, the syntax is very close to what Docker does. You can omit the `--rm` switch if you don't want the container to be deleted when you stop it (it might be relevant for startup, as I'll explain later).
Check if the Recorder is actually running:
```shell
podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
[...]
843222dacfd7 docker.io/owntracks/recorder:latest 7 days ago Up 7 days ago 127.0.0.1:6666->80/tcp, 127.0.0.1:8083->8083/tcp ot_recorder
```
You might want to check also the logs for possible errors with `podman logs ot_recorder`.
Then it's the turn of the frontend:
```shell
podman run \
--pod owntracks \
-d \
--rm \
--name ot_frontend \
--env SERVER_HOST=127.0.0.1 \
--env SERVER_PORT=8083 \
-v /path/to/owntracks/frontend/config/config.js:/usr/share/nginx/html/config/config.js \
owntracks/frontend
```
There are a couple of things worth noting here. The `env` option sets environment variables, and tell the frontend to connect to localhost on port 8083 to find the Recorder. In a podman pod, a service of a container can be accessed by another by connecting through localhost. There are other ways to use proper DNS names like docker-compose does, but they're not essential in this specific case. Secondly, although we use `--env` you can use proper environment files if you desire so (see `man podman`).
Check with `podman logs ot_frontend` whether the container has connected correctly to the Recorder, and we're done.
### Automatic startup
We can use systemd user units to do the job to start our container at boot. Before that we need to do one more thing, which is important especially if you never log in directly with this user (and that's why we made it in the first place).
In order to systemd to work, it needs (as far as I can see) XDG_RUNTIME_DIR set. So I put this in the user's shell startup configuration:
```bash
export XDG_RUNTIME_DIR=/run/user/$(id -u)
```
then I logged out and back in. I'm not sure if this can be done without a logout/login.
Afterwards, it's matter of creating the relevant directories and generating the systemd units:
```shell
mkdir -p ~/.config/systemd/user
cd ~/.config/systemd/user
podman generate systemd --name owntracks -f # optional: add --new to re-create containers at each restart
# Make systemd aware of the units
systemctl --user daemon-reload
```
This will create a bunch of files there, namely `pod-owntracks.service`, `container-ot_recorder.service` and `container-ot_frontend.service`. You can then enable owntracks at boot with
```
systemctl --user enable pod-owntracks.service
```
You can add `--new` to make podman recreate pod and containers on each restart. This is a prerequisite if you want podman to actually update images easily, but at least in my limited testing, when pods are involved often restarts break, so I made the containers persistent. YMMV.
Point a browser on the server (even `links` will suffice) to `localhost:8083` and `localhost:6666` if you want to verify everything is done correctly.
### Hooking up the web server
Right now both the Recorder and the frontend are accessible only via localhost. This was the plan all along, because we'll put nginx in front of them. I assume you have already a functional web server with proper SSL set up (with Let's Encrypt, there is no reason not to).
First of all, create a new configuration file for your site. Then you can add the following bits to it (largely copied from the OwnTracks docs):
```nginx
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name tracks.example.com;
server_tokens off;
client_max_body_size 40m;
# Put SSL and other configuration bits here
# OwnTracks frontend
location / {
proxy_pass http://127.0.0.1:6666/;
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;
auth_request_set $auth_cookie $upstream_http_set_cookie;
add_header Set-Cookie $auth_cookie;
}
# OwnTracks backend
# Proxy and upgrade WebSocket connection
location /owntracks/ws {
rewrite ^/owntracks/(.*) /$1 break;
proxy_pass http://127.0.0.1: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 /owntracks/ {
proxy_pass http://127.0.0.1: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 /owntracks/view/ {
proxy_buffering off; # Chrome
proxy_pass http://127.0.0.1:8083/view/;
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;
}
location /owntracks/static/ {
proxy_pass http://127.0.0.1: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 /owntracks/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;
}
}
```
Check the configuration with `nginx -t` and then restart your webserver. If you access `https://tracks.example.com` you should see a map (OpenStreetMap) and if you access `https://tracks.example.com/owntracks` you should be presented with a list of locations and users. Of course everything is empty, because we haven't added any device yet.
## Authentication: is httpasswd the only way?
## oauth2-proxy
## The ideal source of authentication
## Gluing it all together