https://bugs.openldap.org/show_bug.cgi?id=8912
--- Comment #6 from Cliff <cwheat(a)sterlingandzoe.info> ---
On Fedora Core 36,
@(#) $OpenLDAP: slapd 2.6.2 (Aug 15 2022 00:00:00) $
openldap
Included static backends:
config
ldif
monitor
mdb
using LDAP Browser\Editor v2.8.1:
While attempting to add subordinate naming contexts off of base DN ""
(RootDSE), slapd will only show such subordinate naming contexts if they are of
the same RDN attribute. For instance, using all of FC36's trusted CA
certificates DN, which boil down to those based at c=?, or o=?, only those of
the same attribute will display as subordinates to "". I either get all c= or
o=, but not both. The subordinate naming context attribute that comes in the
configuration file determines which attribute will be shown.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9905
Issue ID: 9905
Summary: The test case 043 execution failed
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: 1010881517(a)qq.com
Target Milestone: ---
Test case 043 failed after I added #9823 pr to my openldap-2.6.0.
Some logs may be useful to you.
>>>>> Starting test043-delta-syncrepl for mdb...
running defines.sh
Starting provider slapd on TCP/IP port 9011...
Using ldapsearch to check that provider slapd is running...
Using ldapadd to create the context prefix entries in the provider...
Starting consumer slapd on TCP/IP port 9012...
Using ldapsearch to check that consumer slapd is running...
Using ldapadd to populate the provider directory...
Waiting 7 seconds for syncrepl to receive changes...
Stopping the provider, sleeping 10 seconds and restarting it...
Using ldapsearch to check that provider slapd is running...
Using ldapmodify to modify provider directory...
Waiting 7 seconds for syncrepl to receive changes...
Using ldapsearch to read all the entries from the provider...
Using ldapsearch to read all the entries from the consumer...
Filtering provider results...
Filtering consumer results...
Comparing retrieved entries from provider and consumer...
Stopping consumer to test recovery...
Modifying more entries on the provider...
Restarting consumer...
Waiting 7 seconds for syncrepl to receive changes...
Try updating the consumer slapd...
Waiting 7 seconds for syncrepl to receive changes...
Using ldapsearch to read all the entries from the provider...
Using ldapsearch to read all the entries from the consumer...
Filtering provider results...
Filtering consumer results...
Comparing retrieved entries from provider and consumer...
Stopping consumer to test recovery after logpurge expired...
Modifying even more entries on the provider...
Configuring logpurge of 1 second...
Waiting 4 seconds for accesslog to be purged...
Using ldapsearch to check if accesslog is empty...
Restarting consumer...
Waiting 7 seconds for syncrepl to receive changes...
Using ldapsearch to read all the entries from the provider...
Using ldapsearch to read all the entries from the consumer...
Filtering provider results...
Filtering consumer results...
Comparing retrieved entries from provider and consumer...
test failed - provider and consumer databases differ
>>>>> Failed test043-delta-syncrepl for mdb after 0 seconds
(exit 1)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9358
Issue ID: 9358
Summary: back-mdb may return accesslog entries out of order
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
back-mdb will usually return search entries in entryID order, but may do a dn
traversal instead if the count of children is smaller than the count of search
filter candidates. The RDNs are sorted in length order, not lexical order. For
accesslog, all RDNs are of equal length but if they have trailing zeroes, the
generalizedTime normalizer truncates them. Changing their lengths causes
accesslog's timestamp-based RDNs to sort in the wrong order.
The least intrusive fix is to override the syntax/normalizer for reqStart and
reqEnd attributes to not truncate trailing zeroes.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8064
Ondřej Kuzník <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=9906
--
You are receiving this mail because:
You are on the CC list for the issue.