'weave env' became less useful when we stopped using tcp socket

[bboreham]

This sequence of commands (found in the README) will now fail:

host2$ weave launch $HOST1
host2$ eval $(weave env)
host2$ docker run --name a2 -ti ubuntu
Post http:///var/run/weave.sock/v1.19/containers/create: dial unix /var/run/weave.sock: permission denied. Are you trying to connect to a TLS-enabled daemon without TLS?

If you then try to fix the problem by running as root,

host2$ sudo weave launch $HOST1
host2$ eval $(sudo weave env)
host2$ sudo docker run --name a2 -ti ubuntu

the third line runs the container without going via the proxy and hence without attaching to weave.

The reason is that sudo does not pick up the environment variable from weave env.

[rade]

IMO, our docs should never ever show sudo <command>. Only ever sudo -s.

[rade]

And maybe stick a prominent warning in the docs.

[errordeveloper]

@bboreham isn't this just down to the fact that permission of weave.sock is not the same as docker.sock or, even, docker.sock wasn't there in the first place and weave launch talke to the daemon via a TCP socket?

[errordeveloper]

@bboreham also, in the second part, I am not sure why you put sudo in front every command...

[errordeveloper]

IMO, our docs should never ever show sudo <command>. Only ever sudo -s.

@rade I like this approach, although there is still a separate issue with secure_path not including default path of weave script that is documented...

[rade]

@bboreham I don't think @bboreham's example is accurate. I cannot think of a situation where that command sequence would have worked previously and now doesn't. The proxy will only choose to listen on a domain socket if that is how the user is interacting with docker. If they were able to do so w/o using sudo, then surely that should also work for the weave socket.

[rade]

I think the following would have worked previously, but now doesn't?

host2$ sudo weave launch $HOST1
host2$ eval $(sudo weave env)
host2$ docker run --name a2 -ti ubuntu