Re^3: making NET:SSH quiet

Your comment talks about SSH modules as if they were all the same but they are not. There are several of them and every one has its own strengths and weaknesses and none is better than the others in all the matters.

The example provided accounts for a more robust solution, which allows for one to extend to suit their design goals

The piece of code you have posted suffer from the same problem, it may suit your needs but it is not the solution to all Perl & SSH tasks.

It has several limitations: no connection reuse, no password authentication, no passphrases, no synchronization between different workers, no command quoting, usage of highly insecure options, wrong handling of hung sessions, etc.

Also, this solution can easily be extended to Secure Copy, as this would just be another command to run.

Almost any SSH module available from CPAN already supports SCP and/or SFTP out of the box.

Really, you should get more familiar with the SSH modules available from CPAN, specially the new ones. They are better than what you think!

Comment on Re^3: making NET:SSH quiet

Replies are listed 'Best First'.
Re^4: making NET:SSH quiet by DeadPoet (Scribe) on Jan 12, 2011 at 18:36 UTC
I am more than willing to explore... The topic that I see as most interesting is wrong handling of hung sessions. Thus far, in our 2300+ server environment I have NOT come across a set of SSH options that can account for when a process becomes hung on the remote server, such as rpm, df, bdf, getconf, ioscan, flaky sshd, etc... That is why one may need to kill the process and prevent script lock. Oh please, provide an example and I will run tests. Next, I am not knocking the various authors of CPAN Secure Shell modules. These folks have done wonderful work, such as your work. But I did say: However, many of these modules can be difficult to compile on various platforms... And, one may not be able to meet the requirements needed to compile. If I remember correctly, each module that I have used ships with ActiveState Perl. Passwords and Pass Phrases could easily be addressed as the IPC::Open3 call provides STDIN, STDOUT, and STDERR. Synchronization between workers, what are they working on together? Are they working on the same server or different. Once again the %RESULTS shared hash is an example of bringing data back to the parent. However, could server(X) see server(y)'s data and act upon it, yes--the structure is shared. Could one just report on the collective information, as illustrated, yes. It is a concept and I stated adjust as needed. So now I will add to my original statement and say: Check your local listing and your mileage may vary. --Poet	[reply]
Re^5: making NET:SSH quiet by salva (Canon) on Jan 13, 2011 at 09:57 UTC
Thus far, in our 2300+ server environment I have NOT come across a set of SSH options that can account for when a process becomes hung on the remote server, such as rpm, df, bdf, getconf, ioscan, flaky sshd, etc... That is why one may need to kill the process and prevent script lock There isn't an easy and general way to handle remote commands hung. Killing the local `ssh` process is not enough as it may leave the remote processes running. IMO, the best approach is to try to identify the pid of the remote process and kill it running `kill` also via `ssh` on the remote host (setting ServerAliveInterval and ServerAliveCountMax should be enough to detect hung sessions due to connection errors). Passwords and Pass Phrases could easily be addressed as the IPC::Open3 call provides STDIN, STDOUT, and STDERR It is not that easy! `ssh` does not use STDIN/STDOUT for authentication dialogs but `/dev/tty`. Getting that right is pretty tricky. Try to do it while limiting yourself to the modules provided with ActiveState Perl or try to make it work under Windows!	[reply] [d/l] [select]