This page gives you some suggestions for
troubleshooting remote starting problems for the ViewStation's window
managers.
Window Manager Remote Starting Checklist
Starting the ViewStation's window managers from a remote host with
the "rsh" command allows the local ViewStation window manager access to
its resource files on the host and permits "rcp" and "rcmd" access to
the network.
These unique and powerful features all depend on the success
of the initial "rsh" command and the successful operation of
nameservice and other network services. If these processes fail, the
local window managers cannot gain the access they require.
This checklist shows a few things you can check if you have
problems with this process. It is suggestive of places to look for
problems. It is not specific about many items because the names and
syntax of files can vary from system to system.
Necessary Network Services
1) /etc/hosts file - The ViewStation must have a name
entry here on its "rsh" host.
For a Sun host, the /etc/hosts file looks like this: #
Sun host database
# If the NIS is running, this file is
consulted only when booting
#
128.91.3.12 hdssun
#
128.91.6.5 mikegfx
128.91.6.10
davidfx
and so on.
2) /etc/hosts.equiv - The ViewStation must have
specific equivalency with its primary host (the source of the "rsh"
command). Often this /etc/hosts.equiv file is empty or has only a "+"
entry; it should have a specific entry for the ViewStation using the
rsh command. Check your man pages for the correct form and syntax for
this file.
For a Sun host, the /etc/hosts.equiv file looks
like this: # hosts.equiv file
# See /etc/hosts
for a list of valid names
hdssun1
hds486
davidfx
+
If you are using an .rhosts file, exchanging
permissions is a little more complicated and sensitive since "Trusted
Access" is implemented in different ways by different systems. The
system administrator should be familiar with how this works on his
system. Each user may have an .rhosts file in their home directory
which contains the names of hosts equivalent to the user. The file
itself contains a host name and a user name for each user that is to be
granted equivalent status with the home user.
3) Domain Name Service (and/or NIS or Yellow Pages) -
The ViewStation must have a name (not just an IP address) on file and
the nameservice lookup functions must work correctly from all devices
and in all directions.
Resource File Requirements
The "rsh" command (or its equivalent on other systems, such as
"rcmd" on SCO systems and "remsh" on HP systems, etc.) starts a shell.
This shell must have correct environment variables, paths, and so on, in
place or it cannot locate the files it needs for operation. Different
systems and different users may have this information in different
places. You must insure that this information is available to the local
window manager.
1) For the C shell - the .cshrc file should contain all the
pertinent path and environment variables. The .cshrc file is read each
time the "rsh" command is given, so this file is the desired location
for them. A .login file is read only on startup, and so is not a good
location for these variables.
2) For the Bourne shell - the .profile file should
contain all the pertinent path and environment variables. The .profile
file is read when the "rsh" command is given, so this file is a good
location for them.
3) For the Korn shell - the .profile file should
contain all the pertinent path and environment variables. You must
also put the path and environment variables in some system-wide
location where they will be read whenever the "rsh" command is given,
perhaps invoking the command from a script which explicitly finds and
reads them.
4) Resource files and locations - resource variables
for the window managers can have many locations, such as .Xdefaults,
/usr/lib/X11/app-defaults, .Xresources, .mwmrc, .openwin-menu, etc. You
must insure that these files are read, which means both that the
locations are correctly specified and also that the "rcp" command
succeeds. The ViewStation attempts to read these files in a number of
locations; use the Console window for messages to see the file names and
locations it looks for. These may be different than the locations your
host used for host-based operation of the window managers. Note that
the shell startup files may not produce any output messages or the
"rcp" command will fail and an "RCP protocol screwup" message will be
sent. This is a restriction inherent in the "rcp" protocol.
5) Resource file contents - the contents of the
resource file may cause problems. Comment lines, variable names, etc.
must conform to the window manager's format and syntax. For example,
resources written as C code cannot be imported without some syntax
adjustments. These are often tricky problems to find and may depend on
syntax differences between window manager versions. Check the man pages
of the window managers; the ViewStation uses full, licensed copies of
the window managers, so all resources and syntax are fully supported.
Common Error Messages
The ViewStation Diagnostic messages (or Console Window) are a
valuable tool in tracing problems and errors. The Diagnostic messages
report rcp attempts to read files with both names and locations, and
display error messages when they occur. These are some common errors:
1) "RCP failed" - this message typically points to
problems with permissions. Check /etc/hosts.equiv and path variables,
or perhaps nameservice failures.
2) "Error: Remote shell 'env' command to user@host
contains an invalid line." - this message typically points to path
or environment variable problems. It may be that the .cshrc file (or
its equivalent) has a command that is not understood or has incorrect
syntax.
3) "Error executing remote shell env command to
user@host." - this message usually indicates that there is a
problem with permissions or getting to the correct files.
4) "RCP protocol screwup" - this message can refer to
any of the permission, path, or environment variable problems.
5) "Login incorrect" or "Permission denied" - these
messages typically indicate a problem with the /etc/hosts or
/etc/hosts.equiv files.
Suggestions for fixes
The basic task is to isolate the problem. Simplify the
configuration as much as possible. Use a single host, single host name,
and a single user. Rename the user's .cshrc and use a minimal file in
its place. Rename the resource files and use a minimal file in their
places. Use the Console window messages to track
the loading process and file locations. Reduce your system
configuration to the minimal configuration and try to run the
ViewStation's window manager before you add the more complicated
elements.
A quick and simple test for the "rsh" command is to enter:
rsh localhost env
which will show you the path variables and environments
which are set in your .cshrc file. If variables are missing from this
response, they will also be missing for the local window manager
started by rsh.
Another simple test is to do an "rcp" between two of the hosts
on the network to test its operation independent of the ViewStation and
its file transfer requirements. The ViewStation's requirements are
simple: the ability to start a remote shell and do a remote copy.
Added features, like nameservices, and configurations, like special
user environments, can make this simple requirement into a complicated
set of tasks. There are many situations and problems of this type.
Almost without exception, the problems can be traced to
incompatibilities within the system configuration.
HDS Technical Support people will be glad to help you examine
the problem, but they are not experts on your system. Use your system
administrator and your network utilities to try to trace the problem.
HDSrunwm Launcher Program
This
page describes an HDSware utility program for starting the window
managers in environments where RSH cannot be used.
Return to Section Heading Page
Return to the Home Page
If you need more information than is available here, you can reach
HDS via email at info@hds.com, or
call us at 1.800.HDS.1551 in the USA, or at +610.277.8300 from outside
the US. For questions or problems regarding the HDS WWW page, contact
webmaster@hds.com.
© 1996 by HDS Network Systems
Inc.