[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: "olcSizeLimit: size.prtotal=disabled" ignored?
Am Wed, 2 Sep 2015 14:27:39 +0300
schrieb Igor Shmukler <igor.shmukler@gmail.com>:
> Hi DIeter,
>
> Thank you again. I changed the config. Now, slapcat shows:
> olcSizeLimit: size.prtotal=disabled
> olcLimits: {0}dn=* size.soft=1000 size.hard=1000 size.prtotal=disabled
you should either user sizelimit or limit in order to disable
pagedResults, but not both.
>
> Still the same story:
> # filter: (objectclass=*)
> # requesting: ALL
> # with pagedResults critical control: size=5
> #
>
> # sssvlv.com
> dn: dc=sssvlv,dc=com
> objectClass: top
>
> Does it mean there is a bug?
There is no bug, at least not since release 2.4.33. I tested it with
2.4.33, 2.4.36, 2.4.42. Mostlikly your configuration is missing some
vital parameters.
-Dieter
>
>
> On Wed, Sep 2, 2015 at 1:26 PM, Dieter Klünter <dieter@dkluenter.de>
> wrote:
> > Am Wed, 2 Sep 2015 12:50:59 +0300
> > schrieb Igor Shmukler <igor.shmukler@gmail.com>:
> >
> >> Hello DIeter,
> >>
> >> Thank you for the clarification.
> >> I modified the LDIF to apply the page size limit to a specific
> >> database. Now, slapcat(8) shows limits for my DIT database:
> >> olcSizeLimit: size.prtotal=disabled
> >> olcLimits: {0}dn=* size.soft=unlimited size.hard=unlimited
> >
> > size.hard=unlimited is you problem.
> > From slapd.conf(5)
> >
> > If pagedResults control is requested, the hard size limit is
> > used by default,
> > Use unlimited to allow unlimited number of entries to be
> > returned, e.g. to allow the use of the pagedResults control as a
> > means to circumvent size limitations on regular searches;
> >
> > -Dieter
> >
> >
> >>
> >> The only difference from an example that I found - in my
> >> configuration olcSizeLimit comes before olcLimits. Hopefully, this
> >> is not the problem.
> >>
> >> The server however still does process paged results as below:
> >> # extended LDIF
> >> #
> >> # LDAPv3
> >> # base <dc=sssvlv,dc=com> with scope subtree
> >> # filter: (objectclass=*)
> >> # requesting: ALL
> >> # with pagedResults critical control: size=5
> >> #
> >>
> >> # sssvlv.com
> >> dn: dc=sssvlv,dc=com
> >> objectClass: top
> >>
> >> Is there a requirement to apply olcLimits before olcSizeLImit?
> >>
> >> Sincerely,
> >>
> >> Igor Shmukler
> >>
> >>
> >>
> >> On Wed, Sep 2, 2015 at 11:05 AM, Dieter Klünter
> >> <dieter@dkluenter.de> wrote:
> >> > Am Wed, 2 Sep 2015 08:38:42 +0300
> >> > schrieb Igor Shmukler <igor.shmukler@gmail.com>:
> >> >
> >> >> Hello Dieter,
> >> >>
> >> >> Thank you for replying.
> >> >>
> >> >> > slapd silently ignores the control request, but sizelimit
> >> >> > still comes into effect.
> >> >>
> >> >> Given that, as well as the other relevant information...
> >> >>
> >> >> Is "olcSizieLimit: size.prtotal=disabled" not affecting the
> >> >> response, a bug in OpenLDAP 2.4.x, or did I incorrectly
> >> >> understand the documentation? If it is a bug, should it be
> >> >> filed? How would one go about disabling simple paged results
> >> >> [having the OpenLDAP server respond with critical extension
> >> >> unavailable or similar]? Is restricting access to the control
> >> >> with an ACL is the way to go?
> >> >
> >> > I have overlooked a few mistakes of yours :-(
> >> >
> >> > 1. you modified the global configuration part, that is cn=config,
> >> > and not a database part.
> >> > 2. you configured a sizelimit, not a limit.
> >> >
> >> > slapd.conf(5) clearly states:
> >> >
> >> > GENERAL DATABASE OPTIONS
> >> > Options in this section only apply to the configuration file
> >> > section for the database in which they are defined.
> >> > 'limits' is specified within the general database options,
> >> > size.prtotal is defined within the 'limits' section.
> >> >
> >> > -Dieter
> >> >
> >> > --
> >> > Dieter Klünter | Systemberatung
> >> > http://sys4.de
> >> > GPG Key ID: E9ED159B
> >> > 53°37'09,95"N
> >> > 10°08'02,42"E
> >> >
> >>
> >
> >
> >
> > --
> > Dieter Klünter | Systemberatung
> > http://sys4.de
> > GPG Key ID: E9ED159B
> > 53°37'09,95"N
> > 10°08'02,42"E
> >
>
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E