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.h...
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.
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.h...
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 To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
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
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 flo@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.h...
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 To unsubscribe send an email to
freeipa-users-leave@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.fedorahoste...
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
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.voo1234@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 flo@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.h...
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 To unsubscribe send an email to
freeipa-users-leave@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.fedorahoste...
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
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.voo1234@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.voo1234@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 flo@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.h...
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 To unsubscribe send an email to
freeipa-users-leave@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.fedorahoste...
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
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.voo1234@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.voo1234@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.voo1234@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 flo@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.h...
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 To unsubscribe send an email to
freeipa-users-leave@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.fedorahoste...
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
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.voo1234@gmail.com mailto:lune.voo1234@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.voo1234@gmail.com <mailto:lune.voo1234@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.voo1234@gmail.com <mailto:lune.voo1234@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 <flo@redhat.com <mailto:flo@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-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@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-leave@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.fedorahoste...
Re Florence.
I performed the following command :
ipa config-mod --searchtimelimit=5
It solved this "problem".
May I ask what can be the impacts on increasing searchtimelimit please ?
Best regards.
Lune
Le jeu. 20 déc. 2018 à 12:37, Florence Blanc-Renaud flo@redhat.com a écrit :
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.voo1234@gmail.com mailto:lune.voo1234@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.voo1234@gmail.com <mailto:lune.voo1234@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 *-findcommands.
- at 389-ds level: the attribute nsslapd-sizelimit of theentry
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 andnsPagedSizeLimit
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.voo1234@gmail.com <mailto:lune.voo1234@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 <flo@redhat.com <mailto:flo@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.h...
> > 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-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@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.fedorahoste...
> 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-leave@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.fedorahoste...
Hi Lune,
On Thu, Dec 20, 2018 at 4:14 PM lune voo via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Re Florence.
I performed the following command :
ipa config-mod --searchtimelimit=5
It solved this "problem".
May I ask what can be the impacts on increasing searchtimelimit please ?
It's a safeguard to make sure the server cannot be kept busy for long periods of time by long-running requests.
5 seconds is OK, but if you want to be on the safe side of things you can revert to the default value until you need to run "ipa group-remove-member" again.
As Florence mentioned improvements have been made in that area in newer versions of FreeIPA.
Best regards, François
Best regards.
Lune
Le jeu. 20 déc. 2018 à 12:37, Florence Blanc-Renaud flo@redhat.com a écrit :
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.voo1234@gmail.com mailto:lune.voo1234@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.voo1234@gmail.com <mailto:lune.voo1234@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.voo1234@gmail.com <mailto:lune.voo1234@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 <flo@redhat.com <mailto:flo@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-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@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-leave@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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
On 12/20/18 10:13 AM, lune voo via FreeIPA-users wrote:
Re Florence.
I performed the following command :
ipa config-mod --searchtimelimit=5
It solved this "problem".
May I ask what can be the impacts on increasing searchtimelimit please ?
Hi Lune,
The purpose of setting these kinds of limits is to prevent clients from abusing the Directory Server/IDM and causing potential DOS attacks. If you increase the search time limit it just means that any client can run "longer" searches and tie up Directory Server/IDM resources longer. That being said, 5 seconds or 10 seconds are very reasonable limits, but for example setting it to an hour would not be.
HTH,
Mark
Best regards.
Lune
Le jeu. 20 déc. 2018 à 12:37, Florence Blanc-Renaud <flo@redhat.com mailto:flo@redhat.com> a écrit :
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.voo1234@gmail.com <mailto:lune.voo1234@gmail.com> > <mailto:lune.voo1234@gmail.com <mailto:lune.voo1234@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.voo1234@gmail.com <mailto:lune.voo1234@gmail.com> > <mailto:lune.voo1234@gmail.com <mailto:lune.voo1234@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.voo1234@gmail.com <mailto:lune.voo1234@gmail.com> > <mailto:lune.voo1234@gmail.com <mailto:lune.voo1234@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 > <flo@redhat.com <mailto:flo@redhat.com> <mailto:flo@redhat.com <mailto:flo@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> > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> > > To unsubscribe send an email to > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@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 <mailto:freeipa-users@lists.fedorahosted.org> > To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@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-leave@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.fedorahoste...
Thanks for all these answers guys (and woman) o/
Lune
Le jeu. 20 déc. 2018 à 16:23, Mark Reynolds mreynolds@redhat.com a écrit :
On 12/20/18 10:13 AM, lune voo via FreeIPA-users wrote:
Re Florence.
I performed the following command :
ipa config-mod --searchtimelimit=5
It solved this "problem".
May I ask what can be the impacts on increasing searchtimelimit please ?
Hi Lune,
The purpose of setting these kinds of limits is to prevent clients from abusing the Directory Server/IDM and causing potential DOS attacks. If you increase the search time limit it just means that any client can run "longer" searches and tie up Directory Server/IDM resources longer. That being said, 5 seconds or 10 seconds are very reasonable limits, but for example setting it to an hour would not be.
HTH,
Mark
Best regards.
Lune
Le jeu. 20 déc. 2018 à 12:37, Florence Blanc-Renaud flo@redhat.com a écrit :
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.voo1234@gmail.com mailto:lune.voo1234@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.voo1234@gmail.com <mailto:lune.voo1234@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 *-findcommands.
- at 389-ds level: the attribute nsslapd-sizelimit of theentry
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 andnsPagedSizeLimit
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.voo1234@gmail.com <mailto:lune.voo1234@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 <flo@redhat.com <mailto:flo@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.h...
> > 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-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@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.fedorahoste...
> 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 returnedentries
- 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 theipa
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-leave@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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
freeipa-users@lists.fedorahosted.org
-
Florence Blanc-Renaud -
François Cami -
lune voo -
Mark Reynolds