SDK images should provide a path to install yum packages

[qmfrederik]

I want to increase my test coverage and include a CI job which runs dotnet test on RedHat Linux. I'm trying to use the registry.access.redhat.com/ubi8/dotnet-60 container image for this. My application depends on a couple of libraries which I want to install through yum.

The default configuration of the registry.access.redhat.com/ubi8/dotnet-60 container image is such that:

• The default user (1001) is unprivileged does not have permissions to install packages
• sudo is not installed (and the 1001 user probably does not have sudo permissions).

This means I cannot just run yum install -y ... in my CI script, but have to build a new container image, and use that image in my build script.

While I can understand the motivation for this, this is a barrier for using the UBI images, especially when you want to do a quick trying on a RedHat platform. It also does not align with the .NET SDK images Microsoft publishes, where you can just run apt-get ... (for the Debian-based images).

[omajid]

Can you share what sort of libraries you are trying to install? Do they enable specific .NET features? Or are they specific to your application?

The SDK images are designed for creating applications using s2i (eg, extra assemble scripts) using a set of policies that optimize on the side of well managed deployment (eg, no sudo, restricted permissions). This runs a bit counter to the use case of testing complex setups (involving multiple extra packages) in CI.

I wonder if using a straight registry.access.redhat.com/ubi8 image - and manually installing dotnet-sdk-6.0 and any other dependencies - will work better for your use case?

[tmds]

The default user (1001) is unprivileged does not have permissions to install packages sudo is not installed (and the 1001 user probably does not have sudo permissions).

By design the default user has no potential to become root.

Maybe podman allows us to be less strict about this? @adambkaplan @bparees can you share your thoughts?

Anyway, we won't change this for the existing images. You'll need to build your own.

You can use the .NET ubi image as a base and start your Dockerfile with USER 0. (Or pass --user 0 to podman/docker run).

[bparees]

you can always run the container as root if you want to have root permissions.

but for efficiency, it would be far better to build that new image w/ the additional packages and use that in your CI flow, rather than having your CI flow have to install the packages fresh every single time.

or even have your CI flow include a dockerfile based image build step that adds the packages.

[qmfrederik]

Thanks all for the feedback you've shared.

I often find myself writing .NET packages which are tiny wrappers around Linux libraries -- such as turbojpeg, libpng, libcap and friends. Ideally, I have a test step in my CI/CD pipeline which test these wrappers on the various Linux distros.

For Debian & Ubuntu, I can use the .NET docker images, run apt-get update && apt-get install libpng && dotnet test and be done with it. For Redhat, it's always an uphill battle to get anything done ;-).

What @omajid suggested (using a straight registry.access.redhat.com/ubi8 image - and manually installing dotnet-sdk-6.0 and any other dependencies) will work best in my case.

but for efficiency, it would be far better to build that new image w/ the additional packages and use that in your CI flow, rather than having your CI flow have to install the packages fresh every single time. (@bparees)

This depends hugely on how often you run CI. I run CI for those library wrappers whenever I make changes to those packages - a couple of spikes per year, really. It's really killing the inner dev loop if I have to first update my RH image, push that image, update my pipeline the use the updated image, and then start doing the work I really wanted to do on my .NET package :-).

By design the default user has no potential to become root. (@tmds)

I can understand this for the dotnet base image. For an SDK image, it's not uncommon to add additional build tools, so it may not be unreasonable to ask for a path for the default user to become root.

I'll leave it here, it really was one of those "ugh, RH" moments and just wanted to share my feedback with you ;-).

[tmds]

@adambkaplan @bparees are the reasons we have a non-root user in our s2i images still valid? Or are they historical?

[bparees]

@adambkaplan @bparees are the reasons we have a non-root user in our s2i images still valid? Or are they historical?

until usernamespaces are adopted by k8s, i'd say they are still valid

[adambkaplan]

Correct - and even in OpenShift, user namespaces is still in the early stages of development.

[tmds]

Thanks for confirming it is (still) necessary.