On 05/10/2016 12:06 PM, Erik Swanson (eriswans) wrote:
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).
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
