Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re^4: SSH2 - Asynchronous Opens & Synchronous Commands

by 5haun (Acolyte)
on Apr 04, 2014 at 13:50 UTC ( #1081143=note: print w/ replies, xml ) Need Help??

in reply to Re^3: SSH2 - Asynchronous Opens & Synchronous Commands
in thread SSH2 - Asynchronous Opens & Synchronous Commands

This is an interesting proposal. I'll have to do some tests with this. Thanks. I'll report back with my findings.

Update: I'm still working on this test case. I've got something implemented using Telnet, but I need to do some more testing. I'll post code tomorrow morning.

In the meantime, how would you handle waiting for all the async open requests to complete? I this what wait_for_master is for? My current solution loops checking for $ssh->wait_for_master(1) returning true.


Comment on Re^4: SSH2 - Asynchronous Opens & Synchronous Commands
Re^5: SSH2 - Asynchronous Opens & Synchronous Commands
by salva (Monsignor) on Apr 05, 2014 at 14:14 UTC
    You have to call $ssh->wait_for_master(1) repeatedly until it succeeds:
    my %connecting = map { $_ => 1 } @hosts; while (1) { for my $host (keys %connecting) { my $ssh = $ssh{$host}; if ($ssh->wait_for_master(1)) { delete $connecting{$host}; } elsif ($ssh->error) { # handle connection error delete $connecting{$host}; } } last unless %connecting; select (undef, undef, undef, 0.05); }


      Thank you. So far, it looks like OpenSSH+Telnet will do what we need it to, although I am having to make some adjustments for the use of Telnet.

      BTW, it would be nice (i.e. enhancement request) if $ssh->error provided a message that could differentiate between password, connect, and timeout failures: I get "unable to establish master SSH connection: bad password or master process exited unexpectedly" for authentication, for connect (socket not open), and for timeout errors. I need to be able to differentiate (that was pretty easy to do with Net::SSH2). Unless you have a better test, it looks like I'll need to try a socket connect before the opens to differentiate.

        The connection and authentication phases are carried out by the OpenSSH client and it doesn't pass the cause of the failure back to the module.

        An easy to implement workaround is to redirect the output of the master ssh process to a file and then, to retrieve it when something goes wrong.

        my $ssh = Net::OpenSSH->new($host, master_stderr_file => "/tmp/ssh-std +err-$host", master_opts => ['-v'], ...);

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1081143]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (11)
As of 2014-09-02 17:40 GMT
Find Nodes?
    Voting Booth?

    My favorite cookbook is:

    Results (25 votes), past polls