The NIS netgroup map can be problematic. From what I have been able to figure out, the NIS server builds a map called netgroup.byhost that is keyed by hostname and lists all the netgroups that that host is a member of. NIS map lookups must match the search key exactly, i.e., are case sensitive. In netgroup.byhost the lookup key is the hostname with ".*" appended to it, eg, "feather.llnl.gov.*". You can test your netgroup map with
ypmatch "feather.llnl.gov.*" netgroup.byhost
When a mount request comes in, the NFS server does a reverse DNS lookup on the IP address of the NFS client to get the client's hostname. The NFS server does a case sensitive lookup of the client's hostname in the NIS netgroup.byhost map to get a list of all the netgroups that the client belongs to. Then the exports list is consulted to see if the filesystem is exported to any of those netgroups.
Because the NIS lookup in the netgroup.byhost map must mach exactly, you have to be very careful that the hostnames in your netgroup file match exactly what DNS returns in response to the reverse lookup of the client's IP address. This usually means that your NIS netgroup file must contain FQDNs. (I suppose it is possible that the NIS Makefile converts partial hostnames to FQDNs when creating the netgroup.byhost map, but I don't think it does.)
We ran into some trouble with some SGI NFS servers because the SGIs were changing the result of the DNS lookup to all lower case. Our DNS servers return ".Virginia.EDU" and the SGIs were converting this to ".virginia.edu" for some unknown reason. Our NIS maps use ".Virginia.EDU" because that's what DNS returns, so when the SGIs converted to lower case, the NIS lookup failed and mounts were denied. We fixed the problem by modifying the NIS Makefile for our netgroup map. Our new Makefile creates two entries in netgroup.byhost for each host -- one keyed with the hostname returned by DNS and one keyed with the hostname in all lower case. That solved our SGI mount problems.
I don't know if netapp filers use this same algorithm for checking mounts. It doesn't sound like it if there was a bug where FQDNs failed to work. You would think that only FQDNs could possibly work.
Jagan Bearelly wrote:
I am assuming you are using DNS. There should be case sensitive FQDN entry that matches the "nslookup" output for a given client and please see that dns.domainname is set with the same case sensitive value because "ypmatch" on NIS server is case sensitive.
I am using DNS, I am not sure what you mean by case sensitive FQDN or do you mean case insensitive? All combos of case seem to work when I do an nslookup, i.e. feather, Feather, FEATHER...and none of this mattered for the first 1-1/2 years so why now? The dns.domain is set also.
Also, ONTAP version 5.3.4R3 doesn't have a fix for netgroup related issue (19922 netgroup lookups can fail with fully qualified domain name). This fix is available in 5.3.5, 5.3.5R1 and 5.3.5R2 which are the latest releases.
Thanks for the info. However, I went to the NOW site and the Data ONTAP Release Advisor (a really neat tool I just found) said to go to 5.3.5r2. So, is this not only the latest but also stable since stable is mucho importante. I am running off to conquer new worlds in another week and I can't get an unlisted number and hide since I will only be four trailers away from where I am now. And, I don't want to leave a bunch of limping filers as my legacy now do I???
Cheryl
Steve Losen scl@virginia.edu phone: 804-924-0640
University of Virginia ITC Unix Support