Breaking change: puppet UID/GID changed 999 -> 1001 in #141 with no migration path

[bootc]

Summary

#141 changed ARG OPENVOX_USER_UID / OPENVOX_USER_GID from 999 to 1001. Existing persisted data written by prior images (owned 999:999) is no longer owned by the running process, and any deployment pinning 999 breaks. This is a silent breaking change.

Affected images

• Changed in: ghcr.io/openvoxproject/openvoxserver:8.13.0-main@sha256:a9b17904f0f92e8bf29344c8dc12a5106da92d4962c5a03f359a2a15edb0c47b (post-feat: unionize Ubuntu Containerfile with the one for Alpine #141)
• Previous: …@sha256:c49843bd94e4caae5e23fcf790afb28a44629ac55f99db489df77cab7fa0b77c

Evidence

OLD:  puppet:x:999:999:puppetserver daemon:/opt/puppetlabs/server/data/puppetserver:/bin/sh
NEW:  puppet:x:1001:1001::/opt/puppetlabs/server/data/puppetserver:/usr/sbin/nologin

(The login shell also changed /bin/sh → /usr/sbin/nologin.)

Impact

• Persisted volumes (CA dir, SSL, server/data/puppetserver, reports, code) written as 999:999 become inaccessible to the new process (uid 1001) on upgrade, with no automatic remediation.
• Deployments hard-coding user: "999:999", K8s runAsUser: 999, or host ACLs for uid 999 break.
• docker exec … sh / debugging as the puppet user breaks due to the nologin shell change.

Suggested fix

Either:

1. Revert to UID/GID 999 to preserve compatibility; or
2. Keep 1001 but treat it as a documented breaking change — release notes + an upgrade step (recursive chown of persisted dirs) and a clear statement of the new shell. If the UID is meant to be configurable, document the OPENVOX_USER_UID/GID build args and the implications of changing them.

Consider whether the shell change to nologin is intentional; if debugging access matters, retain a usable shell.

Related: #148, #149 — all stem from #141.

[alexjfisher]

Is the uid of 52 only 'reserved' in Fedora/RedHat? https://src.fedoraproject.org/rpms/setup/blob/rawhide/f/uidgid#_70

I guess there's no central organisation that managed these??

[bootc]

Is the uid of 52 only 'reserved' in Fedora/RedHat?

Indeed that registry is only for Fedora as far as I'm aware. Even if we switched to that UID we'd end up breaking people's systems, and using a UID <100 in a container would make me question some choices to be honest.

[rwaffen]

stupid me. i didnt thought much about this, sry 🫣😵‍💫

[bootc]

Hah, no, I think your goals are noble... but sometimes it's hard to see how a minor change can have a big impact elsewhere.

Today I also realised it's also hard to build custom images based on the new image as things like apt-get will run as the puppet user by default now. That is probably more easily fixable by me adding a USER root:root in my Containerfile before the Apt stuff, then setting it back to USER puppet:puppet afterwards. Possibly just something to document (but I haven't tested this).

[rwaffen]

haha, thx :)

and yes, i also done things like this, switch to root on a rootless base image and then switch back... feels strange, but does the job

[rwaffen]

okay, here i see the problem again. in alpine not the uid, but the gid of 999 ist aleady taken. 999 belongs to a group called "ping" in alpine.