Skip to content
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

Closed
a-wing opened this issue Jan 21, 2021 · 29 comments
Closed

docker eclipse-mosquitto:2.0 Error: Address not available #2040

a-wing opened this issue Jan 21, 2021 · 29 comments

Comments

@a-wing
Copy link

a-wing commented Jan 21, 2021

docker run eclipse-mosquitto:2.0
1611227315: mosquitto version 2.0.5 starting
1611227315: Config loaded from /mosquitto/config/mosquitto.conf.
1611227315: Starting in local only mode. Connections will only be possible from clients running on this machine.
1611227315: Create a configuration file which defines a listener to allow remote access.
1611227315: Opening ipv4 listen socket on port 1883.
1611227315: Opening ipv6 listen socket on port 1883.
1611227315: Error: Address not available
1611227315: mosquitto version 2.0.5 running

Error: Address not available

@citrusvanilla
Copy link

citrusvanilla commented Jan 26, 2021

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.

@ralight
Copy link
Contributor

ralight commented Jan 27, 2021

Mosquitto 2.0 binds to the loopback interface if you don't provide a listener configuration. That loopback interface probably isn't available to your docker container, so it fails. If you add listener 1883 to your configuration it will start working happily again - but note that you also need to configure some form of authentication, or set allow_anonymous true if you don't want clients to have to authenticate.

Full details on moving to 2.0 are here: https://mosquitto.org/documentation/migrating-to-2-0/

@Derkades
Copy link

Derkades commented Feb 9, 2021

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.

@ralight
Copy link
Contributor

ralight commented Feb 9, 2021

@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 latest tag was advertised a week before it happened. I appreciate that not everyone will want to / be able to follow all of the projects they are using for changes like this, but I hope you'll appreciate we have tried to give plenty of opportunity for people to discover that there are breaking changes, and to have chance to do something about them.

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.

@TomasVojacek
Copy link

TomasVojacek commented Feb 10, 2021

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.
Can be documentation on hub.docker.com updated how to tackle this?
Or at least mention that there is this problem?
There no info about this significant change there.

@Derkades
Copy link

Derkades commented Feb 10, 2021

I hope you'll appreciate we have tried to give plenty of opportunity for people to discover that there are breaking changes

Yes, and I fully realize it is my mistake for using a :latest image instead of pinning a specific version.

Security is by its nature a bit inconvenient.

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 listener 1883 which means it won't work (--ports does not work for applications binding only to 127.0.0.1 inside the container as far as I know)

@lepinkainen
Copy link

Thank you for this change, it made me notice:

  1. How important Mosquitto is to my home automation setup
  2. How badly I'm monitoring that it's actually running 🎉

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

@stahnma
Copy link

stahnma commented Feb 11, 2021

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 mosquitto.conf and that's a file I have to pass around with a docker container and not just a ENV var. Could this be made into an ENV var so it can be handled via a runtime string and not having to pass state somehow to start the container?

@mosterdt
Copy link
Contributor

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. -p 1883:1883.

@lepinkainen
Copy link

@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.

This was referenced Feb 11, 2021
@michaelosthege
Copy link

I'm running a mosquitto Docker container as part of a Gitlab CI for integration tests:

test-mypackage:
  stage: test
  image: python:3.7
  services:
  - name: eclipse-mosquitto:1.6.13
    alias: mqtt-ci-broker
  script:
  - pytest ...

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.

@06kellyjac
Copy link

https://hub.docker.com/_/eclipse-mosquitto doesn't document the change in mosquito config location

@ralight
Copy link
Contributor

ralight commented Mar 7, 2021

The use of an environment variable was rejected by docker, but you can use the no authentication configuration that is provided:

docker run -it -p 1883:1883 eclipse-mosquitto:<version> mosquitto -c /mosquitto-no-auth.conf

denysdovhan added a commit to denysdovhan/smart-home that referenced this issue Mar 22, 2021
@tablatronix
Copy link

nothing like a point release to break everything.. ugh

@06kellyjac
Copy link

06kellyjac commented Apr 9, 2021

@tablatronix AFAIK this was a major release going to 2.0.0, not a minor or patch version bump


It may have been latest catching up from 1.X.X straight to 2.0.5 (like the OP) or something in an effort to delay the breaking change longer for latest tag followers 🤷 Just speculating.

But an unstable tag is an unstable tag and latest users need to accept that.
The tag just 2 should give most of the benefits of latest but avoid the downside of major version breaking changes

@melyux
Copy link

melyux commented May 12, 2021

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.?

@06kellyjac
Copy link

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 🙃

@Derkades
Copy link

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 upside_down_face

you read it here: #2040 (comment)

@melyux
Copy link

melyux commented May 12, 2021

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.

@salzig
Copy link

salzig commented May 14, 2021

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.

@vava24680
Copy link

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.

@Tofandel
Copy link

Tofandel commented Jun 5, 2021

