feat: openshift compatible containers by enabling arbitrary UIDs

[dotconfig404]

About

This PR adds support for running the container as a user with arbitrary UID.

Changes

Containerfile: default group no longer puppetdb

The default group is now root.
The default group is now set to root in order for the container to have access via group permissions to it's internal and externally managed files as any UID, as long as using the root group.

Containerfile: group = root on relevant directories

The following directories have changed their group membership to root (if they were not already):

/etc/puppetlabs
/var/log/puppetlabs 
/var/run/puppetlabs 
/opt/puppetlabs/

and their group access is mirroring the user permissions. The setgid bit has been set on these directories and their subdirectories to ensure permission inheritance.

Not entirely sure if all of these are required or if it is comprehensive.

Containerfile: USER="" in /etc/default/puppetdb

In order to workaround a check that compares the defined user in this file when using the startup scripts for puppetdb we can set the USER variable to an empty string, otherwise it will try to switch users to puppetdb.

20-configure-ssl.sh‎: no longer setting ownership on SSLDIR

if [ -w "$SSLDIR" ] && [ "$(id -un)" = "root" ]; then
  # make sure Java apps running as puppetdb can read these files
  echo "Setting ownership for $SSLDIR to puppetdb:puppetdb"
  chown -R puppetdb:puppetdb ${SSLDIR}
fi

The test will fail with users of arbitrary UID because id -un will not be able to give a proper name when the UID is not found in /etc/passwd.
We could also simplify the test instead by using id -u = 0 instead of removing this section, but perhaps it is best left up to the user to manage the permissions, especially since the container is no longer tied to the puppetdb user after this PR.

ssl.sh: set_file_perms removal

Similar logic here, we want the group to have the same permissions as users, so we should remove/adjust this.

[rwaffen]

@dotconfig404 would we consider this as a breaking change? because we changing the default user of the container?

[rwaffen]

ah now the ci is breaking:(

[dotconfig404]

need to check in a few days, am a bit swamped atm

EDIT: probably not, since the default user does actually stay the same, but the default group is changed

[dotconfig404]

Noticed that I missed the restart file instalation that prevented running the container properly. I had shadowed the logic for that in my local setup via a bind volume, so I forgot to add it. Not the Containerfile has also a replace sed to prevent the foreground from installing a restart_file.

RUN sed -i 's/^init_restart_file/#init_restart_file/' /opt/puppetlabs/server/apps/puppetdb/cli/apps/foreground

Was the CI thing related to what you posted about in slack with it having trouble because of the uppercase letters in the org name OpenVoxProject?

[rwaffen]

Was the CI thing related to what you posted about in slack with it having trouble because of the uppercase letters in the org name OpenVoxProject?

yes, exactly