12-13-2000 12:35 PM
When I attempt to restart a new client, it finds the machine and then comes up with the error ...
"The target system "[targetcomputername]", is not allowing root remsh access by you (root@[servercomputername]). Would you like bootsys to set the .rhosts file on that system at this time? ([y]/n)"
When yes is chosen, it attempts again, and fails with the same message. I have checked the .rhosts file on the target and the entry appears (repeatedly. Once for each attempt I have made) but the access is still dnied. I have tried adding the entry manually to the .rhosts file, adding the servername to the regular hosts file, as well as creating and adding the server to the hosts.equiv file. I still get the same error on bot HPUX10.20 machines.
Thanks in advance for the help and I appreciate the time you are taking to assistme.
Solved! Go to Solution.
12-13-2000 02:07 PM
A couple of things to check:
Is .rhosts in root's home directory (not necessarily /)?
Is the host in .rhosts listed in /etc/hosts (or your name service)? Use nslookup to verify.
Is .rhosts owned by root and not a symbolic link?
Good luck and let us know how it turns out,
12-13-2000 03:50 PM
Thanks for the ideas. I double-checked all of the things you listed. Quick answers ...
Yes, both the server and the client I am trying to remsh to are listed in both machine's hosts file. Using nslookup I get a correct IP for each machine, on both machines.
The .rhosts file is in the correct home directory for 'root' (and it is '/ ')
And the .rhosts file is owned by root, as a member of the sys group.
More info. Tried some experiments. I added the servername and two account names to the SERVERS .rhosts files and attempted to remsh from the server to the server. I.E. while logged on as root on the machine SERVER, I typed the following command ...
#remsh SERVER ls
... and the 'ls' command executed, giving me a listing off SERVER.
I then tried the same command while logged into SERVER as a user, and the ls command ran. This tells me remsh is functioning fine on the server.
I then added the identical user account to the client machine in question and, while logged onto the client machine as root (and then as the user account) tried the same command. I.E. While logged onto CLIENT I typed ...
#remsh CLIENT ls
... and the command failed giving invalid logon. I tried all the above commands with the '-l ' switch (using root and username) and it succeeded on the SERVER and failed on the CLIENT machine.
I then tried to remsh CLIENT while logged onto SERVER (using both root and username) and it failed.
It seems to be a failure on the CLIENT machine, but I do not know enough about it to guess what it is.
12-13-2000 04:43 PM
shell stream tcp nowait root /usr/lbin/remshd remshd
If the above statement is present and commented, uncomment and use the command to re-read the inetd.conf file.
# inetd -c
Hope this helps.
12-13-2000 05:29 PM
Check your /var/adm/inetd.sec file and make sure there isn't a condition set that would deny login from this other server. (Sounds silly I know, but I've seen it...)
Next thing to try is again doing the nslookup..do it with nslookup
Not that this will be the answer, but it's a couple things to try and at least rule out.
12-13-2000 09:59 PM
If trying to remsh from 'thishost' to 'thathost':
Ensure that thishost's entry in thathost's /.rhosts file references thishost's *official* hostname, not an alias in /etc/hosts.
12-14-2000 04:41 AM
Do telnet and rlogin work?
12-14-2000 08:51 AM
In addition to the other suggestions, you may want to check your /etc/nsswitch.conf on both servers. Another thing that you can do is to use IP addresses as opposed to domain names in the ~/.rhosts
Also, I recommend you try doing an rlogin from SERVER to CLIENT. if this asks you for the password then the problem probably has to do with name resolution. if it says connection refused, then, it is likely that remshd is not running - verify by running (on CLIENT):
netstat -a | grep shell
PS. remember that .rhosts is in the home directory of the user
12-14-2000 09:01 AM
As you recall, I was attempting (initially) to use ignite to start this server. Ignite uses the remsh command. When it failed, I attempted to do a remsh command independently and failed.
The entry in the .rhosts file was added by the ignite server and the entry included only the servers UNqualified name. I.E. [servername] root
I checked that this entry matched the entry which was in the hosts file, which was simply [servername] (again UNqualified.)
I also used the nslookup against the DNS server and the hosts file (using servername and IP) and they were both coming up identical, with just the UNqualified [servername].
For fun, I changed the entry in the .rhosts file to the FULLY qualified name of [servername.subdomain.domain]. Even though I DID NOT change the entry in the hosts file, nor on the DNS server (nslookup STILL responds with just [servername] ) the remsh command functioned.
Good bug to know with HPUX 10.20 Ignite. Quick reminder, this bug DID NOT occur with HPUX 11.0. Apparently, the resolution services got patched for 11.0.
Thanks for everyone who helped!