Hi all,
I am still really struggling with something that should be a simple query, but isn't. I have a filter that returns just one single result, as follows:
[25/May/2013:20:54:16 +0100] conn=82 op=10 SRCH base="o=Foo,c=GB" scope=2 filter="(&(associatedDomain=example.com)(!(associatedDomain=host.example.com)))" attrs="associatedDomain" [25/May/2013:20:54:17 +0100] conn=82 op=10 RESULT err=4 tag=101 nentries=1 etime=1 notes=U
This query however returns the following error:
Search error 4: Size limit exceeded
The "notes=U" in the log gives an excessively cryptic clue - the query wasn't indexed, and the error message seems to be misleading, as it doesn't seem to be the size limit that is exceeded, but rather the time limit.
I have indexed the associatedDomain attribute as follows:
dn: cn=associatedDomain,cn=default indexes,cn=config,cn=ldbm database,cn=plu gins,cn=config objectClass: nsIndex objectClass: top cn: associatedDomain nsSystemIndex: false nsIndexType: eq
Am I correct in understanding that a "eq" index is not enough to handle the "not" part of the filter above?
What do you have to do to index a "not" filter?
Regards, Graham --
On 25 May 2013, at 10:00 PM, Graham Leggett minfrin@sharp.fm wrote:
I have indexed the associatedDomain attribute as follows:
dn: cn=associatedDomain,cn=default indexes,cn=config,cn=ldbm database,cn=plu gins,cn=config objectClass: nsIndex objectClass: top cn: associatedDomain nsSystemIndex: false nsIndexType: eq
It just gets weirder and weirder.
We start with no index on the associatedDomain attribute:
[root@monica slapd-monica]# ls -al /var/lib/dirsrv/slapd-monica/db/userRoot/associatedDomain.db4 ls: cannot access /var/lib/dirsrv/slapd-monica/db/userRoot/associatedDomain.db4: No such file or directory
I ask 389ds to create the index on associatedDomain:
[root@monica slapd-monica]# ./db2index.pl -D "cn=Directory Manager" -w - -n userRoot -t associatedDomain Bind Password: adding new entry "cn=db2index_2013_5_25_21_21_43, cn=index, cn=tasks, cn=config"
I watch the log file, 389ds goes through the motions of creating an index on associatedDomain:
[25/May/2013:21:21:42 +0100] - userRoot: Indexing attribute: associatedDomain [snip] [25/May/2013:21:22:11 +0100] - userRoot: Finished indexing.
We end with no index on the associatedDomain attribute, no error message, no nothing:
[root@monica slapd-monica]# ls -al /var/lib/dirsrv/slapd-monica/db/userRoot/associatedDomain.db4 ls: cannot access /var/lib/dirsrv/slapd-monica/db/userRoot/associatedDomain.db4: No such file or directory
This is RHEL6 with 389-ds-base-1.2.11.15-14.el6_4.x86_64.
I am completely stuck, has anybody experienced weirdness like this before? Am I doing the right thing to create the index? Is there some way of coaxing an error of any kind out of 389ds?
Regards, Graham --
On 25 May 2013, at 10:27 PM, Graham Leggett minfrin@sharp.fm wrote:
It just gets weirder and weirder.
We start with no index on the associatedDomain attribute:
[root@monica slapd-monica]# ls -al /var/lib/dirsrv/slapd-monica/db/userRoot/associatedDomain.db4 ls: cannot access /var/lib/dirsrv/slapd-monica/db/userRoot/associatedDomain.db4: No such file or directory
I ask 389ds to create the index on associatedDomain:
[root@monica slapd-monica]# ./db2index.pl -D "cn=Directory Manager" -w - -n userRoot -t associatedDomain Bind Password: adding new entry "cn=db2index_2013_5_25_21_21_43, cn=index, cn=tasks, cn=config"
I watch the log file, 389ds goes through the motions of creating an index on associatedDomain:
[25/May/2013:21:21:42 +0100] - userRoot: Indexing attribute: associatedDomain [snip] [25/May/2013:21:22:11 +0100] - userRoot: Finished indexing.
We end with no index on the associatedDomain attribute, no error message, no nothing:
Got to the bottom of this.
Should the two master servers not agree on the schema, most specifically schema elements on server A are missing from server B, the index generation process will fail silently, and return a message saying "Finished indexing" above.
This fools the admin into thinking the attribute has been successfully indexed when no indexing took place.
Hopefully this will help someone else.
Regards, Graham --
On 05/26/2013 02:50 PM, Graham Leggett wrote:
On 25 May 2013, at 10:27 PM, Graham Leggett minfrin@sharp.fm wrote:
It just gets weirder and weirder.
We start with no index on the associatedDomain attribute:
[root@monica slapd-monica]# ls -al /var/lib/dirsrv/slapd-monica/db/userRoot/associatedDomain.db4 ls: cannot access /var/lib/dirsrv/slapd-monica/db/userRoot/associatedDomain.db4: No such file or directory
I ask 389ds to create the index on associatedDomain:
[root@monica slapd-monica]# ./db2index.pl -D "cn=Directory Manager" -w - -n userRoot -t associatedDomain Bind Password: adding new entry "cn=db2index_2013_5_25_21_21_43, cn=index, cn=tasks, cn=config"
I watch the log file, 389ds goes through the motions of creating an index on associatedDomain:
[25/May/2013:21:21:42 +0100] - userRoot: Indexing attribute: associatedDomain [snip] [25/May/2013:21:22:11 +0100] - userRoot: Finished indexing.
We end with no index on the associatedDomain attribute, no error message, no nothing:
Got to the bottom of this.
Should the two master servers not agree on the schema, most specifically schema elements on server A are missing from server B, the index generation process will fail silently, and return a message saying "Finished indexing" above.
This fools the admin into thinking the attribute has been successfully indexed when no indexing took place.
Hopefully this will help someone else.
Can you please file a ticket - fixing this in the source is the best way to help someone else.
Regards, Graham --
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org
-
Graham Leggett -
Rich Megginson