Bullseye, mosquitto and authentification for remote access

Development
#1

Hi all,

as bullseye now uses mosquitto version 2.0.x, (compared to latest: 1.5.7 in buster), according to official docu and own experience, now authentification is needed:

In version 1.6.x and earlier, the listener defined by -p (or the default port of 1883) would be bound to all interfaces and so be accessible from any network. It could also be used in combination with -c.

From version 2.0 onwards, the listeners defined with -p are bound to the loopback interface only, and so can only be connected to from the local machine. If both -p is used and a listener is defined in a configuration file, then the -p options are IGNORED.

Using mostly rhasspy-mobile-app this caused some irritations after upgrading to bullseye (I use a .deb installation). For the moment, I got around that using an external MQTT server, but for the future, I’d ask for support for either authentification or “anonymous access” on the internal server.

Wrt. to bullseye, see also remark on update to the libgfortran version here

EDIT: Seems for future anonymous login an additional option has to be set as mentionned in https://mosquitto.org/documentation/authentication-methods/:

allow_anonymous true

Unfortunately, I don’t have no clue how to hand that over. Seems not to be a commandline thing but has to be inserted in the (mosquitto) configuration file, so a simple extension as https://github.com/rhasspy/rhasspy-supervisor/commit/c6e6b90bcde6df254c94d0ad9d3d836caae71f2d most likely will not do the trick…

Kind regards

Trouble with text-to-speech over MQTT
#2

/usr/lib/rhasspy/rhasspy-supervisor/mosquitto.conf

listener 12183
allow_anonymous true
pid_file /run/mosquitto/mosquitto_Rhasspy.pid
persistence false
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log

and

https://github.com/rhasspy/rhasspy-supervisor/blob/47d5a0aa84f7ab361592dd3ac0b4f4e7e35f602d/rhasspysupervisor/init.py#L242

#mqtt_command = [mosquitto_path, “-p”, str(mqtt_port)]
mqtt_command = [mosquitto_path, “-c”, “/usr/lib/rhasspy/rhasspy-supervisor/mosquitto.conf”]

might work.

Greetings Jens

#3

Big thanks for pointing at the relevant parts of the rhasspy code.

Imo using a central file should be omitted to allow coexistence for several instances of (e.g.) Rhasspy, and setting just the required single key should be sufficient as well.
So how to locate that somewhere in the “profiles” directory and redirect mosquitto call to the right place…?

#4

The conf only affects the Rhasspy instance. Additional instances on other ports (e.g. systemctl start mosquitto on port 1883) are possible in parallel. Since it is the “internal” MQTT, I put the conf in the rhasspy-supervisor directory. I think it’s a good idea to include this need in the code. The option “allow_anonymous true” and the global port 12183 cannot be specified as a start option and a conf is mandatory.

#5

For other appplications this will not cause any trouble, agreed. Maybe I’m wrong, but setting it up that way will lead to all Rhasspy instances on this server using this one and only place for any configuration.

Second argument: allowing settings in a “per profile” way would also allow more easy (and consistent) way to edit these (internal) settings.

Apart from all other stuff, also setting a full path might cause trouble in case the distribution itself presees other path stuctures (not starting in /user/lib). Things like that may also happen in the future…

#6

Oops, I didn’t mean to cause any confusion.
The example above only describes the possibility of using the internal MQTT on a Bullseye installation. This internal MQTT was previously not available on port 12183 in a configurable way.
Far be it from me to interfere in the realm of Rhasspy developers.

Greetings, Jens

#7

To be honest, I’m also not sure about how to do that sort of stuff the “right” way…
Having at least a clue -generally spoek- where to place the changes is a big step forward (besides me not having a clue how to do the coding :thinking:). Again: Many thanks for pointing to the (imo) right place in the code :slightly_smiling_face:!