How to use yum when running scripts after setup

[doberkofler]

When running a custom script that uses yum to install additional packages, I get an error because I'm not root and it is also not possible to use sudo as it is also not installed. What is the proper way to add packages in a custom script?

Executing user defined scripts
/opt/oracle/runUserScripts.sh: running /opt/oracle/scripts/setup/1_packages.sh
Loaded plugins: ovl
ovl: Error while doing RPMdb copy-up:
[Errno 13] Permission denied: '/var/lib/rpm/Obsoletename'
You need to be root to perform this command.
DONE: Executing user defined scripts

[oraclesean]

Are you trying to do this in a running container? If so, try connecting as root:

docker exec -u root -it $CONTAINER_NAME bash

It looks like you're trying to do this via an entrypoint, though, and I don't think there's an (elegant) way of automating it.

Ideally, you want to avoid altering container filesystems and instead introduce changes to the underlying image. (The reason has to do with how containers use overlay filesystems to store changes to their base images. A yum install in a container can add significantly to its physical footprint. Happy to explain this further if you like!) The ideal place for a yum install is in the setupLinuxEnv.sh script under the dockerfile/$VERSION directory. The benefit is you'll now have an image that includes the added software.

If the change is a one-off, you could add sudo to the setupLinuxEnv.sh and then call sudo yum in the setup script.

[doberkofler]

I'm trying to keep the install scripts unchanged and therefore using the "user defined scripts. I understand how to use yumin general in a container but would like to understand if and how to useyum in "user defined scripts.

[oraclesean]

I get it. Without sudo and without modifying the repository, your best bet may be the docker exec with the -u root option. I can't think of another way. Sorry!

[doberkofler]

Change request: I understand but would it then not make sense to create the base images with the sudo command so we could use sudo in the custom scripts?

[oraclesean]

At face value, that seems to make sense. However, you'll notice that containers are missing packages normally included in base OS installations, including editors and sudo. It's a practice that keeps image sizes low—making them faster to transfer over networks. But it's also for security. An image isn't vulnerable to attack vectors that aren't part of the image.

One principle of containerization is that images should include everything needed to run a service and nothing more. Containers typically run at scale via automation, so there's often no requirement to edit files and, thus, no need for an editor. In the case of sudo, the base image should (ideally) include whatever packages the service ultimately needs.

Think of entrypoints as a means of painting the walls of an apartment, whereas the build is for construction. Using entrypoints to move walls requires extra permissions (permits, inspecting the electrical/plumbing, etc.), makes a lot more mess, and annoys the neighbors. Ideally, you want to build the walls in the right place at the outset.

[oraclesean]

You may also find alternative Oracle database repos better suited to your needs. If you don't want to alter the base repo/installation scripts, it includes the option of (among other things) specifying a list of RPMs as part of the image.