After reading on the dockerized versions of satnogs client, I was eager to give it a try. I took an openwrt router (banana-pi R2) that I had lying around and went for the installation. Here are some of the issues I faced just in case some one else tries:
openwrt uses /opt/docker as docker home, so I used /opt to mount an ssd disk
first run pulled the image knegge/satnogs-client:latest. The logs showed that the satnogs-client complained about missing libraries.
got the sources and modified the Dockerfile to add these packages: libatlas3-base libopenjp2-7 libtiff5, and then built the image locally.
running rtl_test in the container as satnogs-client user showed a permission problem to access the usb device. Solved by applying chmod -R 666 /dev/bus/usb in the host.
a multicast dns daemon (like avahi or umdns) needs to run in the docker host, otherwise a SOAPY remote dependency will cause a failure.
the satnogs-client complained regarding gnuradio. I removed the .gnuradio configuration directory in the image. The troubleshooting page recommended to run the python scripts. The scripts were working. That generated a new configuration .gnuradio/prefs/vmcircbuf_default_factory, with the value gr::vmcircbuf_mmap_shm_open_factory, while the original one, gr::vmcircbuf_sysv_shm_factory did not work. For the next docker run, this new configuration file was mapped to override the one provided in the image. I suppose the .gnuradio configuration should not be included in the image.
So finally, the satnogs-client was running on this device. Using htop to see the cpu usage on the device showed no more than 50 % usage.
I is nice to just pull a docker image in an unsupported devices like mine to install the satnogs-client. I look forward to further try other images with different tags in the same device and try whatever suggestions come forward.
Hi, very cool running this on other devices (:
This was my initial work on dockerization and it has since moved to the librespace version and based on docker-compose.
I see some of the differences is on the host and some in the image, both of these are kind of adressed in this lsf version.
For example the .gnuradio file is not created anymore (this was a relic from the older buster I think).
The missing libs sounds a bit strange, these should’ve been pulled in as depencencies, should be fixed (althou active development on this image is not encouraged, use lsf).
Permissions is handled different in the compose, but I think it’s worth adapting the client rather than the host, or the docker user on the host instead. What is the group and permissions of the rtl-sdr ? And what groups are the docker user member of ?
I have been ignoring avahi for most systems, it is installed on host but not mapped to the container afaict. The adalm-pluto is even more dependant on this and complains a bit but still works.
Perhaps I can try replicating some of this, just need to put openwrt on some rpi and try it out.
If you continue to work on this I suggest you use the WIP lsf instead of my initial client.
Good to have your feedback. I have moved to experiment with the docker compose setup you mentioned which is based on the lsf docker satnogs client. The first problem that appeared with my setup:
docker compose up
...
Error response from daemon: error gathering device information while adding custom device "/dev/ttyUSB0": no such file or directory
Commented out that usb device entry in the devices section in the docker-compse.yml file, as that device is not present in the router (no problem to add it, anyway). After that all containers started. No gnuradio problems and no missing libs messages. Next I tried rtl_test which failed due to permissions problems. The solution was not to use volume for /dev/bus/usb and use instead a devices section:
devices:
- '/dev/bus/usb'
So nice to have again the satnogs-client running, htop showing a maximum load of 50% when processing observations.
Regarding docker in openwrt, it is not assigned to any extra group, so just docker.
The compose is a maxed out example, you can certainly remove services you don’t need. This will probably be configured different in the future, I was thinking of building something like menuconfig for selecting what services you need and some other settings, but this is not super necessary.
Just remove gpsd, rotctld entirely if you don’t need them.
Right, the device mapping with /dev/bus/usb should not be in volumes.
You can also point it to symlinks in /dev/serial/by-id/ and docker will happily map the proper device.
I’m making a few changes to reflect this.
Regarding the permissions, isn’t the dongle group owner named plugdev ? ls -lR /dev/bus/usb/
What I mean is that the user that launches docker-compose should be added to plugdev, then it will just work after reboots etc.
OK regarding the regarding the removal of services and the device mapping. The /etc/group in openwrt has not no plugdev, and no dongle group. The permission for accessing the usb device from the docker container was provided by applying chmod -R 666 /dev/bus/usb in the host. I would be surprised if openwrt would allow for other solutions there.
Probably the docker compose file should allow mapping the satnogs-client user an group to an user in the host in order to ease fixing usb access issues.
Well, not sure how that is supposed to be done. Normally the user starting the container needs to have the privileges required, the uid:gid mapping doesn’t change this, numerically it is defined here and used here.
This short wiki doesn’t really have details on it either, perhaps only that the uid running this is 1000.
You can also experiment with privileged and security-opt stuff, but the entire project is made to not need to run as root, privileged etc.