Why just not change the default config file so it includes listener 1883 so it will work by default for everybody using docker ?

@mspoehr
Copy link

mspoehr commented Aug 6, 2021

This just bit me today. This command from above got me up and running:

docker run -it -p 1883:1883 eclipse-mosquitto:<version> mosquitto -c /mosquitto-no-auth.conf

@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.

@octopop
Copy link

octopop commented Aug 24, 2021

Ran into same issue only to have adding listener 1883 to my .conf file fixing the issue. Should be added as default or at least be documented on the docker hub page.

My mosquitto.conf file:

persistence false
allow_anonymous true
connection_messages true
log_type all
listener 1883

Command I use to run the container:

docker run --name mosquitto -p 1883:1883 --rm -v `pwd`/mosquitto.conf:/mosquitto/config/mosquitto.conf eclipse-mosquitto

@06kellyjac
Copy link

@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.

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.

@groovenectar
Copy link

groovenectar commented Mar 18, 2022

Running into a lot of these issues as well with the Docker method...

I saw this in mosquitto.conf which reflects some of the comments here:

#listener 1883 
#socket_domain ipv4
#uncomment 2 lines above for first run so we get LE certificates. 
#at the same time comment out all lines below. Once you have the certificate
#stop the unencrypted listener

So I tried following those directions but I still get:

mosquitto_1   | 1647606589: Opening ipv6 listen socket on port 1883.
mosquitto_1   | 1647606589: Error: Address not available
mosquitto_1   | 1647606589: mosquitto version 2.0.14 running
otrecorder_1  | ot-recorder[11]: version 0.8.8 starting with STORAGEDIR=/store
otrecorder_1  | ot-recorder[11]: connecting to MQTT on mosquitto:1883 as clientID ot-recorder-095362d0488f-11 without TLS
otrecorder_1  | Error: Connection refused
docker-recorder_otrecorder_1 exited with code 14

Trying on Rocky Linux (CentOS) 8

@groovenectar
Copy link

groovenectar commented Mar 18, 2022

This seems to do something at least:

docker run -it -p 1883:1883 eclipse-mosquitto:2.0 mosquitto -c /mosquitto-no-auth.conf

From here: https://github.com/eclipse/mosquitto/tree/master/docker/2.0

So I just need to figure out authentication

@matloob-smartmimic
Copy link

Finally it worked with below properties of conf, without this, it did not work.

listener 1883
protocol websockets
allow_anonymous true
persistence true
persistence_location /mosquitto/data
log_dest file /mosquitto/log/mosquitto.log
log_dest stdout
password_file /mosquitto/passwd
log_type all

Thanks
Matloob Ali

@sb603
Copy link

sb603 commented Jul 5, 2022

getting the following in logs..

my conf file looks like:

`listener 1883
protocol websockets
allow_anonymous false
persistence true
persistence_location /mosquitto/data
log_dest file /mosquitto/log/mosquitto.log
log_dest stdout
password_file /mosquitto/passwd
log_type all

`

`1657049490: mosquitto version 2.0.14 starting
1657049490: Config loaded from /mosquitto/config/mosquitto.conf.
1657049490: Starting in local only mode. Connections will only be possible from clients running on this machine.
1657049490: Create a configuration file which defines a listener to allow remote access.
1657049490: For more details see https://mosquitto.org/documentation/authentication-methods/
1657049490: Opening ipv4 listen socket on port 1883.
1657049490: Opening ipv6 listen socket on port 1883.
1657049490: Error: Address not available
1657049490: mosquitto version 2.0.14 running
1657049951: mosquitto version 2.0.14 terminating
1657049951: Saving in-memory database to /mosquitto/data//mosquitto.db.
1657049952: mosquitto version 2.0.14 starting
1657049952: Config loaded from /mosquitto/config/mosquitto.conf.
1657049952: Error: Unable to open pwfile "/mosquitto/log/mosquitto.passwd".
1657049952: Error opening password file "/mosquitto/log/mosquitto.passwd".
1657049952: mosquitto version 2.0.14 starting
1657049952: Config loaded from /mosquitto/config/mosquitto.conf.
1657049952: Error: Unable to open pwfile "/mosquitto/log/mosquitto.passwd".
1657049952: Error opening password file "/mosquitto/log/mosquitto.passwd".
1657049953: mosquitto version 2.0.14 starting
1657049953: Config loaded from /mosquitto/config/mosquitto.conf.
1657049953: Error: Unable to open pwfile "/mosquitto/log/mosquitto.passwd".
1657049953: Error opening password file "/mosquitto/log/mosquitto.passwd".
1657049954: mosquitto version 2.0.14 starting
1657049954: Config loaded from /mosquitto/config/mosquitto.conf.
1657049954: Error: Unable to open pwfile "/mosquitto/log/mosquitto.passwd".
```

Anyone else getting the unable to open pwfile constantly? 

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests