Daniel P. Berrange wrote: > On Thu, Jun 18, 2009 at 12:20:40PM -0400, Jim Paris wrote: > > I'm using Debian. I've already had to switch from the > > "netcat-traditional" package to the "netcat-openbsd" package. > > Debian does already include that patch, but what a mess... > > I know the reason why it gets stuck on the server end too - after an > auth failure, the server won't kick off the client. The connection > just remains in an unauthenticated state. This allows the client to > (in theory) retry the authentication step, and gives us a little more > flexibility for any future protocol changes we might need to make. Makes sense -- it would be nice for the client to be able to retry with read-only authentication when read-write fails, without having to reopen the SSH connection. Or is that not possible, since it would require opening a different socket? > I think the best way to solve the problem of 'nc' potentially not > quitting promptly, is to simply have the remote client kill() the > SSH client pid, rather than simply closing the socket & doing > waitpid() on the SSH client. This would ensure the waitpid promptly > cleans up. Yeah, that should fix the hang. > > Since already know libvirtd is installed on the remote host, > > would it make sense to just add a new set of options: > > libvirtd --socket-connect > > libvirtd --socket-connect-ro > > that do the same thing as "nc -U" on the appropriate socket? > > Then we know it would work everywhere, and have the added > > benefit that the client wouldn't need to know the location of the > > socket. > > If we'd thought of this originally, I would certainly have done it > this way, but if we did this now, it would break compatability. ie > new libvirt clients would be trying to run a binary that does not > exist with old server deployments. It could still be done in a backwards-compatible way. Something like: ssh server "libvirtd --socket-connect || nc -U /socket" Or, if you really wanted to be nice to us Debian folks, ssh server "libvirtd --socket-connect || nc.openbsd -U /socket || nc -U /socket" (while the Debian libvirt package does depend on netcat-openbsd, there's nothing that forces the local "nc" symlink to point to the openbsd version over the traditional version, if both are installed). It's definitely messy, but it would really be nice to remove the need for the client to know which netcat to use, or where sockets are located, etc. Hmm, as I think about it more, I guess netcat is also used for VNC connections? I wonder if that could be implemented as a dynamic port forward on the existing SSH connection, which would also eliminate the need for a second connection (and having to enter the password a second time)... -jim -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list