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
Read this if your Mosquitto is broken #265
Comments
References: * [Mosquitto doc](https://mosquitto.org/documentation/migrating-to-2-0/) * [Workaround](SensorsIot#265) * [IOTstack new menu breaks Mosquitto configs](SensorsIot#258 (comment)) * [Pull Request on gcgarner/IOTstack](gcgarner#228) Mosquitto 2.x has introduced a requirement for a `listener` in the config file. If this is absent, Mosquitto will bind to the loopback interface. When Mosquitto is running in a container, this implies no connectivity. Mosquitto 2.x has also changed the security defaults. Earlier versions permitted passwordless access out-of-the box. The new version assumes a password scheme will be implemented and requires passwordless access to be an explicit configuration choice. This PR maintains the IOTstack status quo by: 1. Adding `listener 1883`; and 2. Activating `allow_anonymous` with the value `true`. Anyone who has already set up a password scheme will need to import the `listener` line but, presumably, their `allow_anonymous` will already be active and set to `false`, and that will not need to change.
Hi, and thanks for sharing! I searched all the internet what is going wrong before read this issue here! :) I've managed to fix the issue by using the configuration method described above. Please update instructions for users that have previously implemented a password scheme for Mosquitto. |
Thank you for this post @Paraphraser! I searched and tried for hours before I stumbled on you advise and could fix the problem in seconds. Of the two options I would strongly suggest the second one, adjusting the configuration, because that way you solve the problem for good, if you switch back to 1.6 this problem will pop up again in the future. |
@wijnsema the truly cool thing (or, at least, I think it is cool) about Docker is how easy it is to revert. Sure, once you know a solution to a problem, it is definitely better to fix it properly. But, if something has just gone pear-shaped, reverting to "last known good" lets your IOTstack keep truckin' and your IoT devices sending their data. You then have the luxury of breathing, thinking, and taking your time. You might, for example, want to test that the fixes you've found in a GitHub issue actually work on a test system before you put them into production. After all, there's no guarantee that they are correct for every IOTstack user's situation. 🤪 Granted, reverting doesn't always cure every evil. There was a PiHole fiasco a few versions back where the upgrade didn't work but did sufficient "damage" to the database in PiHole's volumes folder that reverting didn't work either. At least, not straight away. It took a combination of reverting and restoring PiHole's volumes folder from backup to get going again. |
@Paraphraser indeed Docker is wonderful, it really changed the IT landscape, but I will not use Regarding fix/upgrade, it really depends on the situation. In mine, I just started with Iotstack so I want the newest versions. Now up to my next problem, timescaledb fails to start after the docker pull, when it worked before (Segmentation fault, no idea were that comes from). Anyway, have a nice day (or evening). |
@wijnsema I may be slightly more gung-ho with the PULLs because I run a test system in parallel with the live system. In fact, one of the main reasons why I developed Paraphraser/IOTstackBackup ahead of the game was so that I could guarantee that my test system's data and config was reasonably close to the live system. I always do a "apply mild vacuum and witness the result" on the test system before trying it on my live system. I'd be a heckofalot more cautious if I only had a single Pi to work with. 😎 |
@Paraphraser looks perfect. Keep up the good job guys, you really helping us a lot! |
Thanks for the quick fix!! Really saved me! Best regards, |
Thanks for sharing! |
Mosquitto quick fix
If you have just upgraded Mosquitto by doing:
and find that Mosquitto is no longer working, you have two options for getting your IOTstack working again:
Pin to version 1.6.12
Edit the mosquitto service definition in
docker-compose.yml
to pin to version 1.6.12. Something like this will get the job done:Repeat the upgrade process:
Mosquitto will downgrade to the previous version and resume its previous behaviour.
Edit the configuration file
The default configuration file for Mosquitto looks like this:
The active version of the configuration file is at the path:
You need to make the following changes to the active file:
Add this line (anywhere in the file):
If and only if you have not implemented a password scheme for Mosquitto then
allow_anonymous
will still be commented-out. You need to change it to look like this:If you have previously implemented a password scheme for Mosquitto then
allow_anonymous
will be active andfalse
, and should be left that way.After you have edited the configuration file, apply the changes by doing:
Mix-and-match
The configuration file changes described above are compatible with 1.6.12 so you can apply them while 1.6.12 is running, and take the decision to upgrade to version 2.x later.
Known issue with IOTstack Mosquitto configuration file
Under new menu (master branch), there is a known issue 258 where the active version of the Mosquitto configuration file can be overwritten by a menu run. Keep this in mind and make a backup.
Reference
See Migrating to Mosquitto 2.0.
The text was updated successfully, but these errors were encountered: