In message 3510F4A6.701C13F2@mitre.org, "John F. Kane" writes:
I have not located any reported bugs in the NOW Bugs Online database that resemble this problem. Is NetApp aware of this problem and working a solution? Turning off NIS may stop the problem from reoccurring but is not a solution to the problem. The NetApp NIS implementation is a relatively new addition to ONTAP and may need some attention.
John Kane
geen wrote:
John,
I saw the same thing with 4.3.1. My solution was to turn off NIS.
-g d geen
geen@ti.com
John F. Kane wrote:
Has anyone experienced NIS binding problems on their filers? We have four filers (3 F330s & 1 F230) running Ontap 4.3R3 that have been locking out users on a few occasions this past week The UNIX servers and user workstations trying to access the filers are reporting "server not responding: RPC: Timed out" errors. There is not much helpful in the filer logs. In order to unhang the filer, we must manually rebind it to a different NIS slave server.
-- John F. Kane
When we first turned on NIS, everything went to hell. The filer started denying mounts to all the clients. Unfortunately, it didn't do this right away, took several hours. Seems the filer wasn't getting netgroup info. Anyway, here's what NetApp told me:
Hi Jason,
I had one of our escalation engineers look over this call with me.
We believe that what you saw when upgrading to 4.1d is the result of an inefficient method we use to "lookup" the YP information. Instead of doing 3 or 4 lookups to get the netgroup info when the mount is checked we would do one for *every* line in the netgroup file.
This behavior has been logged as bug#4088 in our database and engineering is working to modify the NIS client to correct this problem.
For now the recommendation would be to continue using the local file method which hasn't caused you any problems. When a fix is available for #4088 then you could upgrade and begin using the NIS client for netgroup which should be much faster. One of the benefits of NIS client is that these lookups should be faster but with our first release of this NIS client they simply are not.
I have flagged this call record as bug#4088 with all the info you sent to me. The escalation engineer I spoke with is actually the one that will fix the NIS code and by flagging your call record as this bug he can review it during the time he makes the patch.
This would first be available as a patch release (a release with a capital D in it such as you were running prior to upgrading to 4.1d). The best way to find out when it is available would be to call back and reference the bug#4088 and ask if Eirik has a patch for the NIS client yet. I would think that you might want to wait 30 days or so -- there is no schedule for a fix date for this right now.
Regards, Gil
I never bothered to check back. NOW lists bug #4088 as unfixed. Here's our nsswitch.conf which "solved" our problems:
# # nfssrv1:/etc/nsswitch.conf #
passwd: files nis group: files nis
hosts: files nis dns netgroup: files nis
Good Luck.
--- Jason D. Kelleher kelleher@susq.com Susquehanna Investment Group 610.617.2721 (voice) 401 City Line Ave, Suite 220 610.617.2916 (fax) Bala Cynwyd, PA 19004-1122