On 03/27/2017 01:21 PM, Laurent Vivier wrote: > When the VM is used behind a firewall, This allows > to use a SOCKS5 proxy server to connect the VM IP stack
"allows to $verb" is not idiomatic English; the correct forms are
generally "allows $subject to $verb" or "allows ${verb}ing". In this
case, I'd lean towards "this allows the use of a SOCKS5 proxy server"
> directly to the Internet.
>
> This implementation doesn't manage UDP packets, so they
> are simply dropped (as with restrict=on), except for
> the localhost as we need it for DNS.
>
> Signed-off-by: Laurent Vivier <laur...@vivier.eu>
> ---
> +++ b/qapi-schema.json
> @@ -3680,6 +3680,9 @@
> '*ipv6-dns': 'str',
> '*smb': 'str',
> '*smbserver': 'str',
> + '*proxy-server': 'str',
> + '*proxy-user': 'str',
> + '*proxy-passwd': 'str',
Why can't we spell this out as password, instead of abbreviating?
Should this hook into the "secrets object" framework so that someone
does not have to pass the password in plaintext?
> '*hostfwd': ['String'],
> '*guestfwd': ['String'] } }
Missing documentation.
Do we want all three proxy elements to be in a substruct? The difference
is between:
{ ... "smb": "foo", "proxy-server": "bar", "proxy-user": "noone",
"proxy-passwd": "hello" }
and a substruct:
{ ... "smb": "foo", "proxy": { "server": "bar", "user", "noone",
"passwd": "hello" } }
>
> +@item
> proxy-server=@var{addr}:@var{port}[,proxy-user=@var{user},proxy-passwd=@var{passwd}]]
Yes, you DEFINITELY need to hook into the "secrets object" framework to
avoid having to pass a password in plaintext on the command line. Dan
Berrange may have more advice on doing that.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
