What are the advantages of rsh versus Perl's Expect.pm?

Question

I have a Perl Expect.pm script that does some moderately complex stuff like packaging applications, deploying the application, checking for logs, etc. on multiple remote unix hosts.

My predecessor had written similar scripts using rsh.

Is there a better approach between the two? Or should I use something all together different?

I am guessing somebody will bring up SSH; it's basically replacement for rsh, right? Unfortunately, however SSH is not an option for me right now.

Another thing I should add is that after logging in I need to be able to SUDO to a particular user to do most of the actions on the remote hosts.

Answer 1

They do different things. Expect is a way to script what would otherwise be manual responses. rsh -- remote shell, not restricted shell, an unfortunate name clash -- allows you to run commands remotely on another system.

That said, the security holes and other disadvantages of using rsh to do remote commands, run sudo, etc, are immense.

Answer 2

Given a choice between rsh and telnet via expect, I would chose rsh. Expect scripts are fragile. All it takes to break one is someone changing the value of PS1 on the remote machine. Using rsh also prepares you for the day you will finally enter the '90s and start using ssh (since you can mostly just change rcp to scp and rsh to ssh and everything still works).

Answer 3

Another thing I should add is that after logging in I need to be able to SUDO to a particular user to do most of the actions on the remote hosts.

To address this one particular point: using rsh (or ssh) you can specify which user to become in the remote session:

$ rsh -l username hostname

There's no need to use sudo in this case. Now would definitely be the time to look into ssh due to security issues. The syntax is the same, but ssh also allows a slightly different (and I'd say better) syntax:

$ ssh username@hostname

I found expect to be too finicky, but my experience with it is not substantial.

Answer 4

I can see multiple ways of doing this:

• Expect over telnet, rsh, or ssh
  • pros: single connection, fewer escaping issues
  • cons: fragility in a changing environment
• rsh/ssh each command individually
  • pros: fewer escaping issues, more reliable in a changing environment
  • cons: each connection takes time for authentication, and, for ssh, handshaking the encryption
• rsh/ssh all commands at once
  • pros: single connection (less overhead), more reliable than expect
  • cons: fragility in maintenance especially as you get more than a handful of statements in there, escaping issues are more prevalent (escape in perl so that it's still escaped by rsh/ssh so that it's still escaped by the remote shell so that it's properly handled by the sudo'd remote shell?)
• rsh/ssh and run a script
  • pros: single connection, more reliable, more maintainable
  • cons: finding a way to get it over there (rcp/scp work, NFS works, you need to determine the best way for you).

All things considered, this is the most minor con as you could simply do something like

 open my $fh, "|ssh user@host 'cat > /tmp/myscript'";
 print $fh $script;
 system qw(ssh user@host), "chmod u+x /tmp/myscript; /tmp/myscript; rm /tmp/myscript";

Of course, you'd add in some error handling (failed open, what if /tmp/myscript exists, etc.), but that's the idea.