Dear Managers,
No solution, but a viable workaround. Several respondents
suggested various checks about RIS:
Check the contents of /var/adm/ris/.rhosts (host + "root" on
each line)
Be sure RIS has an unexpired password.
Unfortunately these were already OK in my situation. I never could
get RIS to work.
Lucien Hercaud and I pretty much came up with the same
workaround: NFS-mount the CD on a server (read-only, of course) and
export it to the clients. Then mount the NFS-directory on the
clients, cd to it, and type setld -l . I was ready to do this with a
remote server we get our CSLG-licensed software from, but Lucien
reminded me it works just as well on my local LAN server. LAT is now
installed and will be set up when the load on my clients abates.
Responses:
Lucien_HERCAUD_at_paribas.com
"Sean O'Connell" <sean_at_stat.Duke.EDU>
Simon Reavell <simon.reavell_at_bbsrc.ac.uk>
Harry Eleftheriou <Harry.Eleftheriou_at_digital.com>
Original Post:
Dear managers,
Because of a hardware failure in our Computer Center, I have to
install the LAT subset on my client stations running DU v4.0B. Since they
do not have CD-ROM drives, I must use RIS to do this. The RIS setup succeeds
on the server garfield. However when I type
setld -l garfield:
on a client, it tells me it can't initialize garfield. Further examination
reveals that the command in setld (which is a script) that fails is this:
rsh -l ris garfield echo "Hello"
(which tests that rsh works). The message is permission denied. Attempts to
use rsh without an -l option succeed.
I have checked the following:
1) The rshd daemon is enabled in /etc/inetd.config on the server (without the
-l option). An kill -HUP has been issued to the inetd daemon.
2) /etc/hosts.equiv on the server contains both the short and long names of the
client stations. The file has 755 permission and is owned by bin:bin.
3) /.rhosts on the server also contains the short and long names of the client
stations. The file has 400 permission and is owned by root:system.
4) We use C2 security. I can log into the ris account directly on the server
with no problems. edauth reveals failed login attempts that seem to correlate
directly with the use of setld (or a direct rsh -l) on the client. I cleared
the failed attempts so that the ris account would not lock up.
Any clues?
Larry
============================================================================
Larry Griffith Dept. of Computer & Info Science
larry_at_garfield.wsc.mass.edu Westfield State College
(413) 572-5294 Westfield, MA 01086 USA
PGP public key available at:
http://garfield.wsc.mass.edu/dcis/griffith.html
============================================================================
Received on Mon Mar 30 1998 - 23:51:59 NZST