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

Wed Oct 12 10:54:44 UTC 2005

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