|
|
|
by Cas Caswell Commercial Systems Division
An Overview of the REMSH Service
The remote shell, or REMSH, service is used to connect to a specified host and
execute a command on that remote host.
This article describes:
- Verifying installation
- Configuring the REMSH client
- Using REMSH
- Troubleshooting REMSH
- Implementation differences between REMSH on MPE/iX and REMSH for
HP-UX
- Available documentation
REMSH is the same service as rsh on BSD UNIX systems. The name was changed due
to a conflict with the existing command rsh (restricted shell) on System V
UNIX systems.
REMSH allows a user to connect to the remote system and execute a command on
that remote system. Output from the remote command is sent to the REMSH
standard output so the user can see the results of the command.
Verifying Installation
The REMSH client is part of the Internet Services product with release C.55.03.
To verify that REMSH is available on your system, use NMMAINT,73 to list
versions of the Internet Services.
Configuring the REMSH Client
There is only one file on the MPE/iX system that you will need to change in
order to allow use of the REMSH client. That is the file services.net.sys.
However, there are some files that will need to be configured on the remote
UNIX systems.
Editing the Services File
The services file associates official service names and aliases with the port
number and protocol the services use. To enable REMSH use, you must edit the
services file.
To edit the services file:
- You may edit the SERVICES.NET.SYS file from MPE/iX. Open the
services file with a text editor.
- Verify that the following line exists in the file.
shell 514/tcp cmd # remote command, no passwd used
- Add the line if it does not exist.
- If the line already exists in the file and is preceded by a pound
symbol (#), delete the # and any spaces before the service name to
enable the service.
- Save the file and exit the editor program.
UNIX Configuration
The REMSH service does not prompt for user ID and passwords. That information
is handled via the command line parameters and configuration on the UNIX host.
See the using REMSH section for details on how the user id is determined and
passed to the UNIX host.
Password information is bypassed by use of a .rhosts file in the remote user's
home directory or by use of the file /etc/hosts.equiv. See the man pages of
the UNIX system for details on how to set up a /etc/hosts.equiv file. A user's
.rhosts file entry will consist of the MPE/iX system name and user id.
For example, to access the HP-UX system "taltos" as user "cawti," from the
MPE/iX system "jhereg" while user MANAGER.SYS, set up a host
equivalency via the /etc/hosts.equiv file, or you will create a .rhosts file
in the home directory of user "cawti" on the "taltos" machine. The .rhosts
file would look like this:
jhereg MANAGER.SYS
This will cause the REMSH daemon on the UNIX host to allow a connection from
MANAGER.SYS on "jhereg" to the "cawti" user on the host "taltos." The
.rhosts file for user "cawti" would contain an entry for every host and userid
that you desired to access the "taltos" host as if they were the user "cawti."
 |
NOTE: The MPE/iX equivalent of the UNIX user id is the User.Account.
An artifact of the MPE/iX implementation is that the MPE/iX information is
usually reported in upper case. So be sure your .rhosts or /etc/hosts.equiv
entries use the MPE/iX user ID information in upper case.
|
Using REMSH
The REMSH service is accessed by running the REMSH.NET.SYS program.
You may do so under the MPE/iX CI or under the Posix shell. While the format
of the commands will differ depending on how you run the program, the
parameter list remains the same. We'll first look at the parameters and then
look at running the program under the Posix Shell or from MPE/iX CI.
For the purposes of explaining the parameters, look at a sample invocation
from the Posix shell. Detailed examples of both the Posix shell and MPE/iX
invocations will follow later.
From the Posix shell you would invoke the REMSH by typing:
/SYS/NET/REMSH remotehost -l remoteuser remotecommand
In all cases you must provide a remotehost and a
remotecommand. The REMSH program will fail and generate an
error message otherwise. Unless the remote system has MPE/iX type userids, you
will also need to provide a -l remoteuser parameter as well.
Otherwise the remote system will not allow the connection.
- remotehost
- is the name of the remote host you are attempting to connect to. The
host name can be either the official name or an alias as understood by
gethostbyname().
- remoteuser
- is the userid on the remote system you wish to be.
|
|
NOTE: The traditional UNIX implementation of REMSH makes the -l
remoteuser parameter optional. If you do not provide a -l
remoteuser parameter, REMSH takes your current userID and
assumes that you wish to connect to the same userID on the remote system.
Since the MPE version of the userID is USER.ACCOUNT, and the UNIX
equivalent is user, it is unlikely that you will find a user on the remote
system to match your id. We recommend that you always provide the -l
remoteuser argument to REMSH.
|
- remote- command
- is the command that you wish to execute on the remote machine. This
command may be a CI command, a program (that meets certain criteria) or
a shell script. If remotecommand is not specified, REMSH
will terminate and provide a usage message.
|
|
NOTE: REMSH cannot be used to run commands that require a terminal
interface (such as VI) or commands that read their standard error (such as
more).
|
MPE/iX Examples
To run REMSH from MPE/iX prompt, type:
run remsh.net.sys;info="remotehost -l remoteuser [-n]
remotecommand"
jhereg(PUB): run remsh.net.sys;info="taltos -l cawti -n pwd"
/u2/home/cawti
jhereg(PUB):
Posix Examples
From the Posix Shell prompt, type:
/SYS/NET/REMSH remotehost -l remoteuser [-n] remotecommand
shell/iX> /SYS/NET/REMSH taltos -l cawti -n pwd
/u2/home/cawti
shell/iX>
Since you are running under the Posix shell, there are a number of shell
features that you can take advantage of.
Shell metacharacters that are not quoted are interpreted on the local host;
quoted metacharacters are interpreted on the remote host. The following
command line appends the remotefile to the local file
localfile:
SYS/NET/REMSH taltos -l cawti cat remotefile >> localfile
The following command line appends remotefile to the
otherremotefile:
/SYS/NET/REMSH taltos -l cawti cat remotefile ">>" otherremotefile
The following command line runs REMSH in the background on the local
system, and the output of the remote command comes to your terminal
asynchronously:
/SYS/NET/REMSH otherhost -l remoteuser -n remotecommand
The following command line causes REMSH to return immediately without waiting
for the remote command to complete:
/SYS/NET/REMSH otherhost -l remoteuser -n
"remotecommand 1>&- 2>&- &"
In REMSH, if the first parameter in its argument vector is not REMSH,
it will use the value as a host name. You may symbolically link the host name
to the REMSH program. A typical BSD UNIX implementation will have these links
under the /usr/hosts directory.
If you have made a symbolic link to the REMSH program that is the host name
(that is in our examples, ln -s /SYS/NET/REMSH taltos), you could
generate the same result as the first example with the following:
shell/iX>taltos -l cawti -n pwd
/u2/home/cawti
shell/iX>
Troubleshooting REMSH
These are the REMSH messages with an explanation of the meaning and suggested
action, if any.
Message
remsh: MPE/iX/X version won't support rlogin or rexec
functionality
usage: remsh host -l login -n command
Meaning
Be sure to provide a command to execute.
Message
remshd: Login incorrect
Meaning
There is probably an invalid entry in remote .rhosts file. Be sure
host name and userid are correct.
Userid must be in upper case. Be sure you provided an -l
userid parameter, or that the remote system has a
userid that matches your MPE/iX logon.
Message
Program requires more capabilities than allowed for the group, the user
of a temporary file, or the hierarchical directory user. (LDRERR 505)
Native mode loader message 505
Unable to load program to be run. (CIERR 625)
**** EXEC FUNCTION FAILED; subsys =517; info = 48
ABORT: REMSH.NET.SYS
NM SYS a.00aa0270 dbg_abort_trace+$24
NM UNKN 150.00366f6c
NM UNKN 2dd.0004bbd8
[1] + Done (134) REMSH hpcsyn24 -l casc -n pwd
262204 Abort REMSH
Meaning
The first message is from running REMSH from MPE/iX name space, and the second
is from running under the Posix Shell. The cause is typically lack of PM
capability on the group where REMSH resides. Since REMSH is in
NET.SYS, it is unlikely you will see this problem unless someone
changes the capability of the NET.SYS group.
Message
shell/tcp: Unknown service
Meaning
The shell service specification is not present in the services file.
Edit /etc/services or SERVICES.NET.SYS to fix.
Message
Can't establish stderr
Meaning
REMSH cannot establish secondary socket connection for stderr.
Message
Couldn't reopen stderr
Meaning
The remote command tried to reopen stderror. This is not allowed under REMSH.
Message
<system call>: ...
Meaning
Error in executing system call. Appended to this error is a message specifying
the cause of the failure.
Implementation Differences
The full remote shell service typically consists of two parts: the REMSH
client which allows a user on this machine to access remote hosts, and the
remshd server which allows REMSH clients on other hosts to access the local
host. Only the REMSH client functionality has been implemented on the MPE/iX
system.
The HP-UX version of the REMSH client has an optional -n parameter that tells
the client to not read from STDIN. Due to differences between MPE IO and UNIX
IO the -n parameter has been hard coded into the MPE/iX client.
The HP-UX REMSH client also allows rlogin and rexec functionality. Since this
implementation was designed to address the needs of users attempting to access
HP-UX commands and scripts from MPE/iX stream jobs, we chose not to implement
any feature needing interactive input with the remote system.
|
