[libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling

[Daniel P. Berrangé]

On Mon, Jul 20, 2020 at 07:18:55PM +0200, Andrea Bolognani wrote:
> On Wed, 2020-07-15 at 16:11 +0200, Andrea Bolognani wrote:
> > On Wed, 2020-07-15 at 14:25 +0100, Daniel P. Berrangé wrote:
> > > On Wed, Jul 15, 2020 at 02:25:14PM +0200, Andrea Bolognani wrote:
> > > > Mh, that makes sense but I'm still wary of using "proxy" due to the
> > > > potential for confusion, since in this case the proxy is on the
> > > > opposite side of the connection than one would probably expect it
> > > > to be. Something like "remoteproxy" or "serverproxy", perhaps?
> > > 
> > > I don't think there's really any problem of confusion here unless
> > > someone doesn't read the docs at all, in which case they won't
> > > even know about this parameter. So I don't think using a more
> > > verbose term is any benefit.
> > 
> > Okay.
> 
> The other day I randomly realized the ssh-based transports already
> accept a 'netcat' URI parameter which can be used to point libvirt
> to a non-standard nc stand-in. With that in mind, is it really
> necessary to introduce another URI parameter? Can't we just reuse
> the existing one?

Any binary provided there needs to implement netcat syntax. The whole
point of this work is that we don't want to use the netcat syntax since
it is impossible to know the correct socket path.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|