In the sparks project page we have a dtrace script that can monitor nscd processing. This will probably help you better root cause the problem.
the script is located here: http://www.opensolaris.org/os/project/sparks/dtrace/ It should give you a better idea of what is coming and going out of nscd. Additionally you may want to monitor your AD server activity logs to see what requests are going to AD and what is being returned. I suspect that the problem of only receiving 200 group entries back from a request, is not a client side nss_ldap or nscd problem. More likely it is a AD server issue. We regularly test large groups and have numerous customers that use groups with > 1000 members regularly. I'm currently not aware of any issues where such a small group list would fail. Doug. HUGE | Rob Terhaar wrote: >> Nicolas Williams wrote: >>> On Tue, Sep 30, 2008 at 03:48:12PM -0500, Doug Leavitt wrote: >>>> We currently set an upper bounds of 512k max for a buffer. >>> Perhaps we should truncate the group membership list rather than fail >>> the whole operation. Such a failure mode is much more graceful than the >>> current one. >>> >>> Would that be a simple fix? >>> >>> Nico > On 9/30/08 5:28 PM, "Doug Leavitt" <[EMAIL PROTECTED]> wrote: >> No. That would violate POSIX specifications for the getXbyY APIs, >> which we do not want to do. >> >> As I specified previously, we've investigated this, and the correct fix >> is to allow the system to be configured in a manner that a change in >> configuration can only take affect upon reboot. >> >> The plan is to do this via smf/nscd, but has not been implemented. >> >> DOug. > > So currently, what do users who have LDAP groups larger then ~200 users use > for centralized naming? Are we using nss_ldap incorrectly? Or is the > nss_ldap/nscd group member limit just set extremely low? Please help! :) > _______________________________________________ cifs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
