10:53 a.m.
Hi all,
I am having some sudden bizarre behaviour from fedora-ds-1.1.2-1.fc6.
The following query, logged in as a specific user created for our
mailserver, has suddenly since this morning returned the error
"Administrative limit exceeded":
'(&(associatedDomain=imausa.net)(!(associatedDomain=rachel.example.com)))'
When the exact same query is made using the Directory Manager, it
returns zero records returned, which is correct (no entries exist in the
directory called imausa.net).
According to the documentation for the error message "Administrative
limit exceeded", this error will be thrown when more than by default
1000 rows are returned during a query by a user other than the Directory
Manager.
When I last looked though, zero records was well less than 1000, and I
am completely stumped.
Trying a domain that is hosted in this server, the query returns one
single record, as expected, as the Directory Manager user.
Trying the same query as the specific user created for our mailserver,
we again get "Administrative limit exceeded".
Has anybody encountered and error like this before?
In answer to "what's changed recently", the number of records in the
LDAP server was increased from just over 1000 records to around 7000
records, although I cannot be sure if this is related. The records have
nothing whatsoever to do with the objects being queried by our
mailserver in this case.
Regards,
Graham
--
11:10 a.m.
Graham Leggett wrote:
Hi all,
I am having some sudden bizarre behaviour from fedora-ds-1.1.2-1.fc6.
The following query, logged in as a specific user created for our
mailserver, has suddenly since this morning returned the error
"Administrative limit exceeded":
'(&(associatedDomain=imausa.net)(!(associatedDomain=rachel.example.com)))'
When the exact same query is made using the Directory Manager, it
returns zero records returned, which is correct (no entries exist in
the directory called imausa.net).
According to the documentation for the error message "Administrative
limit exceeded", this error will be thrown when more than by default
1000 rows are returned during a query by a user other than the
Directory Manager.
Not exactly. You are most likely hitting the look through
limit. Is
associatedDomain indexed for equality? Are there more than 1000 entries
that have the associatedDomain attribute? In order to satisfy the NOT
filter (!) the database has to look through all of the records in the
database.
See http://tinyurl.com/5yjk6m
Directory Manager is immune to look through limits and other such
limits. That's why the search succeeds as Directory Manager.
You can set specific look through limits and other limits for individual
or groups of users - see http://tinyurl.com/2sy8bl
When I last looked though, zero records was well less than 1000, and I
am completely stumped.
Trying a domain that is hosted in this server, the query returns one
single record, as expected, as the Directory Manager user.
Trying the same query as the specific user created for our mailserver,
we again get "Administrative limit exceeded".
Has anybody encountered and error like this before?
In answer to "what's changed recently", the number of records in the
LDAP server was increased from just over 1000 records to around 7000
records, although I cannot be sure if this is related.
That is most definitely the
culprit.
The records have nothing whatsoever to do with the objects being
queried by our mailserver in this case.
It doesn't matter, since they exist in
the same database and have to be
"looked through".
Regards,
Graham
--
------------------------------------------------------------------------
--
Fedora-directory-devel mailing list
Fedora-directory-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
11:32 a.m.
Rich Megginson wrote:
Not exactly. You are most likely hitting the look through limit. Is
associatedDomain indexed for equality? Are there more than 1000 entries
that have the associatedDomain attribute? In order to satisfy the NOT
filter (!) the database has to look through all of the records in the
database.
The total number of objects containing associatedDomain is 50 objects,
and the definition for associatedDomain is the default as found in the
pilot schema like so:
/etc/dirsrv/slapd-chandler/schema/28pilot.ldif:attributeTypes: (
0.9.2342.19200300.100.1.37 NAME 'associatedDomain' DESC 'Standard LDAP
attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 1274' )
How does the directory handle multiple queries in an "and"? I would have
thought that (&(A)(B)) would not bother evaluating B if A evaluated to
zero records (as is the case in the first query), and in theory
calculating the NOT in the second half of the query should have in
theory have searched the results left over after evaluating A (ie just
one record in the second query).
Or have I got this wrong (or backwards)?
Regards,
Graham
--
11:45 a.m.
Graham Leggett wrote:
Rich Megginson wrote:
> Not exactly. You are most likely hitting the look through limit. Is
> associatedDomain indexed for equality? Are there more than 1000
> entries that have the associatedDomain attribute? In order to
> satisfy the NOT filter (!) the database has to look through all of
> the records in the database.
The total number of objects containing associatedDomain is 50 objects,
and the definition for associatedDomain is the default as found in the
pilot schema like so:
/etc/dirsrv/slapd-chandler/schema/28pilot.ldif:attributeTypes: (
0.9.2342.19200300.100.1.37 NAME 'associatedDomain' DESC 'Standard LDAP
attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC
1274' )
How does the directory handle multiple queries in an "and"? I would
have thought that (&(A)(B)) would not bother evaluating B if A
evaluated to zero records (as is the case in the first query), and in
theory calculating the NOT in the second half of the query should have
in theory have searched the results left over after evaluating A (ie
just one record in the second query).
Or have I got this wrong (or backwards)?
I think the problem is that having
!(associatedDomain=somevalue) does
not imply (associatedDomain=*). Do you want to search for entries that
have associatedDomain and !(associatedDomain=somevalue)?
Try a search filter like
'(&(associatedDomain=*)(associatedDomain=imausa.net)(!(associatedDomain=rachel.example.com)))'
That should first find only the entries that have the associatedDomain
attribute.
If that doesn't work, try a sub-filter like
(&(associatedDomain=*)(&(associatedDomain=imausa.net)(!(associatedDomain=rachel.example.com))))
Otherwise, I'm not sure - not filters are problematic in this manner.
Regards,
Graham
--
------------------------------------------------------------------------
--
Fedora-directory-devel mailing list
Fedora-directory-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
noon
Rich Megginson wrote:
I think the problem is that having !(associatedDomain=somevalue) does
not imply (associatedDomain=*). Do you want to search for entries that
have associatedDomain and !(associatedDomain=somevalue)?
Try a search filter like
'(&(associatedDomain=*)(associatedDomain=imausa.net)(!(associatedDomain=rachel.example.com)))'
The filter I have is testing whether a specific known domain exists in
the directory, with the extra proviso that the name of the domain is not
allowed to be the name of the machine itself (thus the not part).
So it should be
(&(associatedDomain=example.com)(!(associatedDomain=machine.example.com))).
Am I correct in understanding that the first part of your query above
(associatedDomain=*) will limit the results within which to search for
the rest of the query?
That should first find only the entries that have the
associatedDomain
attribute.
If that doesn't work, try a sub-filter like
(&(associatedDomain=*)(&(associatedDomain=imausa.net)(!(associatedDomain=rachel.example.com))))
Otherwise, I'm not sure - not filters are problematic in this manner.
Hmmm... I have a second query, which could be problematic, that looks
like this:
(&(|(mail=%s)(mailAlternateAddress=%s))(!(mailHost=$myhostname)))
The idea is that if the mail is known to the LDAP server (and thus the
mail cluster), but is not hosted on this local box, the mail will be
delivered to the box in the cluster that does host the mail.
The trouble is, just doing a (!(mailHost=$myhostname)) is likely to
potentially return a lot of records, however the and part before it
should isolate the exact user first, thus removing the need to query the
entire directory to work out the not.
Does the directory do any kind of query optimisation while evaluating a
search query?
Regards,
Graham
--
12:06 p.m.
Graham Leggett wrote:
Rich Megginson wrote:
> I think the problem is that having !(associatedDomain=somevalue) does
> not imply (associatedDomain=*). Do you want to search for entries
> that have associatedDomain and !(associatedDomain=somevalue)?
> Try a search filter like
>
'(&(associatedDomain=*)(associatedDomain=imausa.net)(!(associatedDomain=rachel.example.com)))'
The filter I have is testing whether a specific known domain exists in
the directory, with the extra proviso that the name of the domain is not
allowed to be the name of the machine itself (thus the not part).
So it should be
(&(associatedDomain=example.com)(!(associatedDomain=machine.example.com))).
Am I correct in understanding that the first part of your query above
(associatedDomain=*) will limit the results within which to search for
the rest of the query?
Apart from implementation issues, a filter like "(!(attr=value))"
matches all entries whose values of "attr" differ from "value", *and*
all entries without "attr" at all. That's why Rich's suggestion should
work. In fact, "(attr=*)" makes use of the "presence" index, while
"(!(attr=value))" makes use of the "equality" index. If the
"look
through" limit applies to selected candidates, if you have presence
indexes in place for "attr" but no equality indexes, the difference
between your query and the one Rich suggested is exactly *all* - entries
with "attr", which could really make the difference between 7000 and 50.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
5685
days inactive
5685
days old
389-devel@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Graham Leggett -
Pierangelo Masarati -
Rich Megginson