[Fedora-directory-users] strange problem with group of more than 2000 users

George Holbert gholbert at broadcom.com
Wed Oct 12 18:00:18 UTC 2005


Hi Basile,

> i exactly can have 726 member in my group  ( 5232 login caracters 5958 
> with end line )

So it doesn't break at exactly 4096, as I suggested earlier.  Hmm... 
perhaps the limit is larger than I thought?
I still would guess the problem is in the client OS rather than the 
directory server.  Note that the before/after logs you posted are 
nigh-identical.  This suggests the directory server isn't doing anything 
different when the group size increases.

It might be a good test to create the same large group in the local 
/etc/group file on a client, and see if it works that way.  This should 
help confirm if the problem is LDAP-related or group length-related.

Good luck,
-- George


basile au siris wrote:

> hi
> back with new infos :)
> i exactly can have 726 member in my group  ( 5232 login caracters 5958 
> with end line )
> what kind of solaris limirtation could it be ?
> i ve  3146 people in the directory in 10 groups and just one with more 
> than 726 users
>
> here are ldap logs for 726 users in group when doing a getent group toto
>
> [12/Oct/2005:12:37:39 +0200] conn=1 fd=64 slot=64 connection from 
> xxx.xxx.xxx.4 to xxx.xxx.xxx.4
> [12/Oct/2005:12:37:39 +0200] conn=1 op=0 BIND 
> dn="cn=proxyagent,ou=profile,dc=example,dc=fr" method=128 version=3
> [12/Oct/2005:12:37:39 +0200] conn=1 op=0 RESULT err=0 tag=97 
> nentries=0 etime=0 dn="cn=proxyagent,ou=profile,dc=example,dc=fr"
> [12/Oct/2005:12:37:39 +0200] conn=1 op=1 SRCH base=" 
> ou=groups,dc=example,dc=fr" scope=1 
> filter="(&(objectClass=posixGroup)(cn=toto))" attrs="cn gidNumber 
> userPassword memberUid"
> [12/Oct/2005:12:37:39 +0200] conn=1 op=1 RESULT err=0 tag=101 
> nentries=1 etime=0
> [12/Oct/2005:12:37:39 +0200] conn=1 op=2 UNBIND
> [12/Oct/2005:12:37:39 +0200] conn=1 op=2 fd=64 closed - U1
>
>
> and here with 727 users when it don t works
>
> [12/Oct/2005:12:46:24 +0200] conn=1 fd=64 slot=64 connection from 
> xxx.xxx.xxx.4 to xxx.xxx.xxx.4
> [12/Oct/2005:12:46:24 +0200] conn=1 op=0 BIND 
> dn="cn=proxyagent,ou=profile,dc=example,dc=fr" method=128 version=3
> [12/Oct/2005:12:46:24 +0200] conn=1 op=0 RESULT err=0 tag=97 
> nentries=0 etime=0 dn="cn=proxyagent,ou=profile,dc=example,dc=fr"
> [12/Oct/2005:12:46:24 +0200] conn=1 op=1 SRCH base=" 
> ou=groups,dc=example,dc=fr" scope=1 
> filter="(&(objectClass=posixGroup)(cn=toto))" attrs="cn gidNumber 
> userPassword memberUid"
> [12/Oct/2005:12:46:24 +0200] conn=1 op=1 RESULT err=0 tag=101 
> nentries=1 etime=0
> [12/Oct/2005:12:46:24 +0200] conn=1 op=2 UNBIND
> [12/Oct/2005:12:46:24 +0200] conn=1 op=2 fd=64 closed - U1
>
> thanks
> basile
>
>
> Jeff Clowser wrote:
>
>> If it is hitting any type of administrative limit, it should show 
>> some type of error in the logs.
>> Look at the searches it is doing, and make sure you have appropriate 
>> indexes on attributes it is searching against - if the appropriate 
>> stuff is indexed, searches should be fast enough to not run into a 
>> timeout issue in most cases.  Look in the access log for Notes=U - 
>> that should be there on an unindexed search.
>>
>> If you don't see any of this in the logs, I'd say it's more a limit 
>> on the Solaris side (as someone else mentioned) than the LDAP side.
>>
>> How big is your directory (how many entries, approximately)?
>>
>> - Jeff
>>
>> basile au siris wrote:
>>
>>> i did a test
>>> with 643 users it works
>>> with 800 users it don t works
>>> could it be timers problem ( time_search_limit or time_bind_limit 
>>> for proxyagent wich is used
>>> to query directory )
>>> basile
>>>
>>> basile au siris wrote:
>>>
>>>> thanks
>>>> i set the sizelimit to -1 but it don t  works better
>>>> i set nssizelimit to -1 of the proxyagent which is used to bind to 
>>>> the directory but same result
>>>> i look at the logs and when i use id or getent there is directory 
>>>> query
>>>> it seems crazy i can t have more than 2000 users in a group
>>>> i search the limit of users i can have
>>>> basile
>>>>
>>>> Jeff Clowser wrote:
>>>>
>>>>> It could be a limit on the sizes of groups, etc in Solaris.
>>>>>
>>>>> To check to see if it's LDAP related, look at the ldap access logs 
>>>>> for queries related to that group or coming from that machine.  
>>>>> Anyway, 2000 I believe is the default sizelimit for searches, so 
>>>>> look for entries with 2000 results, if it's consistently failing 
>>>>> at 2000 users.  If it's just reading the group with 2000+ static 
>>>>> members (1 entry), then maybe reading each user individually (1 
>>>>> entry/search), it shouldn't hit a resource limit.  But...  if it 
>>>>> reads the group, then searches for all users with that group id, 
>>>>> or something similar, it may hit the administrative limits.
>>>>>
>>>>> For a simple test, you could up the sizelimit (say to 10000 or -1) 
>>>>> on the directory server and see if the problem goes away.
>>>>>
>>>>> If you find something like this, there are a couple ways to fix it:
>>>>> 1.  Up your server administrative sizelimit (to a higher number, 
>>>>> or -1 for unlimited).  This should be a last resort, since it 
>>>>> allows anyone (even anonymous) to make unlimited size searches 
>>>>> against your directory.  If your directory is large, that could 
>>>>> cause problems.
>>>>> 2.  If the solaris box is binding as a particular DN to search, 
>>>>> you can add the nsSizeLimit to that entry, and set it to a higher 
>>>>> value (or -1 for unlimited).
>>>>> 3.  If it binds as the end user, you can add nsSizelimit to each 
>>>>> user that can log in.  This is a bit more of a pain to do since 
>>>>> you have to do it for all users, but is better than increasing the 
>>>>> limit for the entire server, in general.
>>>>>
>>>>> - Jeff
>>>>>
>>>>> basile au siris wrote:
>>>>>
>>>>>> hi
>>>>>> i have fds 7.1 on solaris 9 and users and group stored in the 
>>>>>> directory
>>>>>> all works fine except for a group of more than 2000 users
>>>>>> when i use id or getent system did not recognize the group
>>>>>> maybe it s not a fds problem but if someone can give me an idea
>>>>>> thanks
>>>>>> basile
>>>>>>
>>>>>> -- 
>>>>>> Fedora-directory-users mailing list
>>>>>> Fedora-directory-users at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Fedora-directory-users mailing list
>>>>> Fedora-directory-users at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>>
>>>
>>>
>>>
>>> -- 
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>>
>>
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>






More information about the 389-users mailing list