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 <[email protected]> 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 <[email protected]> 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 -- [email protected] >> > To unsubscribe send an email to >> [email protected] >> > 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/[email protected] >> > >> >> 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 -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
