Re: [mosquitto-dev] config file questions

[Greg Troxel <gdt@xxxxxxxxxx>]

Roger Light <roger@xxxxxxxxxx> writes:

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

Packaging systems handle configs differently, but pkgsrc's way is to
install the configs/examples from the upstream source into
e.g. /usr/pkg/share/examples/mosquitto/mosquitto.conf.  This file gets
updated when you update the package, and it's wrong for a user to change
it.   Also, if the package maintainer codes that an example should be
installed, then it is copied to /usr/pkg/etc/mosquitto.conf.  On update,
if it is unmodiifed, the new version is installed, but once modified it
is not touched.

This all seems to me like the right thing (but then it would), and it
leads me to a style where config files are small and contain only
non-default information, with defaults being implicit in the program

So would you be willing to change the repo to make mosquitto.conf to
mosquitto.conf.example, like the others?

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

It's not hard, but it surprised me when I started it by hand.  It's not
a big deal, but to me it's a question of following the traditional
norms, so that people with well-tuned expectations are not surprised.

Certainly having -c foo as a command-line argument to use a different
config file is totally sensible, and also very normal.  I only meant
that when there was no -c argument, the choice to not read a config file
instead of what to mean is the obvious expected behavior of reading the
standard config file.

Separately, I would expect that the mainstream use case is to run one
instance, but I could well be off.

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

There are two separate issues, one easy and one hard.  The easy one is
that if there is a directory built in to the binary as the default, then
it should be described in the man page and the example config the same
way.

The hard one is adjusting defaults to make sense.  In pkgsrc there is a
notion of VARBASE which is basically /var, and that things like this
shoudl be /var/db/mosquitto.db, or if necessary due to permissions,
which I think is rue, /var/db/mosquitto/mosquitto.db.  Here, I think the
way to go is to have a --vardir or some such option when one calls
./configure (to use the autoconf language).  But, another approach is to
have the default be empty and thus the feature not available until
explicitly configured.

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

I would suggest the following quick edits:

  rename from mosquitto-tls to mosquitto-certs

  add insert at the beginning

    When using TLS, the server is expected to have a certificate, and
    clients can either use client certificates or passwords.  This man
    page explains how to make your own certificates, for those not using
    an established Certificate Authority, either Internet-wide or
    organizational.


[separate messages to follow about the more complicated topics]