First cut for implementing Entry USN.
See http://directory.fedoraproject.org/wiki/Entry_USN for the design
This change includes a bug fix for "db2ldif -r"; event queue system was not
shutdown before the plugins are closed, which could have crashed the
Summary: nsslapd-lookthroughlimit is not respected when the
filter test failed in search
Component: Database - Indexes/Searches
Estimated Hours: 0.0
Target Release: ---
Description of problem:
Bug report by Sankar Ramalingam:
Test Setup 1:
Simple paged with sorting with all default configuration values except
nsslapd-lookthroughlimit is set to 100
Added 400 users to the suffix.
Simple paged search request with normal user.
perl ./data/ldap_usr_search.pl -x -pg 90 "cn=test*" -S "cn" "dn"
Problem sorting, LDAP_ADMIN_LIMIT_EXCEEDED
next page size (90):
Result; This returns 90 entries and the ADMIN_LIMIT_EXCEEDED error.
perl ./data/ldap_usr_search.pl -x -pg 91 "cn=test*" -S "cn" "dn"
search failed: LDAP_ADMIN_LIMIT_EXCEEDED
Result: Search fails. Though the limit is set to 100, it fails for 91st entry.
Created an attachment (id=354532)
git patch file for ldbm_search.c
Fix Description: When filter test is necessary against the search results
and the test fails, lookthroughcount attached to the search result structure
should have been decremented since the entry will not be sent to the client,
but it was not. This change fixes it.
I've seen some changes in the USN design document, so i'll add my two
cents. Overall it's well written, the architecture seems to be rather
robust. There are some scenarious that are interesting for us as for
the behaviour of the usn plugin and some questions/reflections :
* The USNs seem to be unique within a suffix/backend. Should we enable
the uniqueness plug-in for them? If not can we be sure that a manual
change of entryUSN will not interfere with the correct functioning of
* When the plug-in is activated no entry has entryUSN or maybe some
entries do already have it in some desorder. Maybe we should
initialise (while plug-in in started for the VERY first time) all the
entries without entryUSN with entryUSN=-1 or smth like that?
* Maybe it's a good idea to desactivate the replication of entryUSN
attribute during the server installation by default?
* When we do an export with a utility like db2ldif.pl - should the
entryUSN attributes be exported or not?
* What happens during the import of a whole ldif subtree by smth like
"ldif2db -n userRoot -i /tmp/current_prod_database.ldif" if the
entryUSNs are already present in the imported ldif? If they are not
present? if they are present only in a part of the entries?
* Should usn-tombstone-cleanup be integrated in the server core with
the thread purging the tombstones ot not? Should it be configurable bo
some attributes like nsds5ReplicaPurgeDelay and
And thank you for your work!
Resolves: Bug 479753
Description: Update core schema to latest defined in LDAP RFCs
Fix Description: This patch updates and reorganizes our core schema to
follow the most recently defined standards. The layout of the core
schema files is as follows:
00core.ldif - RFC 4512, RFC 4519, LDAP Subentry Internet Draft
01core389.ldif - 389 specific schema (required to start server)
02common.ldif - 389 specific schema (highly recommended,
Changelog Internet Draft, plug-in schema)
05rfc2927.ldif - MIME Directory Profile for LDAP Schema
05rfc4523.ldif - Schema Definitions for X.509 Certificates
05rfc4524.ldif - Cosine LDAP/X.500 Schema
06inetorgperson.ldif - RFC 2798 (pulls in RFC 2079 and part of
the obsolete RFC 1274 due to required attributes)
There are still a handful of syntaxes that we don't support, so
I've substituted syntaxes for about 15 attributes. The schema and
DIT related description syntaxes are not supported, so I've used
the "Directory String" syntax instead in 00core.ldif. The
certificate syntaxes defined in 4523 are not supported, so I've
used the "Octet String" syntax instead. All of these deviations
are commented with a "TODO" listing the syntax that we need to
I have also updated the Mozilla address book schema to the latest
from upstream for a minor bug fix. I changed the nsSymmetricKey
attribute to use the "Octet String" syntax since the "Binary"
syntax is deprecated.
Platforms tested: F9 x86_64, F11 x86_64
This adds support for the following standard syntaxes, complete
with validation functions:
Facsimile Telephone Number
Name And Optional UID
Teletex Terminal Identifier
This patch does not change the schema to use any of these syntaxes
yet. That will come when we update to the current versions of the
standard schema from the LDAP RFCs.
I also fixed an error in makefile.am where Setup.pm was listed
twice in perl_DATA.
I have omitted the generated build files from the diffs. If you want
the full patch to apply to a local git tree, I made it available at: