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

Andrea Bolognani abologna at redhat.com
Wed Jul 15 14:11:22 UTC 2020

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.


> > Going back to the name of the command itself, since it's an internal
> > implementation details, and as such it's not intended to be invoked
> > by users and accordingly we're installing it under $(libexecdir)
> > along with existing helpers, what about following the established
> > naming convention and calling it 'libvirt_proxyhelper'?
> Installing it to libexecdir is actually a mistake in this version. It
> needs to be installed into bindir, as it must be present in $PATH.

Why is that so? Is it because otherwise we can't guarantee that ssh
on the remote end will find it, seeing as $(libexecdir) can be
changed at configure time and is usually not part of $PATH anyway?

If the binary will show up in $PATH, then I think it's even more
important to ensure it's very apparent that it's for internal use
and not to be invoked directly. Including a message explaining this
in the help output as well as the usage message that is printed when
a URI is not passed on the command line would be a great start.

As for the name of the binary itself, longer and more descriptive is
clearly better to avoid confusion. What about 'virt-proxy-helper'?

Andrea Bolognani / Red Hat / Virtualization

More information about the libvir-list mailing list