Indeed it does! I just ran a complete test with this on the server:
socat TCP-LISTEN:8443,fork UNIX-CLIENT:/var/lib/lxd/unix.socket &
and this on the client:
socat UNIX-LISTEN:/var/lib/lxd/unix.socket,unlink-early,mode=666,fork
TCP:10.43.42.59:8443 &
After two or three runs lxd locks up
Unless we get more justified request (performance in safe environment
like yours), I'd rather we don't make it easy for people to configure a
completely unsafe LXD.
I'm a bit worried of people jumping on such an option as an alternative
from writing code that talks to our unix socket (for local
For those not aware, having access to the LXD API is basically
equivalent (straightforward path) to root on the physical host, so it's
something which must be very closely guarded. I have no doubt that
Martin knows what he's doing and I'm happy that socat makes it
reasonably simple to do what he
Sounds perfectly reasonable, so indeed, let's close this. Thanks Tycho
for the nice idea!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1538174
Title:
ways to speed up overhead of "lxc exec" on
> having access to the LXD API is basically equivalent (straightforward
path) to root on the physical host, so it's something which must be very
closely guarded.
FTR, we have an incredibly (painfully) tight firewall there, and the
Scalingstack instances are basically throwaway ones -- they run
Tycho, nice idea!
FTR, it's
sudo socat UNIX-LISTEN:/var/lib/lxd/unix.socket TCP:10.43.42.59:8443
(CONNECT expects an existing socket, and that machine doesn't even have
lxd installed, just -client). This does work for one operation, then
socat exits. So this needs some tweaking, but looks
On Tue, Jan 26, 2016 at 04:40:15PM -, Martin Pitt wrote:
> Tycho, nice idea!
>
> FTR, it's
>
> sudo socat UNIX-LISTEN:/var/lib/lxd/unix.socket TCP:10.43.42.59:8443
>
> (CONNECT expects an existing socket, and that machine doesn't even have
> lxd installed, just -client). This does work
