Re: [mosquitto-dev] config file questions

[Roger Light <roger@xxxxxxxxxx>]

Hi Greg,

> I am now thinking about configuring tls and users.  This is making me
> think that I really don't want the vast commented example as my config
> file, and thus that mosquitto.conf should be renamed to
> mosquitto.conf.example, to indicate that it's fodder to read, understand
> and take from, rather than something that should be used.

Yes, that's a reasonable position. It has the advantage that the
example config will presumably get updated on new package versions,
and that it is easier to find the configuration in the user config
file.

> 2. mosquitto does not read ${PREFIX}/etc/mosquitto.conf by default, or
> at least that's how I read the man page.  I don't know if that is really
> intended, but it seems odd to me - normally a daemon has a config file
> location, and when started with no arguments reads it.  I admit that I
> am definitely thinking it terms of the normal approach being to set up
> to run one system version of the daemon -- is that off base?

I've taken the view that it shouldn't be difficult to run multiple
instances at once, and that specifying an explicit config file makes
that straightforward. I know of people running multiple instances on a
single device for different purposes. I don't believe it's a big
problem for packages to cover the admittedly more normal situation of
running a single instance, by setting a config path?

> 3. mosquitto(8) and the default config differ about the default for
> persistence directory.

Yes, you're right. This is the Linux packaging defaults leaking into
the man page... I'm not sure what the best solution is here, perhaps
having a list of common persistence paths plus a better explanation
that this is system/packaging dependent.

> 4. The documentation for mosquitto-tls tells you to create your own
> cert.  In a letsencrypt world this seems off.  Even without, it blurs
> the notion of how to configure the user of a certificate/keypair that
> you have, and how you might go about getting one.

The mosquitto-tls man page was intended as a quick reference for the
people way back when who were asking how to create their own
certificates. It is written from that assumption, but doesn't make it
clear. It needs rewriting, but hasn't been a priority.

> The capath option does not seem to default to the system's openssl
> configuration.  That seems unexpected.  It seems I need to set capath
> separately for the server, for the server to use for validating bridges,
> and for mosquitto_sub.  I expect all of these to default to the system's
> openssl configuration, so that if e.g. I use letsencrypt, everything
> will just work.  (I'm implicitly taking the position that validation of
> mqtt and validation of https by wget, etc. should more or less be done
> the same way.)

I believe that TLS configuration for MQTT is a different situation
than for HTTPS. It is much more likely that you will want to use
client certificates on MQTT. If the system certificates were trusted
by default, then all client certificates signed by those CAs could
connect. As above, some better documentation about this and how to
enable system certificates would be good.

> I am somewhat surpised to have to create a dhparams file and point to
> it, rather than this working by default.  I don't remember having to do
> this for apache, postfix, dovecot, but I could well be wrong.  Dovecot
> seems to generate params by default at startup:
>   https://wiki2.dovecot.org/SSL/DovecotConfiguration

The advice I remember is that dhparam generation can take a very long
time, so it should be done offline. I've just tested 512, 1024, 2048,
4096 key sizes and got times of 1.2s, 1.6s, 3m9s, and 22m40s
respectively.

I've just tested Dovecot 2.3.4 and it complains that the file doesn't
exist if it isn't already there. Perhaps that page is out of date.

> 5. The "per_listener_settings" section in mosquitto.conf(5) is
> confusing.  It does not explain what it means for authentication to be
> separate per listener, and it isn't quite clear what a listener is, and
> why one does or doesn't want to use this.

Thanks, that's a good comment, I'll see about improving it.

Cheers,

Roger