Does anyone have experience using LDAP to obtain group information on filers using the RFC 2307 compliant options in DOT 6.5 and up, specifically with Novell eDirectory?
I'm also curious about how the ldap.usermap.* options work - the documentation is a bit vague on what the filer expects to see in the .attribute.*account options and how/when lookups are performed. Anyone played this or know what the code does?
- Jeff
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Steve Losen Sent: Thursday, March 03, 2005 3:32 PM To: Bob Borowicz Cc: toasters@mathworks.com Subject: Re: nis.group_update.enable
I read where it was recommended (I think for Oracle RAC) to enable the
following option:
nis.group_update.enable
The man page says this enables a local cache of the group data.
Are calls to the NIS (ypbind) slow in DOT?
I'm running 6.4.4R1
The problem is that NIS provides group maps keyed by group name and by group number (gid). It does not, however, provide a map that is keyed by user that lists all the groups that the user belongs to. But this group list is what a filer needs whenever a user logs in to CIFS (to map windows credentials to Unix credentials)
In order to discover which groups a user belongs to, the filer must use NIS to fetch each group entry and see if the user is listed in it. If you have a very long group map, then every time a user logs in to CIFS the filer must fetch each group entry, with a separate NIS transaction for each one.
By caching the group map, the filer can get the user's group list without NIS. Who knows, the cache may even be organized as group lists keyed by user name.
This is not a problem peculiar to netapps. All Unix systems that use NIS have to linearly scan the entire group map every time a user logs in, to find the user's groups.
If you are not using CIFS then you don't have a problem. NFS does not cause the netapp to scan the group map because each NFS packet contains the user's uid, gid, and group list. The NFS client obtains this information once when the user logs in. I also wouldn't worry about it if your group map is not large.
Anecdote alert:
A few years back one of our NIS servers started chewing up tons of CPU. I traced it and discovered that it was almost 100% sequential scans of our very large group map (almost 700 groups). It turned out that most of these scans were coming from the same machine, which was a busy web server. We had a CGI program run via suexec (which runs the CGI as a particular user). Suexec sets the group list for the user, which requires a linear scan of the NIS group map. So every time this CGI was hit (constantly) the web server was shooting almost 700 NIS requests at the NIS server.
On our netapps and web servers we are now using local /etc/group files updated periodically by cron jobs that copy the NIS map to the local file -- much much better.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support