https://bugs.openldap.org/show_bug.cgi?id=9728
Issue ID: 9728
Summary: For lastbind-precision, note it is important in busy
replicated environments
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
It would be good to note in the slapd.conf(5)/slapd-config(5) man pages that
the lastbind-precision setting can be very important to set in busy, replicated
environments.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9727
Issue ID: 9727
Summary: slapd-watcher fails to start if any slapd instance is
down
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: gnoe(a)symas.com
Target Milestone: ---
When starting slapd-watcher and slapd isn't running on one of the monitored
servers, slapd-watcher fails to start:
Example w/host2 slapd not running:
[user@host]# slapd-watcher -xD dc=example,dc=com -w secret -b
dc=example,dc=com -s 1,2 ldap://host1/ ldap://host2/
slapd-watcher PID=11892: ldap_sasl_bind_s: Can't contact LDAP server (-1)
I would expect that slapd-watcher would start up completely and indicate the
host was down, like in the case where a host goes down while slapd-watcher is
running. This would allow slapd-watcher to start when one or more replication
node is down for maintenance.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9733
Issue ID: 9733
Summary: ppolicy.c:66:2: error: unknown type name ‘lt_dlhandle’
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: smillerdev(a)me.com
Target Milestone: ---
On both Linux and macOS in Homebrew, there is a failure trying to compile
OpenLDAP 2.6.0:
/bin/sh ../../../libtool --tag=disable-shared --mode=compile gcc-5 -g -O2
-I../../../include -I../../../include -I.. -I./.. -I./../slapi -c log.c
ppolicy.c:66:2: error: unknown type name ‘lt_dlhandle’
lt_dlhandle pwdCheckHandle; /* handle from lt_dlopen */
^
on macOS there is also an additional errror:
ppolicy.c:458:4: error: initializer element is not a compile-time constant
(void *)offsetof(pp_info,hash_passwords),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See https://github.com/Homebrew/homebrew-core/pull/88036 for the full output
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9691
Issue ID: 9691
Summary: Allow syncrepl persist sessions against empty DBs
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review, replication
Severity: enhancement
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
One way to set up an environment is to start with a completely empty DB,
configure all nodes and replication paths and then populate them.
Right now, the syncrepl sessions get rejected with a 32 NO_SUCH_OBJECT,
triggering the retry cascade. Both the consumer and provider have an empty
cookie, so they are in sync and we could actually transition to a persist phase
and let the session proceed.
This way the environment would start replicating almost immediately after first
entries are added. Mind that ITS#9584 still pushes concurrent refreshes into
the retry logic adding a short delay before *all* configured links are set up.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9751
Issue ID: 9751
Summary: Delta-MPR resolution too eager to drop attribute
deletes
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review, replication
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
syncrepl_resolve_cb will completely drop an attribute delete (or the delete
part of replace) if there's a "newer" (timestamp-wise) op touching the same
attribute.
This way servers processing the "out of order" write end up keeping values that
should have been removed (and have been on those that received it in the
natural order).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9756
Issue ID: 9756
Summary: syncprov_play_accesslog doesn't check minCSN properly
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
When asked to replay the accesslog database for a refresh delete, syncprov
doesn't interpret the minCSN data correctly, resulting in:
- an inaccurate refresh if a purge removed some important data in the meantime
- potentially a very expensive query when consumer is actually up to date
w.r.t. to some sids in our contextCSN
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9752
Issue ID: 9752
Summary: Improperly normalized minCSN values in accesslog
Product: OpenLDAP
Version: 2.5.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
The CSN matching rules require normalized values to be provided. When
normalized values are provided to attr_merge they must be distinct from the
regular values. accesslog.c:1982 is providing the same berval in both regular
and normalized value, which triggers an assert failure for this consistency
check.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9747
Issue ID: 9747
Summary: dynlist overlay breaks member compare operation for
groups
Product: OpenLDAP
Version: 2.5.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: henson(a)acm.org
Target Milestone: ---
Given the following group:
dn: uid=unxadmin,ou=group,dc=cpp,dc=edu
objectClass: groupOfNames
objectClass: cppGroup
objectClass: posixGroup
uid: unxadmin
cn: Unix Administrators
gidNumber: 17730
member:
member: uid=gkuri,ou=user,dc=cpp,dc=edu
member: uid=henson,ou=user,dc=cpp,dc=edu
memberUid: gkuri
memberUid: henson
and the following dynlist config:
dynlist-attrset groupOfURLs memberURL member+memberOf@groupOfNames
ldap compare operations checking group membership fail erroneously:
# ldapcompare -x -H ldaps://ldap-vmc-01.ldap.cpp.edu/
uid=unxadmin,ou=group,dc=cpp,dc=edu member:uid=henson,ou=user,dc=cpp,dc=edu
FALSE
If the dynlist-attrset configuration is removed, the compare works as expected:
# ldapcompare -x -H ldaps://ldap-vmc-01.ldap.cpp.edu/
uid=unxadmin,ou=group,dc=cpp,dc=edu member:uid=henson,ou=user,dc=cpp,dc=edu
TRUE
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9749
Issue ID: 9749
Summary: logoldattr documentation is misleading
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Reading the accesslog manpage, someone might expect that attributes specified
in logoldattr would be logged regardless of whether the entry being modified
matches any of the configured filters. This is not the case and should be
clarified.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9707
Issue ID: 9707
Summary: Documentation synchronisation ODSEE --> openldap
Product: OpenLDAP
Version: 2.5.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: laurent.revillion(a)icloud.com
Target Milestone: ---
There is no documentation about the synchronisation between ODSEE and Openldap
2.5.
Will there be one?
--
You are receiving this mail because:
You are on the CC list for the issue.