> On May 10, 2016, at 05:48, Daniel J Walsh <dwa...@redhat.com> wrote: > > On 05/09/2016 07:38 PM, Erik Swanson (eriswans) wrote: >>> On May 9, 2016, at 07:54, Lokesh Mandvekar <l...@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). 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?) — Erik Swanson
