Hi Lune,
On Thu, Dec 20, 2018 at 4:14 PM lune voo via FreeIPA-users
<freeipa-users(a)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(a)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(a)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(a)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(a)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(a)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/searche...
>> > >
>> > > 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(a)lists.fedorahosted.org
>> > <mailto:freeipa-users@lists.fedorahosted.org>
>> > > To unsubscribe send an email to
>> > freeipa-users-leave(a)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.fedoraho...
>> > >
>> >
>> > 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(a)lists.fedorahosted.org
>> > To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
>> >
>>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...