Re: [meta-virtualization][PATCH 3/7] recipes-containers/images: add app-container-mosquitto
Tim Orling <[email protected]> Fri, 03 Jul 2026 08:27:59 -0700
| Newsgroups | org.yoctoproject.lists.meta-virtualization |
|---|---|
| Message-ID | <178309247930.29524.9527654462555578401.b4-reply@b4> |
On 2026-06-12 11:06:31-07:00, Bruce Ashfield wrote:
> Hi Tim,
>
> A few comments — most are series-level patterns that show up here for
> the first time. I won't repeat them later to not waste our time
>
> On Fri, May 29, 2026 at 18:31 -0700, Tim Orling wrote:
>
> > Add OCI container image recipe for the Eclipse Mosquitto MQTT broker.
> > The image uses multi-layer mode with separate base and mosquitto layers,
> > exposes standard MQTT (1883) and WebSocket (9001) ports, and launches
> > mosquitto with its default config file as the entrypoint.
> >
> > Inherit container-nonroot-user to run as 'nonroot' with UID 65532.
>
>
>
> > +OCI_LAYERS = "\
> > + base:packages:base-files+base-passwd+netbase \
> > + mosquitto:packages:mosquitto \
> > +"
>
> [...]
>
> > +IMAGE_INSTALL = " \
> > + base-files \
> > + base-passwd \
> > + netbase \
> > + mosquitto \
> > +"
>
> Same point as 2/7 — image-oci.bbclass now folds packages: layers into
> IMAGE_INSTALL automatically (I pushed to master-next). When you respin,
> this block can go.
Removed redundant IMAGE_INSTALL in v2.
>
> > +# Workaround /var/volatile for now
> > +ROOTFS_POSTPROCESS_COMMAND += "rootfs_fixup_var_volatile ; "
> > +rootfs_fixup_var_volatile () {
> > + install -m 1777 -d ${IMAGE_ROOTFS}/${localstatedir}/volatile/tmp
> > + install -m 755 -d ${IMAGE_ROOTFS}/${localstatedir}/volatile/log
> > +}
>
> This same function appears in 3/7 (mosquitto), 4/7 (valkey), 5/7
> (nginx), and 7/7 (curl) — four near-identical copies. Worth factoring
> into a small helper bbclass (e.g. container-volatile-fixup.bbclass) that
> each recipe can inherit, or rolling it into container-nonroot-user.bbclass
> since every recipe that uses the fixup also inherits the nonroot class.
> Not blocking — but it's a smell that's easy to silence in v2.
Added container-volatile-fixup.bbclass in v2.
>
> > +OCI_IMAGE_ENTRYPOINT = "${sbindir}/mosquitto"
> > +OCI_IMAGE_ENTRYPOINT_ARGS = "-c '${sysconfdir}/mosquitto/mosquitto.conf'"
>
> Two questions about running mosquitto as our nonroot (uid 65532):
>
> 1. The mosquitto package usually creates a 'mosquitto' system user
> (low uid, varies by build) and ships a default config that
> references paths under /var/lib/mosquitto/ and /var/log/mosquitto/
> owned by that user. As nonroot we won't be the package's expected
> user. Does mosquitto -c on the stock config actually start cleanly
> for you, or did you need to tweak the conf?
>
> I assume it runs fie, since you've been testing it for a while
It turns out that in v1 we were not really running as the 'nonroot' user,
because of image-oci and container-nonroot-user both setting OCI_IMAGE_RUNTIME_UID
with ?= (which means the order of inheritance influenced the behavior). Part of
v2 changes image-oci to OCI_IMAGE_RUNTIME_UID ??= so container-nonroot-user can
'override' it (while still being a 'soft' ?= assignment).
It runs fine in both 'production' (default) and '-dev' flavors.
$ docker run --rm -it registry.yocto.io/library/mosquitto:2
1783090865: Info: running mosquitto as user: nonroot.
1783090865: mosquitto version 2.1.2 starting
1783090865: Config loaded from /etc/mosquitto/mosquitto.conf.
1783090865: Bridge support available.
1783090865: Persistence support available.
1783090865: TLS support available.
1783090865: TLS-PSK support available.
1783090865: Websockets support available.
1783090865: Starting in local only mode. Connections will only be possible from clients running on this machine.
1783090865: Create a configuration file which defines a listener to allow remote access.
1783090865: For more details see https://mosquitto.org/documentation/authentication-methods/
1783090865: Opening ipv4 listen socket on port 1883.
1783090865: Opening ipv6 listen socket on port 1883.
1783090865: mosquitto version 2.1.2 running
$ docker run --rm -it registry.yocto.io/library/mosquitto:2-dev
1783090933: Info: running mosquitto as user: mosquitto.
1783090933: mosquitto version 2.1.2 starting
1783090933: Config loaded from /etc/mosquitto/mosquitto.conf.
1783090933: Bridge support available.
1783090933: Persistence support available.
1783090933: TLS support available.
1783090933: TLS-PSK support available.
1783090933: Websockets support available.
1783090933: Starting in local only mode. Connections will only be possible from clients running on this machine.
1783090933: Create a configuration file which defines a listener to allow remote access.
1783090933: For more details see https://mosquitto.org/documentation/authentication-methods/
1783090933: Opening ipv4 listen socket on port 1883.
1783090933: Opening ipv6 listen socket on port 1883.
1783090933: mosquitto version 2.1.2 running
For '-dev' mode, the container starts as 'root' and setuids to 'mosquitto' user.
One of the other things I noticed in testing is that the 'nonroot' UID 65532
was never making it into /etc/passwd, because the base-passwd package is what
was providing /etc/passwd and the useradd/extrausers mechanism installs in
IMAGE_ROOTFS, which was not being brought into the container layers. This has
also been fixed in v2 of container-nonroot-user.bbclass.
The mosquitto.conf that is built by the recipe has all lines commented out.
In practice, end users will almost always want to provide their own mosquitto.conf.
For instance, they will probably want to require a password and access control (ACL).
Many real-world uses on target will probably want a multi-container approach, putting a
reverse proxy like nginx in front of mosquitto or running with docker-compose.
>
> 2. If persistence is enabled in the stock mosquitto.conf (persistence
> true; persistence_location /var/lib/mosquitto/), we need a
> writable /var/lib/mosquitto for our nonroot user — same flavour of
> gap the rootfs_fixup_var_volatile workaround addresses, just for
> a different path. If you've already validated that persistence is
> off in the stock conf (or that mosquitto degrades gracefully when
> the persistence dir isn't writable), a one-line comment in the
> recipe explaining the trade-off would save the next person from
> re-deriving it.
The as-shipped mosquitto.conf has all lines commented out, so persistence is not enabled.
>
> Bruce