[Feature request]: Rename local user to `openvox`

[defnull]

Use Case

I'm building my own container image based on ghcr.io/openvoxproject/openvoxserver:8 and need to run commands or fix file permissions for the user that is later owning the server process. I just assumed it is now called openvox but it is still named puppet.

Describe the solution you would like

The local user within the container should be named openvox or something neutral, not puppet. This also applies to other aspects that still default to puppet (e.g. CA_HOSTNAME). The project is no longer called "puppet", let's get rid of it.

Describe alternatives you've considered

If renaming the local user is not possible due to backwards compatibility concerns, maybe create an alias user with the same HOME and uID? Or document a stable the numeric user ID so it can be used in scripts instead? Or make the name configurable?

Additional context

I absolutely love what is currently happening with this project!

[rwaffen]

good call. i think, here in the package based container build it can come from the packages 🤔 but then again, we create it in the containerfile.... will test this and come up with a solution

[rwaffen]

as i thought, even if we create an openvox user, a puppet user with same id comes still from the packages. and this we wanna change with the next major, aka OpenVox 9.

would be a variable, to create the user with the same id, but another name be enough for your usecase?

root@bd9aef6c1445:/# grep -e puppet -e openvox /etc/passwd
openvox:x:999:999::/home/openvox:/bin/sh
puppet:x:998:998:puppetserver daemon:/opt/puppetlabs/server/data/puppetserver:/usr/sbin/nologin

[defnull]

That should work, but the home directory should also match.

I identified several places where the username is used in my entrypoint scripts:

• A lot of chown puppet:puppet calls.
• Some runuser -u puppet -- ... calls.
• Puppet tools expect $confdir to be ~/.puppetlabs/etc/puppet if run as non-root, so I have to know the home directory of the puppet (or later openvox) user. I use ~puppet for that, which expands to /opt/puppetlabs/server/data/puppetserver in bash.

All three should work fine if there is a second user with the same UID, GID and home as the puppet user, and an openvox group with the same GIU as the puppet group. Maybe also use the same nologin for security? It should be as close to the puppet user as possible.

[defnull]

That said, this is not important at all, I can just as well continue working with the existing puppet user and wait for the next major release before upgrading my scripts. I'd be fine with a wont-fix, I just wanted to point it out.

[rwaffen]

i'll leave that open, so we have a reminder. i go through all issues from time to time. (until we are famous this is still doable :D )