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 <f...@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.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
