-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docker eclipse-mosquitto:2.0 Error: Address not available #2040
Comments
geeze im glad i found this. i tried to pin the 2.0.5 image as well in my docker-compose yaml and your message made me think it had to do with changing the tag. i rolled back to 1.6.12 for the time being. 2.0.5 is giving me an error that i had suspected was from the mosquitto daemon possibly running in the background somehow though i could find no evidence supporting this. |
Mosquitto 2.0 binds to the loopback interface if you don't provide a Full details on moving to 2.0 are here: https://mosquitto.org/documentation/migrating-to-2-0/ |
Is there any way this can be the default for the docker image, for example an environment variable that is set by default in Dockerfile and detected by the mosquitto server? It is somewhat inconvenient to mount a config in the container just to get it to work, the previous version worked fine without any configuration. Recently the :latest tag (which I admittedly shouldn't have been using) was switched from v1 to v2 and it broke my setup. |
@Derkades I'm sorry to hear it broke your setup. The breaking changes have been advertised for the past two months, and the change of the Security is by its nature a bit inconvenient. The aim of the breaking changes is to require people to actively think about how they are securing their broker. If they want to allow unauthorised access, so be it, but it definitely shouldn't be the default. |
We are using docker image as gitlab CI service in this scenario we can not expose port to host but using container to container communication. Current version image prevent this. |
Yes, and I fully realize it is my mistake for using a :latest image instead of pinning a specific version.
In the case of docker the problem is not that the default config is inconvenient or more secure, but it broken for nearly all use cases (connecting to it from another container or from outside docker). Applications in docker are expected to listen on all interfaces. As @TomasVojacek said the documentation on docker hub does not mention |
Thank you for this change, it made me notice:
This gave me the excuse to tighten up security a bit and add some basic monitoring so that I don't spend two days figuring out why my Zigbee switches don't work :D |
I also found this in a docker container loading up on another node. Thus far, I haven't figured out how to pass instruction to the daemon to bind on a public interface without loading in a whole |
While I think it's a great idea to bind to the loopback interface by default, I do agree with others that the docker container documentation could at least reflect this. The official image documentation has no mention of needing a listener: https://hub.docker.com/_/eclipse-mosquitto , and the docker documentation in this repository also makes no mention: https://github.com/eclipse/mosquitto/tree/master/docker/2.0 If people follow these instructions, they end up with an unreachable mosquitto instance inside a container. While there is great value in not defaulting to all interfaces on a normal system, restricting the listener to localhost inside a docker container serves no real benefit. It forces users to always define a mosquitto.conf. And even if mosquitto binds to every address within a docker container, it is still up to the user of the container to bind this port to their own network with e.g. |
@mosterdt is correct, there is no added security in having a service be loopback-only inside a Docker container. I can't even think of a use-case where that would be useful. Web servers, databases etc. become completely useless unless something can access it :) What is allowed to access the container from the outside should be decided by the container configuration when starting up. |
I'm running a mosquitto Docker container as part of a Gitlab CI for integration tests:
Passing a configuration file is much much harder than passing an environment variable. In fact the Gitlab documentation on services only has examples for how to pass configuration through environment variables. Please consider to make the listener configurable through an environment variable. |
https://hub.docker.com/_/eclipse-mosquitto doesn't document the change in mosquito config location |
The use of an environment variable was rejected by docker, but you can use the no authentication configuration that is provided:
|
nothing like a point release to break everything.. ugh |
@tablatronix AFAIK this was a major release going to It may have been latest catching up from But an unstable tag is an unstable tag and |
I don’t get it, why can’t we pass the listener configuration as an environment variable? Like we can do with MOSQUITTO_USERNAME, etc.? |
I thought I read somewhere docker wouldn't let them do that (since its an official docker image) but now I can't find where I read that so maybe I imagined it 🙃 |
you read it here: #2040 (comment) |
Yeah, I saw that comment but didn’t know why on earth “docker” would reject an environment variable. @06kellyjac Didn’t know that about official images. |
out of curiosity: binding an application to "0.0.0.0" inside of a container is like the classic localhost binding, in a way that only the host where the application is run (and other apps on that host inside a container) can access the application. Where is the benefit of running mosquitto only on localhost in a container? So far i can only see downsides. edit: or to state it differently, binding to "127.0.0.1" inside of a container means mosquitto is unusable for all users, except those with very small installations where mosquitto is used with a shared loopback interface (kubernetes inside of a pod or manually) or the user gives a f*ck about security/isolation and binds with the host network. |
For those who faced the inconvenient usage when using mosquitto image in GitLab CI, maybe you can consider using the GitLab Container Registry service to store the mosquitto images with default configuration that can listen on all the interfaces, the GitLab CI can use the images in the project's Container Registry directly. We have used this method to overcome the inconvenience. |
Why just not change the default config file so it includes |
This just bit me today. This command from above got me up and running:
@ralight why isn't this documented on the eclipse-mosquitto's docker hub page? Adding a short description of the available config files in the container would probably help a lot of people, especially if the default is going to be mosquitto running in local mode. |
Ran into same issue only to have adding My mosquitto.conf file:
Command I use to run the container:
|
Yeah, this has been raised months ago: #2040 (comment) It was added to this README here: https://github.com/eclipse/mosquitto/tree/master/docker/2.0 in this commit 12ff9d5 but the README on docker hub is either in a different location/repo or needs to be edited by hand in the Docker Hub UI. Please update the Docker Hub page @ralight because very few people are going to find that README within the docker/2.0 dir. |
Running into a lot of these issues as well with the Docker method... I saw this in
So I tried following those directions but I still get:
Trying on Rocky Linux (CentOS) 8 |
This seems to do something at least:
From here: https://github.com/eclipse/mosquitto/tree/master/docker/2.0 So I just need to figure out authentication |
Finally it worked with below properties of conf, without this, it did not work. listener 1883 Thanks |
getting the following in logs.. my conf file looks like:
`
|
Error: Address not available
The text was updated successfully, but these errors were encountered: