New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ubuntu:latest (16.04) image does not contain 'sudo', breaking old Dockerfile builds #48

Closed
priestlyemu opened this Issue Apr 28, 2016 · 15 comments

Comments

Projects
None yet
8 participants
@priestlyemu

priestlyemu commented Apr 28, 2016

have a number of Dockerfiles that are based on a plain 'FROM ubuntu'. These containers depend on 'sudo' being installed, which up until 14.04.4 the latest image had.

When 16.04 became the latest, my containers broke. While I understand I can modify my containers to use 14.04 specifically or install sudo, it seems this change might cause problems for others, so I thought I'd report it.

% docker run ubuntu:14.04.4 sudo echo foo
foo

% docker run ubuntu:16.04 sudo echo foo
docker: Error response from daemon: Container command 'sudo' not found or does not exist..

@tianon

This comment has been minimized.

Owner

tianon commented Apr 28, 2016

This was a change provided by Canonical (sudo being no longer part of their "minimal set of packages" which they're still willing to call "Ubuntu"). Additionally, using sudo inside a container is a bit strange in itself -- can you explain a little more what you're using it for, and why it's necessary?

As a side note, I'd highly recommend not relying on :latest -- that alias is going to change at every LTS here, and even more frequently for other repos, so it's not going to be a stable target for repeatable builds. 😅

@priestlyemu

This comment has been minimized.

priestlyemu commented Apr 28, 2016

I have containerized an existing environment that usually runs natively. It uses sudo and I am not in control of those scripts. I believe this would be a very common scenario for container usage.

As I noted, this isn't a huge issue for me but it seems like it would be really crappy if you had many containers that all specified an unqualified "FROM ubuntu" and now they didn't work. I guess the rule is to never use an undecorated FROM image if you don't control it.

I reported it mainly because it seemed like it might have been an oversight, and that there may be a number of other "missing" packages other than 'sudo'.

Sounds like it is behaving as planned, if not as I expected :-)

@tianon

This comment has been minimized.

Owner

tianon commented Apr 28, 2016

Indeed -- you should be able to get sudo back by adding something simple like:

RUN apt-get update && apt-get install -y sudo && rm -rf /var/lib/apt/lists/*
@bboreham

This comment has been minimized.

bboreham commented May 12, 2016

I wanted to note that we hit a similar problem: we use nc for demos, so having it disappear from the docker run ubuntu "simplest possible example" is inconvenient.

Docker have the same situation at https://docs.docker.com/engine/quickstart/#bind-a-service-on-a-tcp-port. While pinning to a specific version does give a way out, pinning to an ancient version (12.10 in that case) is worrying, and any version one pins to today will become ancient over time.

Is there a suitable alternative for "mainstream docker image that can be relied on to contain a bunch of standard Unix tools" ? Maybe we should create ubuntu-fullfat ?

@tianon

This comment has been minimized.

Owner

tianon commented May 12, 2016

If you're looking for hyper-fat images, you probably want the main variants of buildpack-deps (https://hub.docker.com/_/buildpack-deps/, https://github.com/docker-library/buildpack-deps) -- it has both Debian and Ubuntu variations with a very large number of packages installed (three variants each: curl, scm, and the full libraries variant).

If they don't have nc already as a transitive dependency (which needs to be verified), I'd be +1 to adding it under similar justifications to procps (docker-library/buildpack-deps#38).

@bboreham

This comment has been minimized.

bboreham commented May 12, 2016

Aha! Thanks for the suggestion.

$ docker run -ti buildpack-deps
root@b2bd59e85828:/# nc
bash: nc: command not found

I have to say, even if this were not the case, I'd probably blanch at the 610MB download.
"Be careful what you ask for" 😃

@tianon

This comment has been minimized.

Owner

tianon commented May 12, 2016

@bboreham

This comment has been minimized.

bboreham commented Jun 13, 2016

Just to close out my detour, I note another command we use in demos - ping - has also disappeared; my needs are nothing like a "source code management dependency" so I will not be proposing to add them to xenial-scm.

@yosifkit

This comment has been minimized.

Collaborator

yosifkit commented Jun 13, 2016

@bboreham, the debian image has ping. 😄

@tianon

This comment has been minimized.

Owner

tianon commented Aug 26, 2016

Given that this is by-design, I'm closing. 👍

@tianon tianon closed this Aug 26, 2016

@Aisuko

This comment has been minimized.

Aisuko commented Mar 23, 2017

@tianon This is userful for me ,thank you .

@anandumdas

This comment has been minimized.

anandumdas commented Mar 8, 2018

The error happens because the binary you are trying to call from command line is only part of the current user's PATH variable, but not a part of root user's PATH.

You can verify this by locating the path of the binary you are trying to access. In my case I was trying to call "bettercap-ng". So I ran,

$ which bettercap-ng

output: /home/user/work/bin/bettercap

I checked whether this location is part of my root user's PATH.

$ sudo env | grep ^PATH

output: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

So sudo cannot find the binary that I am trying to call from commandline. Hence returns the error command not found.

You can direct sudo to use the current user's PATH when calling a binary like below.

$ sudo -E env "PATH=$PATH" [command] [arguments]

In fact, one can make an alias out of it:

$ alias mysudo='sudo -E env "PATH=$PATH"'

It's also possible to name the alias itself sudo, replacing the original sudo.

Please refer to this video for step by step solution

@kingaj12

This comment has been minimized.

kingaj12 commented Apr 6, 2018

Put USER root in the Dockerfile before the sudo apt-get xxx, then you can switch back to a non-root user once all that is done.

@m3m0m2

This comment has been minimized.

m3m0m2 commented May 10, 2018

Hi, not sure if this is the right place to post, I'm having the issue that sudo is missing and cannot be installed neither on a docker image using Ubuntu 16, the URI is broken:

Step 4/28 : RUN apt-get -y install sudo
---> Running in 05ff9cfdc6c1
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
sudo
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 390 kB of archives.
After this operation, 1618 kB of additional disk space will be used.
Err:1 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 sudo amd64 1.8.16-0ubuntu1.3
404 Not Found [IP: 91.189.88.149 80]
E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/s/sudo/sudo_1.8.16-0ubuntu1.3_amd64.deb 404 Not Found [IP: 91.189.88.149 80]

E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
The command '/bin/sh -c apt-get -y install sudo' returned a non-zero code: 100

@tianon

This comment has been minimized.

Owner

tianon commented May 10, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment