[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: query result size limit by ip


Thanks for the suggestions.

Using back-ldap would mean that we would move most of our searches to the proxyServer-to-dbServer path. That sounds like not such a good idea, but I haven't used back-ldap before so I don't know how much overhead that causes.


--On Thursday, June 12, 2008 09:44:06 AM -0400 Aaron Richton <richton@nbcs.rutgers.edu> wrote:

The better way would be to change limits.c...we've seen a few requests
for this over time...

Your workaround sounds plausible. I'd consider using a back-ldap on the
limited server that proxies to the unlimited server.

The sizelimit directive is marked ARG_MAY_DB. So one workaround that may
or may not work for your situation (or at all, this is off the top of my
head) is:

database hdb
suffix "dc=unlimited,dc=com"
access to * by peername.ip="" read

database relay
suffix "dc=limited,dc=com"
relay "dc=unlimited,dc=com"
sizelimit 500
access to * by * read

and then you could configure different suffix for different limits, but
serve "the same" data. back-relay should be lighter than two slapd with

On Thu, 12 Jun 2008, Bill MacAllister wrote:

We have an application that can only bind to the directory anonymously
and  needs to be able to exceed our query size limit.  The queries will
come from  a small set of IP addresses.  What we want to do is to set
the query size  limit by source ip address.

One way that I can see to do this is to run two slapd servers with
different  -h switches specified on the slapd startup so that each
server will bind to a  different interface:port.  Then we can restrict
access to the
unlimited-size-query server using ip tables.  What would be really nice
is if  the two configurations could specify the same backend databases.
Has anyone  done this?  Should this work?  Is there a better way to do


Bill MacAllister <whm@stanford.edu>
Systems Programmer, ITS Unix Systems, Stanford University

Bill MacAllister <whm@stanford.edu>
Systems Programmer, ITS Unix Systems, Stanford University