Re: [libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling
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.
> 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