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