https://bugs.openldap.org/show_bug.cgi?id=9576
Issue ID: 9576
Summary: Add ConfigTable link into ConfigArgs
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: enhancement
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Would make it possible to examine defaults if necessary.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9493
Issue ID: 9493
Summary: slapo-accesslog handling of deletion of multi-valued
configuration attributes removes wrong value from list
Product: OpenLDAP
Version: 2.4.57
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: svella(a)technologist.com
Target Milestone: ---
I observed this in the debugger while working on a small feature addition to
slapo-accesslog.
log_cf_gen(), when handling the initial configuration of oldAccessLogOldAttr
(accesslog.c:989), linked list li_oldattrs is being built by inserting each
value in order at the head of the list, resulting in the list being in reverse
order. But when handling LDAP_MOD_DELETE of same attribute (accesslog.c:989),
it is using the index of the removed value (valx) to find and removed the entry
in the linked list, but it's counting from the head of li_oldattrs and not the
tail, resulting in the wrong item being removed from the list unless counting
from the head or the tail happens find the same item.
(Line numbers refer to commit 6c469f07935e351e349bf38fc223dab704c51a76)
Handling of oldAccessLogBase appears to have the same problem, and a cursory
glance through the source of other overlays reveals a similar pattern, and I'm
guessing the same problem.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9282
Issue ID: 9282
Summary: Syncrepl re-creates deleted entry
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Scenario:
2 node Multi-provider replication
Add database to provider A
ensure database replicates to provider B
Stop provider A
delete entry on provider B
Start provider A
Wait for provider B to reconnect to provider A
Deleted entry re-appears
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9356
Issue ID: 9356
Summary: Add list of peerSIDs to consumer cookie to reduce
cross traffic
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If we add a list of peersids to the cookie, each consumer can tell the
providers who else the consumers talk to and then the provider can omit sending
updates to that consumer, originating from those peers
There's some special handling needed if a connection dies
If a consumer loses one of its peer connections, and after N retries is still
not connected, it should send a new cookie to its remaining peers saying
"here's my new peer list" with the missing one removed. Likewise, if a retry
eventually connects again, it can send a new cookie again
Make that peer list reset configurable in the syncrepl config stanza. This can
help account for end admin knowledge that some links may be more or less stable
than other ones.
The idea here is that if one of your other peers can still see the missing
peer, they can start routing updates to you again
It should abandon all existing persist sessions and send a new sync search with
the new cookie to all remaining peers
For consumer side, also means adding the sid for a given provider into the
syncrepl stanza to save on having to try and discover the peer sid.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9492
Issue ID: 9492
Summary: Add local logging capa
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: mhardin(a)symas.com
Target Milestone: ---
Enhancement request: Add capability to slapd to log to a local file with log
rotation features. Log format should not change from syslog-generated log
style.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9575
Issue ID: 9575
Summary: Object class olcGlobal should not allow
olcPasswordHash
Product: OpenLDAP
Version: 2.5.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Object class olcGlobal should not allow olcPasswordHash because slapd will
crash during start if attribute is set.
Reported in this thread:
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9536
Issue ID: 9536
Summary: back-asyncmeta crashes when traffic is directed to a
new database, created via cn=config
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
A new back-asyncmeta database is successfully created via cn=config, but the
first LDAP request it tries to proxy causes a segmentation fault:
0# 0x00007F4C1E346629 in
/usr/src/backend/src/main/c++/overlay-proxy/.libs/overlay_proxy-2.4.so.0
1# 0x00007F4C26D701E0 in /lib64/libc.so.6
2# pthread_mutex_lock in /lib64/libpthread.so.0
3# ldap_pvt_thread_mutex_lock in /usr/local/libexec/slapd
4# asyncmeta_getconn in /usr/local/libexec/slapd
5# asyncmeta_back_add in /usr/local/libexec/slapd
6# fe_op_add in /usr/local/libexec/slapd
7# overlay_op_walk in /usr/local/libexec/slapd
8# 0x00000000004D8EFB in /usr/local/libexec/slapd
9# 0x00000000004D90DC in /usr/local/libexec/slapd
10# do_add in /usr/local/libexec/slapd
11# 0x0000000000445B20 in /usr/local/libexec/slapd
12# 0x00000000004460FB in /usr/local/libexec/slapd
13# 0x0000000000563C54 in /usr/local/libexec/slapd
14# 0x00007F4C270FB569 in /lib64/libpthread.so.0
15# clone in /lib64/libc.so.6
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9581
Issue ID: 9581
Summary: Add precision setting for slapd lastbind setting
Product: OpenLDAP
Version: 2.5.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The lastbind functionality that was imported into slapd for 2.5 is missing the
ability to fine tune the precision with which to allow the updates that was
present in the original overlay. It would be nice to have an option for it.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9599
Issue ID: 9599
Summary: Additional balancing strategies for lloadd
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
At the moment, lloadd picks a backend on a round-robin basis, taking the first
one that can deal with the request. This has several disadvantages:
- there is no way to implement a failover set up where certain (e.g. local)
servers should be contacted as a priority
- all balancing is implicit on the limits imposed on servers - a
connection/server is a candidate until we've reached those limits
Allowing a priority and/or a different strategy to be set should address these.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9598
Issue ID: 9598
Summary: Restricted operation routing in lloadd
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Lloadd is not supposed to understand the LDAP protocol and is happy to route
operations to whichever connection is available, but this can backfire in
certain ways:
- there are controls and extended operations that establish an shared context
on the connection (paged results, TXN, ...)
- it might take a measurable amount of time before a write operation is
propagated to other servers
There should be a way to force some of these to a chosen backend/upstream
connection temporarily or even permanently based on the OID of the
extop/control in question.
--
You are receiving this mail because:
You are on the CC list for the issue.