Hi,
based on the err code err=3 I can see that I was wrong, it's not a size
limit but rather a time limit issue. It looks like the LDAP server is
busy after the modification on the cn=<MyBigGroup> entry and takes more
than 33sec to answer.
The default search time limit is 2 seconds at IPA level:
dn: cn=ipaConfig,cn=etc,$BASEDN
ipaSearchTimeLimit: 2
There is also a search time limit set at 389-ds level:
dn: cn=config
nsslapd-timelimit: 3600
and another one can be set per-user:
dn: uid=<user>,cn=users,cn=accounts,$BASEDN
nsTimeLimit: <value>
Is there anything in the error log of 389-ds at the same time?
Note that IPA 3.0.0 is quite old and we did improvements related to
group management in more recent versions (for instance [1] or [2]).
The failing search may simply be an internal search in order to get the
size and time limits, needed to create the search that will check the
content of the entry after the MOD has been done.
flo
[1] https://pagure.io/freeipa/issue/4965
[2] https://pagure.io/freeipa/issue/4947
On 12/20/18 11:38 AM, lune voo via FreeIPA-users wrote:
I tried to perform an ldapsearch using the same kind of command :
ldapsearch -x -D "cn=Directory Manager" \
-h <MyIPAServer> \
-p 389 \
-W \
-b "cn=ipaconfig,cn=etc,dc=<myRealm>" \
-s sub \
objectclass=*
Enter LDAP Password:
I got this result immediately :
# extended LDIF
#
# LDAPv3
# base <cn=ipaconfig,cn=etc,dc=<myRealm>> with scope subtree
# filter: objectclass=*
# requesting: ALL
#
# ipaConfig, etc, <myRealm>
dn: cn=ipaConfig,cn=etc,dc=<myRealm>
objectClass: nsContainer
objectClass: top
objectClass: ipaGuiConfig
objectClass: ipaConfigObject
ipaUserSearchFields: uid,givenname,sn,telephonenumber,ou,title
ipaGroupSearchFields: cn,description
ipaSearchTimeLimit: 2
ipaSearchRecordsLimit: 100
ipaHomesRootDir: /home
ipaDefaultLoginShell: /bin/sh
ipaDefaultPrimaryGroup: users
ipaMaxUsernameLength: 64
ipaPwdExpAdvNotify: 4
ipaGroupObjectClasses: top
ipaGroupObjectClasses: groupofnames
ipaGroupObjectClasses: nestedgroup
ipaGroupObjectClasses: ipausergroup
ipaGroupObjectClasses: ipaobject
ipaUserObjectClasses: top
ipaUserObjectClasses: person
ipaUserObjectClasses: organizationalperson
ipaUserObjectClasses: inetorgperson
ipaUserObjectClasses: inetuser
ipaUserObjectClasses: posixaccount
ipaUserObjectClasses: krbprincipalaux
ipaUserObjectClasses: krbticketpolicyaux
ipaUserObjectClasses: ipaobject
ipaUserObjectClasses: ipasshuser
ipaDefaultEmailDomain: <myDomain>
ipaMigrationEnabled: FALSE
ipaConfigString: AllowNThash
ipaSELinuxUserMapOrder:
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c102
3$unconfined_u:s0-s0:c0.c1023
ipaSELinuxUserMapDefault: unconfined_u:s0-s0:c0.c1023
cn: ipaConfig
ipaCertificateSubjectBase: O=<myRealm>
ipaKrbAuthzData: MS-PAC
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
This query is fine and fast.
Best regards.
Lune
Le jeu. 20 déc. 2018 à 11:25, lune voo <lune.voo1...@gmail.com
<mailto:lune.voo1...@gmail.com>> a écrit :
Here is the value of nsslapd-sizelimit
nsslapd-sizelimit: 2000
For the anonymous queries, we disabled them long time ago.
If I understand well, the problem comes from this search :
SRCH base="cn=ipaconfig,cn=etc,dc=<MyRealm>" scope=0
filter="(objectClass=*)" attrs=ALL
Do you know why this search is performed once the member user has
been removed from the group ?
Lune
Le jeu. 20 déc. 2018 à 11:08, lune voo <lune.voo1...@gmail.com
<mailto:lune.voo1...@gmail.com>> a écrit :
Hello Florence.
Can you see in 389-ds logs which operation is triggering the
size-limit
error? In /var/log/dirsrv/slapd-domXXX/access, you will find
a line with
RESULT err=4, note the conn=xx and op=yy values, then look
above for a
line with conn=xx op=yy SRCH and finally another line above
with conn=xx
op=0 BIND. Please paste the 3 lines for analysis.
How do you identify the lines concerned please ?
Is "conn" a unique ID of the connection ?
I find this concerning the connection 33725735 that I think I am
using :
674:[20/Dec/2018:10:30:34 +0100] conn=33725735 fd=64 slot=64
connection from <MyIPAServerIP> to <MyIPAServerIP>
715:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=0 BIND dn=""
method=sasl version=3 mech=GSSAPI
716:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=0 RESULT
err=14 tag=97 nentries=0 etime=0, SASL bind in progress
717:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=1 BIND dn=""
method=sasl version=3 mech=GSSAPI
718:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=1 RESULT
err=14 tag=97 nentries=0 etime=0, SASL bind in progress
719:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=2 BIND dn=""
method=sasl version=3 mech=GSSAPI
720:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=2 RESULT err=0
tag=97 nentries=0 etime=0
dn="uid=<MyUser>,cn=users,cn=accounts,dc=<MyRealm>"
721:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=3 MOD
dn="cn=<MyBigGroup>,cn=groups,cn=accounts,dc=<MyRealm>"
725:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=3 RESULT err=0
tag=103 nentries=0 etime=0
735:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=4 SRCH
base="cn=ipaconfig,cn=etc,dc=<MyRealm>" scope=0
filter="(objectClass=*)" attrs=ALL
753:[20/Dec/2018:10:31:07 +0100] conn=33725735 op=4 RESULT err=3
tag=101 nentries=0 etime=33
841:[20/Dec/2018:10:31:08 +0100] conn=33725735 op=5 UNBIND
842:[20/Dec/2018:10:31:08 +0100] conn=33725735 op=5 fd=64 closed
- U1
I cannot find anything related to conn=33725735 between line
#735 and line #753.
So I find that there are 3 errors, but I don't have details of
these errors.
The size limits are configured at multiple levels:
- at IPA level: with ipa config-show, you can see the
settings that IPA
is using for all the queries triggered by ipa *-find commands.
- at 389-ds level: the attribute nsslapd-sizelimit of the entry
cn=config is also limiting the number of returned entries
- at 389-ds level: the attributes nsSizeLimit and
nsLookThroughLimit of
the entry cn=anonymous-limits,cn=etc,$BASEDN limit the
number of
returned entries for anonymous queries
- it is also possible to configure per-user limits, for
instance in
uid=user,cn=users,cn=accounts,$BASEDN with the attributes
nsSizeLimit
nsLookThroughLimit nsPagedLookThroughLimit and nsPagedSizeLimit
config-show gave me this :
Search time limit: 2
Search size limit: 100
I need to check the values of "nsslapd-sizelimit" and
"nsSizeLimit" I currently have.
Will come back asap.
Lune
Le mer. 19 déc. 2018 à 21:59, lune voo <lune.voo1...@gmail.com
<mailto:lune.voo1...@gmail.com>> a écrit :
Hello Florence.
Going to check that tomorrow and add these lines.
Thanks for this first answer.
Lune
Le mer. 19 déc. 2018 à 20:27, Florence Blanc-Renaud
<f...@redhat.com <mailto:f...@redhat.com>> a écrit :
On 12/19/18 12:15 PM, lune voo via FreeIPA-users wrote:
> Hello everyone.
>
> I send you this mail because I have a problem with an
ipa
> group-remove-member command which ends up with the
following error message :
> "Limits exceeded for this query".
>
> I'm using IPA 3.0.0.
> The group for which I want to remove a user contains
other groups also
> (281).
>
> I was wondering how I could solve this problem ?
>
> I tried to play with the configuration as described
here :
>
https://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/searches.html
>
> I tried to increase both limits but it did not solve
the problem.
> I guess as I'm not doing a search but group remove
member, this
> parameters are not used maybe ?
>
> Thanks for your help o/
>
> Best regards.
>
> Lune.
>
> _______________________________________________
> FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
> To unsubscribe send an email to
freeipa-users-le...@lists.fedorahosted.org
<mailto:freeipa-users-le...@lists.fedorahosted.org>
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>
Hi,
when you are running ipa group-remove-member, are you
authenticated as
admin or as another user?
Can you see in 389-ds logs which operation is triggering
the size-limit
error? In /var/log/dirsrv/slapd-domXXX/access, you will
find a line with
RESULT err=4, note the conn=xx and op=yy values, then
look above for a
line with conn=xx op=yy SRCH and finally another line
above with conn=xx
op=0 BIND. Please paste the 3 lines for analysis.
The size limits are configured at multiple levels:
- at IPA level: with ipa config-show, you can see the
settings that IPA
is using for all the queries triggered by ipa *-find
commands.
- at 389-ds level: the attribute nsslapd-sizelimit of
the entry
cn=config is also limiting the number of returned entries
- at 389-ds level: the attributes nsSizeLimit and
nsLookThroughLimit of
the entry cn=anonymous-limits,cn=etc,$BASEDN limit the
number of
returned entries for anonymous queries
- it is also possible to configure per-user limits, for
instance in
uid=user,cn=users,cn=accounts,$BASEDN with the
attributes nsSizeLimit
nsLookThroughLimit nsPagedLookThroughLimit and
nsPagedSizeLimit
So we need to understand which user is performing the ipa
group-remove-member command, and which limit is
triggering the error.
flo
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
