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(a)redhat.com
>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Fedora-directory-users mailing list
>>>>> Fedora-directory-users(a)redhat.com
>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users(a)redhat.com
>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users(a)redhat.com
>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>>
>>
>>
>> --
>> Fedora-directory-users mailing list
>> Fedora-directory-users(a)redhat.com
>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>