Thank you. Will try to understand the man page. Appreciate your help.
On Wed, Sep 2, 2015 at 4:59 PM, Dieter Klünter dieter@dkluenter.de wrote:
Am Wed, 2 Sep 2015 15:59:28 +0300 schrieb Igor Shmukler igor.shmukler@gmail.com:
$ slapd -V @(#) $OpenLDAP: slapd (Ubuntu) (Mar 17 2014 21:20:08) $
I tried olcSizeLimit, before adding olcSizeLimits. Perhaps there is a bug.
Ther is no bug. Read the manual page slapd-config(5) on olclimits, base DN and DN type, pay attention to dn type 'this'.
-Dieter
On Wed, Sep 2, 2015 at 3:55 PM, Dieter Klünter dieter@dkluenter.de wrote:
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
-- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E