I am working on my first Docker deployment and run into issue which I have tried to resolve from several hours.
I have a bash script in Docker and want to run it on host, not in the container. Why? I am not able to resolve the issue with sudo inside of Docker, I mean each time I got errors when I try to execute that script in the container:
sudo: unable to stat /etc/sudoers: Operation not supported
sudo: no valid sudoers sources found, quitting
sudo: error initializing audit plugin sudoers_audit
So I thought, that I run the script from the host to ommit those issue on Docker? If it works like that ⊠Since on the host it works without any issues.
As for sudo, it can be configured in docker images as well, although it usually doesnât make sense, so the question is not if you can run a script in a container but where you need to run it.
About the first one, why it does not make sense to use sudo inside of a container? Just for my knowledge.
Regarding the second one, I need to run that script in the container but it was written like that to call out âsudoâ several times and thatâs why It can not be executed. Give me the hints
If all you need to do is run a script that requires sudo inside the container then one solution might be to simply install sudo in the image before running the script. Depending on your base image, it goes something like this:
FROM ubuntu:latest
RUN apt-get update && apt-get install -y sudo
RUN script_that_needs_sudo.sh
If the image you are using isnât running as root you would need to use USER root before installing sudo and then switch back to whatever user the image is using.
Because you can run the container on behalf of any user. Including root which doesnât need sudo.
If you install sudo in a container and run the container as a non-root user that user has to be in the sudo group.
You also need to configure sudo to work on at least the script you want to run without password (passwordless sudo). Depending on what that script does it could be dangerous.
If the script uses sudo just to run some commands as a non-root user (sudo -u ubuntu -H whoami) thatâs okay. If this is the case, you really need sudo and you can run it as root. If it is not the case and sudo is used to gain root access and if the container is running as root, you can just add a simple script to the path called sudo which only executes the arguments
#!/usr/bin/env bas
exec "$@"
so you donât need to install sudo.
When someone develops a new application, I heard about using gosu rather than sudo.
You can read in the readme why gosu exists. Since you are using an existing script, I guess you need what @rofrano suggested or the short script that I suggested using exec to run any command as is (only if the container is running as root and you donât want to run those commands as an other user.).
Yes, in fact script calls out several times âsudoâ and I would like to run it as root but I do not know why the script does not work like on my Host:
sudo works in the fedora:37 container. If you could share
how you create the container
on which operating system,
and the output of docker version
that could help a lot to find out what causes your issue.
Your first post already showed that the container had sudo installed, but I thought you tried it with a non-root user. Later I forgot about the first postâŠ
Docker versions before 20.10.9 are known to be incompatible with newer linux distributions (in containers), but this specific error message is new to me.
It is a good question, so I shed a bit light on that. If you know my goal it will be easier to support I believe
1 stage: I want to prepare my base_image based on fedora OS. Thatâs why I have configured proxy so far, install several packages, now I want to run several script and commit it.
2 stage: I want to use that image and only to change packages I want to use bash script with some variables pass to Dockerfile to tell the container which package to download.
So coming back to your question:
docker container run -it --name prep fedora:37 bash
docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4dd16c323895 fedora:37 âbashâ 43 hours ago Up 43 hours prep
docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
fedora 37 95b7a2603d3a 3 weeks ago 184MB
docker version
Client: Docker Engine - Community
Version: 20.10.17
API version: 1.41
Go version: go1.17.11
Git commit: 100c701
Built: Mon Jun 6 23:03:51 2022
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.17
API version: 1.41 (minimum version 1.12)
Go version: go1.17.11
Git commit: a89b842
Built: Mon Jun 6 23:01:32 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.6
GitCommit: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
runc:
Version: 1.1.2
GitCommit: v1.1.2-0-ga916309
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Thanks for reminding me. I donât have a Fedora host. Can you check if it works for you on a debian based host for example? To be honest I donât know why that would matter, unless sudo sends some syscall that is not supported on your fedora host, but I donât have more ideas.
Update:
I had a CentOS host. Sudo worked on that too in the fedora container. Then I tried to enable selinux. I had to reboot the VPS and now I canât login. No problem, I already cancalled that VPS thatâs why I tried this setting, but you can try to check if your fedora host has selinux enabled:
sestatus
I donât know if that can affect sudo in the container.
update 2:
I managed to login using VNC instead of SSH and sudo still worked in the container.
