The 512K limit refers to  a line that looks like:

staff::10:user1,user2,user3,user4...userY  <- where the length of that 
string
is 512K.

In our regular LDAP testing, that equates to something approaching
38,000 -> 65000+ users depending on the length of each name.

Where a line like:
a::10:a,b,c...,z,aa,ab,...
yields more results than a line like:
longgroupname:200000::longusername1,longusername2,...

If your system is having a problem at only 200 names, then the issue
is probably not a limit in nss_ldap or naming services.  It is likely some
other non naming problem.

Pre sparks (IE pre S10u4 or pre snv_50) the 8k limit allowed for
something approaching 800-900 names in a group line.

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

Reply via email to