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