The libvirt SSH tunnelling support requires 'nc' to operate. The libvirt RPM does not, however, have any dependancy on 'nc'. So by default it is pure luck whether you can use SSH tunnelling after installing the libvirt package & starting the daemon. Even though we don't technically need it on the client end, I figure nc is so small we may as well add a dep to the main libvirt RPM. This ensures nc is present anywhere the daemon is.

On Mon, Dec 17, 2007 at 04:38:54PM +0000, Richard W.M. Jones wrote: > Daniel P. Berrange wrote: >> The libvirt SSH tunnelling support requires 'nc' to operate. The libvirt >> RPM does not, however, have any dependancy on 'nc'. So by default it is >> pure luck whether you can use SSH tunnelling after installing the libvirt >> package & starting the daemon. Even though we don't technically need it >> on the client end, I figure nc is so small we may as well add a dep to >> the main libvirt RPM. This ensures nc is present anywhere the daemon is. > It's an obvious +1 for this RPM dependency. > > I wonder if we should also check at configure time for the version of nc > in Debian which doesn't have the '-U' option? Even though someone might > compile on Debian but use the resulting client to connect to a Red Hat > system ... The original plan was to bundle a 'nc' replacement > ('libvirtd-cat') for people to run on the remote system. Does debian have 'socat' by chance ? # socat stdio unix-connect:/var/lib/xend/xend-socket GET / HTTP/1.1 500 Internal server error Content-length: 0 Expires: -1 Content-type: application/sxp Pragma: no-cache Cache-control: no-cache If so, we could install a 'nc' shell script which called to socat to emulate it on Debian ?