On 3/26/20 3:15 PM, Richard W.M. Jones wrote:
> +# Run nbd plugin as intermediary; also test our retry code
> +start_nbdkit -P "$pid2" -U "$sock2" --tls=off nbd retry=5 \
> + tls=require tls-psk=keys.psk tls-username=qemu socket="$sock1"
> +
> # Run encrypted server
> start_nbdkit -P "$pid1" -U "$sock1" \
> --tls=require --tls-psk=keys.psk example1
>
> -# Run nbd plugin as intermediary
> -start_nbdkit -P "$pid2" -U "$sock2" --tls=off \
> - nbd tls=require tls-psk=keys.psk tls-username=qemu socket="$sock1"
> -
> # Run unencrypted client
> qemu-img info --output=json -f raw "nbd+unix:///?socket=$sock2" >
nbd-tls-psk.out
>
> --
It's worth a try, so ACK.
It might be nice to add a comment into the test so we know why it's
running the nbdkit instances in an unexpected order.
I did a bit more tweaking (hoisting the qemu-img info process to start
prior to the encrypted example1 server, to better prove that retry is
letting clients connect to our bridge before our bridge can get through
to the server), and pushed.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org