Please review: [Bug 513019] nsslapd-lookthroughlimit is not respected when the filter test failed in search
by Noriko Hosoi
https://bugzilla.redhat.com/show_bug.cgi?id=513019
Summary: nsslapd-lookthroughlimit is not respected when the
filter test failed in search
Product: 389
Version: 1.2.0
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: Database - Indexes/Searches
AssignedTo: nhosoi(a)redhat.com
ReportedBy: nhosoi(a)redhat.com
QAContact: ckannan(a)redhat.com
CC: sramling(a)redhat.com
Blocks: 434915
Estimated Hours: 0.0
Classification: Other
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.
[Proposed Fix]
Created an attachment (id=354532)
--> (https://bugzilla.redhat.com/attachment.cgi?id=354532)
git patch file for ldbm_search.c
File: ldap/servers/slapd/back-ldbm/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.
14 years, 9 months
USN Design Document
by Ivanov Andrey (M.)
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
the plug-in?
* 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
nsds5ReplicaTombstonePurgeInterval?
And thank you for your work!
14 years, 9 months
Please Review: (479753) Update core schema to latest defined in LDAP RFCs
by Nathan Kinder
https://bugzilla.redhat.com/show_bug.cgi?id=479753
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
implement.
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
https://bugzilla.redhat.com/attachment.cgi?id=353910&action=diff
14 years, 9 months
Please Review: Add additional standard syntaxes
by Nathan Kinder
This adds support for the following standard syntaxes, complete
with validation functions:
Bit String
Delivery Method
Enhanced Guide
Facsimile Telephone Number
Fax
Guide
Name And Optional UID
Printable String
Teletex Terminal Identifier
Telex Number
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:
http://nkinder.fedorapeople.org/0001-Add-additional-standard-syntaxes.patch
-NGK
14 years, 9 months
