Fedora directory users - Oct 2005 - strange problem with group of more than 2000 users

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

Basile,
This might be a limitation of the client operating systems, and not the 
directory server.
I believe the maximum size for a group in Solaris 8 is 4096 characters, 
regardless of whether the group is coming from /etc/group, LDAP, or 
wherever else.

I''m not sure what the limit is for recent Linuxes or Solaris > 8,
but it
may well also be around 4096 chars.

So, while your LDAP directory is capable of storing much larger groups, 
you may need to break them up into chunks to appease your client OSes.

-- George

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@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

thanks
just another question
could it be a problem with the timers ( ns_search_limit and ns_bind_limit )
of ldap.client ?
basile



George Holbert wrote:
> Basile,
> This might be a limitation of the client operating systems, and not 
> the directory server.
> I believe the maximum size for a group in Solaris 8 is 4096 
> characters, regardless of whether the group is coming from /etc/group, 
> LDAP, or wherever else.
>
> I''m not sure what the limit is for recent Linuxes or Solaris >
8, but
> it may well also be around 4096 chars.
>
> So, while your LDAP directory is capable of storing much larger 
> groups, you may need to break them up into chunks to appease your 
> client OSes.
>
> -- George
>
> 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@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>
>
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

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@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

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

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

Basile,

It is probably not an issue of the bind time limit, since this limit 
defines how long to wait when attempting to connect to your directory 
server.  It sounds like your client is able to connect.

I doubt it''s the search time limit, since 800 is not a huge number of 
entries.  It would be easy to confirm this by increasing the search time 
limit to something big (say 300 seconds).

Your results make me think you are bumping into a 4096 character limit 
for posix groups on your client OS.
Assume your average username is 6 characters long.
Then:
643 * 6 = 3858 chars  (works)
800 * 6 = 4800 chars  (doesn''t work)

What client OS are you using for your tests?

-- George


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

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

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

basile au siris wrote:
> 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 ?
George Holbert already provided a very plausible analysis of your 
problem. Did you read his posts ?

The DS is working just fine : the bug is in the LDAP client (in this 
case: Solaris).

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

From the logs you included, it doesn''t look like anything on the 
directory server side - the client binds, searches, results are 
returned, and results all show no errors, etc.

I''m in agreement with others that it''s a client (i.e. solaris)
issue/limitation.  Your group might be 5232 characters, but see in the 
logs that it is only returning cn, gidnumber, userpassword, and 
memberuid, so you have to see how big just that part of the group is.  
Also, Solaris may have some wierd, non-bit-boundary limit.  Don''t
expect
to see exactly 4096 or such, since n uid''s might be slightly under it, 
and n+1 uid''s might be slightly over it.

Next question - are there any errors in any solaris logs?  In messages, 
syslog, etc?

 - Jeff

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
>>>>>>