[Issue 9729] New: Allow setting multiprovider before adding syncrepl stanzas
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9729
Issue ID: 9729
Summary: Allow setting multiprovider before adding syncrepl
stanzas
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
It should be possible to set multiprovider first, avoiding the window of the DB
being read-only while performing an online upgrade of a single provider to an
MPR set up and generally simplifying configuration.
Instead, the only requirement should be that serverID has been explicitly set
(hopefully != 0).
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year
[Issue 9493] New: slapo-accesslog handling of deletion of multi-valued configuration attributes removes wrong value from list
by openldap-its@openldap.org
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.
1 year, 1 month
[Issue 9282] New: Syncrepl re-creates deleted entry
by openldap-its@openldap.org
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.
1 year, 1 month
[Issue 9356] New: Add list of peerSIDs to consumer cookie to reduce cross traffic
by openldap-its@openldap.org
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.
1 year, 2 months
[Issue 9732] New: OpenLDAP TLS ciphersuite and groups limit issue
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9732
Issue ID: 9732
Summary: OpenLDAP TLS ciphersuite and groups limit issue
Product: OpenLDAP
Version: 2.4.54
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: narayananballem(a)gmail.com
Target Milestone: ---
Hi Team,
Hope you can help with this issue.
I am trying to disable SSLV3 on OpenLDAP servers we are using OpenLDAP as a
proxy with upstream Active directory servers. we are using CA certs on this
openssl we would like to disable SSLV3
I added the below entry slapd.conf but when I tried to start slapd it's failing
to start
TLSCipherSuite HIGH:MEDIUM:!SSLv2:!SSLV3
errors as below
slapd[19899]: main: TLS init def ctx failed: -1
slapd[19899]: slapd stopped.
slapd[19899]: connections_destroy: nothing to destroy.
debug logs restart as below
TLS: could not set cipher list HIGH:MEDIUM:!SSLv2:!SSLV3.
617c64c1 main: TLS init def ctx failed: -1
617c64c1 slapd stopped.
Also, did anybody notice this issue?
I am facing the issue with a group display we have several users in group while
looking for groups in getent group we are seeing a few groups not sure if there
is any limit on group filed in Database
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 3 months
[Issue 9719] New: refreshOnly sends empty cookie when client up to date
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9719
Issue ID: 9719
Summary: refreshOnly sends empty cookie when client up to date
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: ---
Syncprov will send an empty cookie if the consumer has the same cookie as
provider. To the best of my knowledge this is not in line with RFC4533 and
consumers would effectively drop their cookie when the search finishes.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 3 months
[Issue 9393] New: Provider a LDAP filter validation function
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9393
Issue ID: 9393
Summary: Provider a LDAP filter validation function
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: best(a)univention.de
Target Milestone: ---
In many situations I need to validate if a user submitted LDAP filter has valid
syntax.
It seems there is no official function to check this.
Could you provide one?
libraries/libldap/filter.c: ldap_pvt_put_filter() can be used as a basis.
--
My current workaround is using a unconnected ldap connection and do a search
with that filter. This yields a FILTER_ERROR (invalid filter) or a SERVER_DOWN
error (invalid filter).
See also:
https://github.com/python-ldap/python-ldap/pull/272
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 3 months