Folks, I have just been informed about something that we have been discussing recently on toasters. The issue was exports allowing NIS netgroups to be used in the rw= and root= options on the exports of file systems. The above RFE was posted
7 YEARS AGO
The reason for not allowing this was sited as performance issues. Well, we have come an awful long way with speed and abilities in this time. I think it is just plain silly that this RFE has been ignored for so long. Solaris allows this now and I don't think the issue will be resolved until enough people complain.
It was suggested that I submit a case about this RFE which I am doing now. Unless it gets a bunch of requests it will continue to be ignored another 7 years.
Anyway... if any of you want to hop on this bandwagon and get NAC to address the issue, it was suggested that we all enter cases about this.
Soap Box Off. C-
I have just been informed about something that we have been discussing recently on toasters. The issue was exports allowing NIS netgroups to be used in the rw= and root= options on the exports of file systems. The above RFE was posted
7 YEARS AGO
Woohoo! Is that a record or something? :-)
But remember, the "R" in RFE is for Request...
What I'm curious about is who was the original submitter? I wonder if it was one of the old Teleport gang. We had our first filer in '95, eh Darrell? We put in tons of feedback and sent in our share of core files... we whined/commented about how quotas worked (or, sometimes failed to), about wanting multiple volumes, about hot spots in mixed-size RAID groups, about their list of Woody Allen movies... :-)
The reason for not allowing this was sited as performance issues. Well, we have come an awful long way with speed and abilities in this time. I think it is just plain silly that this RFE has been ignored for so long. Solaris allows this now and I don't think the issue will be resolved until enough people complain.
I agree it would be a nice feature. Of course, they do allow you to have a "files" backend for netgroups - does Solaris allow that yet? Not through Solaris 7, anyway...
Maybe to mitigate the netgroup lookup on every access they could simply cache the netgroups map on a schedule, like they do with regular groups? That seems a reasonable compromise between performance and new functionality. In your NIS Makefile you could add the appropriate [rs]sh command to invoke an immediate refresh if you're impatient... or, heck, let's just put in an RFE to have ONTAP be able to act as its own NIS slave server, so any time you push updates the filer could cache 'em locally, and just bind to itself. :-)
Yeah, I know, that's Silly. NIS has been dead for 6 of those 7 years, but it's like a comfortable old pair of sneakers. They're stinky and beat up and have holes in 'em, but you keep wearin' 'em. Maybe they secretly hoped to let this RFE die of old age, but they "misunderestimated" how stubborn old Sun hacks can be. :-) Perhaps we should start lobbying for having ONTAP allow LDAP backends in nsswitch.conf? Maybe when that happens I for one might start taking LDAP a little more seriously and think about fiiiinally dumping NIS...
-- Chris "I don't care what the people say, ASCII config files are here to stay!"
-- Chris Lamb, Unix Guy MeasureCast, Inc. 503-241-1469 x247 skeezics@measurecast.com
On Thu, Apr 18, 2002 at 11:33:17PM -0700, Chris Lamb wrote:
Woohoo! Is that a record or something? :-)
But remember, the "R" in RFE is for Request...
I understand that R is for Request but I think this one is quite valid.
I agree it would be a nice feature. Of course, they do allow you to have a "files" backend for netgroups - does Solaris allow that yet? Not through Solaris 7, anyway...
Yes they do but you still have no way to put a netgroup in the rw= or root=. I don't care one way or the other as long as I don't have to spend 4 hours walking 175 export lines on 22 filers every time I want to update who can write to an export or who has root writability there. That is how long it took me the other night which is when I decided it was time to take up the torch on this issue.
Maybe to mitigate the netgroup lookup on every access they could simply cache the netgroups map on a schedule, like they do with regular groups?
I suggested that very thing. I am not saying they have to be to the second. I am willing to wait till a pre-determined schedule as long as they allow me the ability to force it if I have to. Heck, I suggested twice a day or once an hour update a cached version of the netgroup and be done with it. I was told that every write checks this so it would be a performance hit. My response was... "So." Every write is going to check it somewhere. So on a timed basis update a cached version of the netgroups and check it there.
That seems a reasonable compromise between performance and new functionality. In your NIS Makefile you could add the appropriate [rs]sh command to invoke an immediate refresh if you're impatient... or, heck, let's just put in an RFE to have ONTAP be able to act as its own NIS slave server, so any time you push updates the filer could cache 'em locally, and just bind to itself. :-)
I am not sure I want the filers being slaves. When you have a normal unix box with a complete OS as a slave and you get a corrupt file you resync and you are done. In the old days of local netgroup files on the filers we had more than one occasion where the filer went completely offline because it got a corrupt copy of a local netgroup file. Getting the file back without the ability to do normal vi edits was tedious. I can only imagine what getting a corrupt NIS netgroup on the filer and having it bound to itself could cause. I like the filer to do it's job and leave the NIS functionality on a sun or hp.
Yeah, I know, that's Silly. NIS has been dead for 6 of those 7 years, but it's like a comfortable old pair of sneakers. They're stinky and beat up and have holes in 'em, but you keep wearin' 'em. Maybe they secretly hoped to let this RFE die of old age, but they "misunderestimated" how stubborn old Sun hacks can be. :-) Perhaps we should start lobbying for having ONTAP allow LDAP backends in nsswitch.conf? Maybe when that happens I for one might start taking LDAP a little more seriously and think about fiiiinally dumping NIS...
Well... someday over that rainbow LDAP may fly but for now I am like NIS and don't mind it's little holes. I just want NetApp to keep me from another 4 hour night the next time one of my 58 root nodes has to change.
C-
-- Chris "I don't care what the people say, ASCII config files are here to stay!"
-- Chris Lamb, Unix Guy MeasureCast, Inc. 503-241-1469 x247 skeezics@measurecast.com
Folks, I have just been informed about something that we have been discussing recently on toasters. The issue was exports allowing NIS netgroups to be used in the rw= and root= options on the exports of file systems. The above RFE was posted
7 YEARS AGOThe reason for not allowing this was sited as performance issues. Well, we have come an awful long way with speed and abilities in this time. I think it is just plain silly that this RFE has been ignored for so long. Solaris allows this now and I don't think the issue will be resolved until enough people complain.
I wonder how Solaris does it.
It's my understanding that the access= list is consulted at the time of the mount. It's OK to take the time to look up a host in a netgroup at mount time.
I think the rw= and root= information has to be checked for each NFS request. So that is the performance issue. I know for a fact that you can change the root= info on the NFS server, exportfs again, and the change happens on all NFS clients without having to umount and mount the volume again. In other words, on the NFS server you can unilaterally grant or remove root= access for actively mounted NFS clients.
If these privileges were set at mount time, then you would have to unmount and mount again on NFS clients in order for the change to take effect.
I suppose the NFS server could cache the rw= and root= information for recently active NFS clients to avoid most netgroup queries.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
Guys,
As of 5.3.7R1, the local /etc/netgroup file is cached. We had a big bottleneck that was eliminated in this release. When you have a netgroup file that's almost 750K and the filer had to parse it for each mount, CPU hit 100% in no time.
This doesn't help caching the NIS netgroup's, but it's a start. Still can't export rw or root to netgroups. :(
/Brian/
Guys,
As of 5.3.7R1, the local /etc/netgroup file is cached. We had a big bottleneck that was eliminated in this release. When you have a netgroup file that's almost 750K and the filer had to parse it for each mount, CPU hit 100% in no time.
This doesn't help caching the NIS netgroup's, but it's a start. Still can't export rw or root to netgroups. :(
The NIS netgroup map is actually very nice, because there is a "netgroup.byhost" map that the filer consults. This map is keyed by hostname (actually "hostname.*"). The data in the entry is all the netgroups that the host belongs to. Try it sometime if you use NIS negroups.
ypmatch foo.com.* netgroup.byhost
So when NFS client "foo.com" tries to mount, the filer does a NIS lookup in netgroup.byhost for "foo.com.*" and gets back a list of netgroups that the host is a member of. If any of these netgroups is listed in the access= list, then the mount is allowed. If the NIS lookup fails, then the filer immediately knows that the host is not a member of any netgroup. Only one NIS lookup is required.
If you did it the other way around, you would have to look up each netgroup listed in the access= list and search for the host. Furthermore, a netgroup can contain a netgroup, so the search is recursive.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
The NIS netgroup map is actually very nice, because there is a "netgroup.byhost" map that the filer consults. This map is keyed by hostname (actually "hostname.*"). The data in the entry is all the netgroups that the host belongs to. Try it sometime if you use NIS negroups.
Yes, but this map is not implemented in NIS+ :( So the filer ends up niscat'ing the whole netgroup file from the NIS+ server. We had to go with local /etc/netgroup files to avoid this.
/Brian/
I wonder how Solaris does it.
Not sure.
I think the rw= and root= information has to be checked for each NFS request. So that is the performance issue. I know for a fact that you can change the root= info on the NFS server, exportfs again, and the change happens on all NFS clients without having to umount and mount the volume again. In other words, on the NFS server you can unilaterally grant or remove root= access for actively mounted NFS clients.
All true statements but my point to NetApp was that if they have to check it for every request they should be able to cache it and check from there (cause they have to check somewhere) and I would be quite happy with a periodic update. I don't expect it to be to the second.
If these privileges were set at mount time, then you would have to unmount and mount again on NFS clients in order for the change to take effect.
That would be very bad... bad.... baddddddd. Obviously not an option.
I suppose the NFS server could cache the rw= and root= information for recently active NFS clients to avoid most netgroup queries.
See above.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
-
Brian Long -
Chris Blackmor -
Chris Lamb -
Steve Losen