Runaway Internet Upload about openaudible_docker HOT 5 CLOSED

Strange. And a little scary.

OpenAudible doesn't upload anything. But the openaudible docker uses an entire linux subsystem called WebTop https://github.com/linuxserver/docker-webtop that we don't have much to do with. Its cool and we haven't heard of any problems. The source code is about 4 small files.

Sounds like something is wrong.. and I don't like the sound of it.

A few things...

The OpenAudible docker container shouldn't be doing anything unless you started it with the web browser, then connected to audible, then turned on automatic downloads.. or after connecting, you said "yes" to the dialog that asks if you want to download your books. Even then, it should just act as if it were going to the audible web site to download your aax files. And it would be downloading traffic and almost no uploading of traffic.

In fact, if you haven't connected to http://your_docker:3000, OpenAudible hasn't even been installed.

(Question: Did you view the web interface for the docker container, thus triggering the install and start of the latest version?)

I suspect it is something else other than OpenAudible.. either the linux it is built on is doing something strange..

Your dream machine should be able to tell you the network traffic -- we don't "upload" anything. We download your books if you decide to do it. I am curious what the network traffic is..

A few things to check:

You can turn on DPI on your dream machine to see what IP is creating the traffic and hopefully what it is connecting to.

docker logs -f openaudible # (get logs from openaudible)

or

docker inspect  --format "$(curl -s https://gist.githubusercontent.com/ictus4u/e28b47dc826644412629093d5c9185be/raw/run.tpl)" openaudible

you can look at container netowkr traffic:

CONTAINER_PID=`docker inspect -f '{{ .State.Pid }}' openaudible`
watch cat /proc/$CONTAINER_PID/net/dev

I am running the latest now.. and not seeing anything unusual.

Because the whole docker container includes an entire linux, you could... start the container, browse to IP:3000
If it is running, see if it is downloading books. (Library Status: Downloads:)

Right click the desktop and bring up Terminal.
From there you can use top or iftop to see what is running.

sudo apt update && sudo apt install iftop -y && sudo iftop

If you do more digging.. let me know what you find. Which version of of OpenAudible got started (that tells you if/how long ago it was installed.)

Thanks for the report -- the video helped...

Good luck and I hope you figure it out.

from openaudible_docker.

yeah, i was quite perplexed. Glad I am not missing anything plainly obvious. I'll do some more troubleshooting when taking down the network will only affect me...LOL

I will report back.

As a side note: I run Watchtower which tries to keep all my Docker containers up to date, but even when that starts up, it does not try to download any new images until 24 hours afterwards, so I do not think that was the culprit

from openaudible_docker.

(Question: Did you view the web interface for the docker container, thus triggering the install and start of the latest version?)

Answer: No I had not.

from openaudible_docker.

Ok. So OpenAudible in all likelihood hasn't been started.. so it might be the linux system that runs on.

Let me know how you started the openaudible container and that port 3000 is the only port open.

Because the container is running a linux server with no real password security, it would be pretty trivial someone/some program with docker access to exec into the container and do whatever they want -- albeit inside of a docker container that is somewhat sandboxed from the rest of your network. (If you had docker access, you could just pull a random malware dockerfile and run that..)

But if you started the container with -network=host (an unlikely and bad idea) you would have a totally open linux server on your network. Which would be bad.

BUT if you also used a reverse proxy or port forwarding to open port 3000 to the world, that would be bad too.. since there is no password. Anyone could log in, open the GUI terminal, and do what they want. (Yikes.)

Lastly, looking at the docker info, there is also a port 3389/tcp that says "expose" but not sure what that means if it isn't exposed during the run command. Maybe available to other containers?

Be safe.

from openaudible_docker.

@openaudible Following up on this. But I tried to troubleshoot this more as best as I can with my technical skills. I could not triage down to any specific thing.

So I told Portainer to rebuild the container, and then turned it back on. The issue is now gone, and the app is working as expected. I think it is safe to say we can close this

from openaudible_docker.