speedtest-cli: Cannot retrieve speedtest configuration

[CrimsonFez]

When running the docker without daemon mode, docker run -p 8000:8000 ansemjo/speedtest, here is my output:

created directory: '/data'
 * Connected database: sqlite:////data/speedtests.db
 * Serving Flask app "speedtest" (lazy loading)
 * Environment: development
 * Debug mode: off
 * Running on http://0.0.0.0:8000/ (Press CTRL+C to quit)
^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^Cb'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'

^C^Cb'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'

b'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'

b'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'

b'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'
^C^C
b'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'
b'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'

b'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'

b'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'

b'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'

b'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'

b'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'
b'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'

^C
b'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'
10.0.0.7 - - [24/Feb/2021 02:19:47] "GET / HTTP/1.1" 500 -
10.0.0.7 - - [24/Feb/2021 02:19:47] "GET /favicon.ico HTTP/1.1" 404 -
172.17.0.1 - - [24/Feb/2021 02:20:53] "GET / HTTP/1.1" 500 -
172.17.0.1 - - [24/Feb/2021 02:20:56] "GET / HTTP/1.1" 500 -
172.17.0.1 - - [24/Feb/2021 02:20:57] "GET / HTTP/1.1" 500 -
172.17.0.1 - - [24/Feb/2021 02:20:57] "GET / HTTP/1.1" 500 -
172.17.0.1 - - [24/Feb/2021 02:20:58] "GET / HTTP/1.1" 500 -
172.17.0.1 - - [24/Feb/2021 02:21:03] "GET / HTTP/1.1" 500 -
172.17.0.1 - - [24/Feb/2021 02:23:19] "GET / HTTP/1.1" 500 -

As you can see, CTRL+C doesn't quit. In addition I get this on the web page:

No measurements taken yet!
(sqlite3.OperationalError) no such table: speedtest
[SQL: SELECT * FROM speedtest WHERE "Timestamp" IS NOT NULL ORDER BY "Timestamp" DESC LIMIT ?]
[parameters: (1344,)]
(Background on this error at: http://sqlalche.me/e/e3q8)

[ansemjo]

Indeed, CTRL+C was not handled correctly. (For reference: the message "Press ... to quit" is printed by Flask automatically because it assumes you're running in a shell. This was not added by me.) ~I added a small signal handler and do not "exec" crond anymore, so the signals should be forwarded properly now. You'll still need to run the container with -it, though, if you plan to keep it in foreground like this.~ I've added tini, which is a tiny init, to handle signals inside the container and terminate processes. So CTRL+C should just work now, with or without -it.

Also, another sidenote: if you have over containers that refuse to handle CTRL+C even when you're running with -it, you can add --init, which wraps the processes in the above tiny init program. This is supposed to handle signals correctly and kill & reap processes inside the container.

---

The "error" you see on the web page is actually expected, since no measurements have been taken yet and dataset is only lazily creating the tables on first writes. That's what the first line is about. I've added a clearer message in d78f48e.

---

What is actually interesting, is the repeated error about speedtest configurations ...

b'Cannot retrieve speedtest configuration\nERROR: <urlopen error [Errno -3] Try again>\n'

I am not entirely sure what that is about but grep'ing in my sources, this error seems to stem from speedtest-cli. On a second branch I had replaced it with another tool that fixed other problems as well (see #4). That branch is now merged into the main branch and the Docker container ansemjo/speedtest has been rebuilt with that. Please pull the image again and check if the error still persists.

[CrimsonFez]

after pulling the new image...

---

docker run -it -p 8000:8000 --name="speedtest" ansemjo/speedtest fixed my unable to exit issue.

---

I'm able to access the web page with this result.

No measurements taken yet!
Please wait for cron to trigger a measurement or start one yourself with 'speedtest-plotter measure'.

(sqlite3.OperationalError) no such table: speedtest
[SQL: SELECT * FROM speedtest WHERE "Timestamp" IS NOT NULL ORDER BY "Timestamp" DESC LIMIT ?]
[parameters: (1344,)]
(Background on this error at: http://sqlalche.me/e/13/e3q8)

When I run docker exec speedtest speedtest-plotter measure it results in Unable to retrieve your IP info. Try again later

docker run -it debian and inside the container cat /etc/resolve.conf returns the correct dns server for the network, 10.0.0.1 ip a returns the correct ip for the container, yet ping 10.0.0.1 doesnt go through

This looks like an issue with my docker setup. I think the only reason I can access my other containers sites and the speedtest-plotter site is because they have ports specified. And any traffic not on those ports is dropped.

I used the --net=host as the first answers states here in running my docker containers and they can now talk on the internet. Now when I run docker exec speedtest speedtest-plotter measure, the site works properly as far as I can tell.

---

This solution could be a security issue, right? Giving the docker full access to the network devices on the host. Is there a better way to handle this?

[ansemjo]

Indeed, this sounds like a firewalling issue to me. I am afraid I cannot assist you further with that, without knowledge of your particular setup.

No, using --net=host is not a security issue per se. By default, Docker drops a lot of capabilities when creating containers; simply having access to the host network interfaces does not mean you are able to manage them yet. Not even when you're root inside the container .. to do that, you'd additionally need to pass --privileged. But you should only ever do this if you know why this is necessary and there is no other way. I am not currently aware of any issues that might facilitate easy container escapes but there have been such vulnerabilities in the past, when processes had access to namespaced network interfaces. To mitigate some of those you could use additional defences like User Namespaces or Rootless Containers.

Running containers in seperate namespaces mostly ensures separation between containers or pods. In the case of speedtest-plotter it might even be argued that using --net=host is beneficial because it avoids one layer of packet forwarding and is therefore closer to the true line speed. I'm not sure how big of an impact this could realistically be though. :shrug:

In fact, I run all my containers on a rootless Docker daemon locally. On CentOS servers I mostly use podman where possible, which makes running rootless really easy.

---

I'll close this issue, since it does not appear to be an issue with this project but rather your particular networking setup. Feel free to comment with further questions of course.

[CrimsonFez]

Thanks for the help! For one of my other projects I will be giving users ssh access inside containers. Would a user be able to log packets and such with --net=host set?

[ansemjo]

This is beginning to be off-topic. But here goes:

I don't think that should be possible without also passing --privileged – at least trying to launch tshark in a container with --net host but without --privileged fails with:

tshark: Couldn't run /usr/bin/dumpcap in child process: Operation not permitted

However, only because I don't know how to do it, that doesn't mean there is no way to do it. ;)

Regardless, giving users access to a shell inside containers sounds like the network namespacing should be the least of your worries because giving users interactive access to a container is probably one of the worst threat models to begin with. Some things to think about:

• Do you want to firewall services on your host against the users in the containers? If so, you should use a seperate network. E.g. prevent users from attempting to connect to sshd on the host.
• Shall all users use the same outside port? If you use the host network for everyone, two containers cannot share the same port – for, I hope, obvious reasons.
• Drop even more capabilities than the Docker default.
• Don't let the users be root inside the container.
• Ideally use separate User Namespaces for each user / container.
• Maybe even use a stronger layer than Linux Containers and use lightweight virtual machines, e.g. Kata Containers or Amazon Firecracker. Afaik both can be used as a "runtime" in Docker, so they're managed just like you're used to.

[CrimsonFez]

Thanks for the advise. Kata Containers might be a better option for what I'm trying to do.