[CRIU] [PATCH 0/3] p.haul: ssh tunneling, v5

Pavel Emelyanov xemul at parallels.com
Wed Oct 29 01:03:18 PDT 2014


On 10/28/2014 01:18 AM, Ruslan Kuprieiev wrote:
> v2, use ssh tunnel by default, enhanced opts handling
> v3, send addr to the client
> v4, use rpc to send socket name
> v5, add --no-ssh option
> 
> Ruslan Kuprieiev (3):
>   p.haul: do not use getsockname() as a hash_name, v4
>   p.haul: add --port option to p.haul-service
>   p.haul: use ssh tunneling and controll it with ssh* cmdline opts, v2
> 
>  p.haul          | 17 +++++++++++++++--
>  p.haul-service  | 15 ++++++++++++++-
>  p_haul_iters.py |  6 +++---
>  ssh_tunnel.py   | 36 ++++++++++++++++++++++++++++++++++++
>  util.py         | 10 ++++++++++
>  xem_rpc.py      | 53 ++++++++++++++++++++++++++++++++++++++---------------
>  6 files changed, 116 insertions(+), 21 deletions(-)
>  create mode 100644 ssh_tunnel.py
> 

I'm still not happy with the fact the spawned ssh with port forwarding
takes time to prepare and we have to retry connecting to it.

I was today told about the paramiko package -- https://pypi.python.org/pypi/paramiko/
Isn't it better to utilize this one?

Another question -- how does this machinery works in qemu? Can you find out?

And the last thing. Our vzmigrate guys tell, that in Python it might be
MUCH simpler to do this another way. First, you connect to ssh, authorize
yourself, then generate an openssl sertificate and then use one to establish
other connections between p.haul and p.haul-service. Maybe RPC control
socket can just re-use the ssh channel, but data socket is better to work
over openssl. Can you research this too?

Thanks,
Pavel



More information about the CRIU mailing list