<cheerful-sarcasm>
This is yet another example of NetApp's fervent commitment to change command syntax, behaviour and output between releases! Through their hard-work and dedication to this cause we can be assured that it will be nearly impossible to consistantly automate any part filer adimistration! And since they diligently ensure not to document any of these changes, us customers can be sure that every ONTAP upgrade will have some annoying SNAFU! Hip Hip Hooray!
</cheerful-sarcasm>
We agree that rsh hosts shouldn't need to be in "options telnet.hosts" - this is ridiculous. NetApp needs to revert this behaviour so that hosts.equiv is all that is necessary for rsh access.
In general, NetApp should think before changing stuff like this as it can lead to many unhappy customers.
-- Jeff
-- ---------------------------------------------------------------------------- Jeff Krueger E-Mail: jeff@qualcomm.com NetApp File Server Lead Phone: 858-651-6709 IT Engineering and Support Fax: 858-651-6627 QUALCOMM, Incorporated Web: www.qualcomm.com
From "David H. Brierley" on Mon, 22 May 2000 15:17:29 EDT:
On Mon, 22 May 2000, Chris Thompson wrote:
I've just spent some time trying to work out why I couldn't rsh to our F740 from some newly installed machines even though I had added them to /etc/hosts.equiv.
This was changed in one of the 5.x releases and I found out about it the same way you did, all of a sudden everything broke. The big problem that I had with it was that I was using the NetApp as a tape server and therefore had well over a hundred clients that needed to be able to "rsh" to it to access the tape drive. In my original configuration I had only two of those hosts listed as being able to telnet to the NetApp but now I had to allow them all. To make things worse, the telnet.hosts option does not allow me to list 100+ hostnames so I had to resort to specifying "telnet.hosts *" so I have now opened up the NetApp to being telnetted to from any host on my local network. Admitted, they still have to be able to guess the password but I just didn't like the thought of opening up the box to potenetial hackery.
-- David H. Brierley Raytheon Electronic Systems, Naval & Maritime Integrated Systems Engineering Technology, Operating Systems Support Group