r-commands between tru64 unix and hp-ux

[John Kittel]

I posted this in tru64 forum, but no joy so far. Maybe you all can help.

I have several old tru64 (4.0d) systems, and several hp-ux 11.11 systems. I'm trying to configure r-commands between them. From hp-ux to tru64 always works. From some tru64 systems to hpux it always works. BUT, from some other tru64 systems to hp-ux rsh ( hp-ux equivalent is remsh)doesn't always work, or at least on some of the systems the output of an rsh command does not display. An rcp from any of these same tru64 systems to hp-ux always works. So far I only see the difficulty with the output of the rsh commands.

For example, on some tru64 systems, if I run this command 20 times, I see the output once or twice, the other times there is no error message, just comes back to the shell prompt:

rsh hpuxbox ls

But, on those same tru64 systems, if I run this command, I always get the output:

rsh hpuxbox "sleep 1; ls"

I'm unable to discover what is the difference between the tru64 systems that would account for this. Some kind of timing issue? Anything you think I can do to troubleshoot it or fix it? ( I can't upgrade).

Thanks.

[A. Clay Stephenson]

The first thing to check on the HP-UX end is /etc/inetd.conf to make sure that remshd is not being starting with the -m option.

Next thing to do is repeated rsh commands on the Tru64 commands until a failure is detected (ie, no expected output). Immediately "echo ${?}" to display the status of the last command. Normally that is a waste of time because ${?} can tell you nothing about the success of the remote command but it can telkl you something about the local machine's ability to initiate the remote command. Essentially, you are trying to see if ${?} is ever non-zero.

You could also enable inetd logging on the HP-UX end so that you can see when the connections are made.

[Arunvijai_4]

Hi John,

How about patch level on these HP-UX servers ? Are they same across ? You can have a patch assessment on your servers.

http://www1.itrc.hp.com/service/patch/wrap.do?dest=/patch/jsp/WrapCPN.jsp&pageKey=patch.html.propatch

-Arun

[John Kittel]

No -m ( or -n) in inetd.conf remshd startup.

$? is 0 when problem occurs.

Patch levels of hp-ux systems are the same, but fairly old, ( have on to-do list to patch up), but "should" be irrelevant, because the problem occurs from different tru64 systems to the same hp-ux systems, e.g. it works from some tru64, not from other tru64, to the same hp-ux.

- John

[John Kittel]

Well, I take that back about the patch level on hp-ux "should" be irrelevant. I guess I can imagine how it could be a factor. It will be a couple months before I can get the patch level up.

[John Kittel]

inetd connection logging on hp-ux side shows exact same information ( connection established) whether the tru64 rsh command works or doesn't work ( returns output or not).

I think the commands are working, but the output is getting lost, - going into bit bucket on tru64 side. But why, and how to fix?

- John

[A. Clay Stephenson · Accepted solution]

The thing that I haven't heard you say is that patches on the Tru64 boxes are the same --- and since, some work, and some don't, that's where I would be looking.

I assume that you have done a man rsh on the Tru64 end to see. I would also try using the -n rsh option on commands that expect no input.

[John Kittel]

Ah! Thank you Clay. The version of the rsh command on the systems that don't work is newer, more recent, than on the systems that do work. Copying the older version of rsh to the systems that had the problem eliminates it.