On 05/10/2016 12:06 PM, Erik Swanson (eriswans) wrote:

...

On May 10, 2016, at 05:48, Daniel J Walsh dwalsh@redhat.com wrote:

On 05/09/2016 07:38 PM, Erik Swanson (eriswans) wrote:

...

...

On May 9, 2016, at 07:54, Lokesh Mandvekar lsm5@fedoraproject.org wrote:

• /usr/bin/docker is a script which execs /usr/bin/docker-current (v1.9) or /usr/bin/docker-latest (v1.10) based on what $DOCKERBINARY is set to.

Too late (or wrong forum?) perhaps, but this split is very distressing to me as an end-user because it breaks the use case of bind-mounting the docker client binary and socket into a privileged container, a pattern which otherwise would work on basically every Docker-host OS out there regardless of Docker version.

— Erik Swanson

Yes we had not thought about this. I guess you would need to volume mount docker and docker-current or docker-latest into the container.

(And whatever envionrment/configuration the /usr/bin/docker stub uses to decide which to execute, as well.)

Currently, I can tell people to bind-mount /usr/bin/docker and the socket, and it’ll work *everywhere*. With this change, I’ll have to document a ridiculous matrix of how to launch a docker-using privileged container, varying on the host OS and the version of the host OS (and what version of Docker they’ve elected to use).

Well not quite everywhere since docker is not static linked. If you volume mount in docker-current or docker-latest it will work.

docker run -v /usr/bin/docker-latest:/usr/bin/docker -v /run/docker.sock:/run/docker.sock ...

Will work.

The assumption of /usr/bin/docker being a self-contained(-ish) binary guaranteed to be compatible with the running daemon’s socket isn’t entirely uncommon: A quick google search for “-v /usr/bin/docker:” shows ~1670 results, all of which are going to be broken by the eccentric change of making /usr/bin/docker a stub (or a symlink).

(Is there a more appropriate venue for this concern/appeal?)

Open a bugzilla on this.

— Erik Swanson