[Issue 9612] New: Change index_hash64 default to on
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9612
Issue ID: 9612
Summary: Change index_hash64 default to on
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Change the default value of index_hash64. By default this means slapd won't
run on a 32-bit CPU (It will continue to work on 32-bit OSes running on 64-bit
CPUs).
If someone needs to run slapd on a 32-bit CPU they can turn this option off.
In the documentation, mark the option as deprecated for eventual removal in a
future release.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month
[Issue 9580] New: Refresh vs. accesslog in delta-MPR
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9580
Issue ID: 9580
Summary: Refresh vs. accesslog in delta-MPR
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: replication
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
A server consuming a plain syncrepl session (might be a delta-MMR refresh)
still has to log the entries into accesslog, however that accesslog stops being
capable of serving as a delta-sync source:
- operation entryCSNs will be out-of-order
- the changes logged will not be the intended modifications (e.g. if we fell
back after a conflict, the conflicting entry will be replaced with the other
version, other examples available)
We need to deal with that somehow, at the very least we need to make sure the
consumer will not take them at face value. We could record this in the
accesslog root entry if we can detect when this starts and match it up with the
final cookie, syncprov would still need some tweaks to understand it.
We could mark the entries received this way and make sure delta-consumers treat
them as "poison", as if they were running a plain syncrepl session themselves
(not update contextCSN until that's finished, mark its own accesslog entries
this way, ...). Anything like that needs guarantees that it will clean itself
up once all of the real plain sessions finish otherwise we've lost delta-sync
altogether.
A different approach might or might not be needed for live delta-persist
sessions replicating from a refreshing provider, but at least that syncprov has
a way of detecting this live if it chooses to.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month
[Issue 9341] New: Delta-sync MPR needs to be stable regardless of ordering
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9341
Issue ID: 9341
Summary: Delta-sync MPR needs to be stable regardless of
ordering
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: replication
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If two or more updates are spread across several providers before they have a
chance to learn about the others, all replicas need to arrive at the same
content regardless of the order in which they arrive.
One example that is broken at the moment:
- (csn a) server 1 accepts a modify
- (csn b) server 2 accepts a delete on the same DN
- (csn c) server 2 accepts an add on that DN again
If a replica receives the actions in the order bca vs. abc, the content of the
entry will be different even though the final CSN set is the same -> they will
never converge. The ordering 'bac' also needs to result in eventual
convergence, even if it means a refresh or replication from either provider
stalling temporarily?
Merge request with this test case (so far):
https://git.openldap.org/openldap/openldap/-/merge_requests/145
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month
[Issue 9577] New: slapd -V should be deprecated
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9577
Issue ID: 9577
Summary: slapd -V should be deprecated
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: smckinney(a)symas.com
Target Milestone: ---
Sometimes a user's (present one included) ignorance gets them in trouble
unnecessarily. The -V option is an example...
Normally, when one wants to determine the version of a process, they use -V, or
perhaps -v. With slapd, the daemon actually continues to run, which can have
negative consequences.
The doc clearly states that -VV is probably what the user wants, but is
counter-intutive. Who RTFM's before checking the version?
-V print version info (-VV exit afterwards, -VVV print
info about static overlays and backends)
I propose we eliminate the option to allow slapd to continue running after
displaying the version. Perhaps we eliminate the -V option entirely, or just
make it work the same as -VV.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month
[Issue 9547] New: OpenLDAP does not send port as SPN when authenticating SASL GSSAPI
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9547
Issue ID: 9547
Summary: OpenLDAP does not send port as SPN when authenticating
SASL GSSAPI
Product: OpenLDAP
Version: 2.4.44
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: robert.wilson1717(a)gmail.com
Target Milestone: ---
When trying to authenticate to an ADLDS server using kerberos and a MIT ccache,
OpenLdap only passes the hostname to the SASL mechanism, causing a mismatch
between the SPN in the client "ldap/adlds.my.domain" and the one registered in
AD "ldap/adlds.my.domain:50000"
Is there a way fo forcing OpenLDAP to pass the port as part of the SASL
request? Or is there a part of the OpenLDAP -> Cyprus-SASL -> MIT KRB5 chain
where this can be enabled?
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month
[Issue 9398] New: Stale accesslog cookie due to unclean shutdown
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9398
Issue ID: 9398
Summary: Stale accesslog cookie due to unclean shutdown
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If slapd terminates uncleanly, a checkpoint will be lost on the accesslog db.
Depending on the syncprov overlay checkpoint settings (usually no checkpointing
is enabled on the accesslog db) this can cause the system to refuse engage in
replication at startup.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month
[Issue 9506] New: dynlist: member expansion when member attribute not requested
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9506
Issue ID: 9506
Summary: dynlist: member expansion when member attribute not
requested
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
When configured to do dynamic "member" expansion, i.e.:
overlay dynlist
dynlist-attrset groupOfURLs memberURL member
Any query against an object that would trigger this expansion will incur a
penalty while dynlist does the expansion work even if there was no request for
the member attribute.
Currently that can be worked around by specifying the manageDSAit control when
doing a search on the object, but this may not be feasible for some client
applications and additionally other directory servers do not do this expansion
for their dynamic group implementations unless the underlying configured
attribute is explicitly requested.
We've already implemented this in dynlist for the memberOfAD case, we should do
it here as well.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month
[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 month
[Issue 9305] New: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9305
Issue ID: 9305
Summary: ldap_connect_to_host: Return code from getaddrinfo()
discarded, troubleshooting difficult
Product: OpenLDAP
Version: 2.4.46
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: minfrin(a)sharp.fm
Target Milestone: ---
When the ldap_connect_to_host() function sees a failure from getaddrinfo(), the
meaningless return code -1 is returned.
This makes troubleshooting difficult on a webserver, where the low level printf
debugging is not practical.
(gdb) step
ldap_connect_to_host (ld=ld@entry=0x7fffc4002e10, sb=0x7fffc400b240, proto=1,
srv=srv@entry=0x7fffc400b2f0, async=async@entry=0) at os-ip.c:543
543 {
(gdb) next
546 ber_socket_t s = AC_SOCKET_INVALID;
(gdb)
562 if ( srv->lud_host == NULL || *srv->lud_host == 0 ) {
(gdb)
568 port = srv->lud_port;
(gdb)
570 if( !port ) {
(gdb)
578 switch(proto) {
(gdb)
580 osip_debug( ld,
(gdb)
warning: Source file is more recent than executable.
71 return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
(gdb)
598 hints.ai_flags = AI_ADDRCONFIG;
(gdb)
601 hints.ai_socktype = socktype;
(gdb)
602 snprintf(serv, sizeof serv, "%d", port );
(gdb)
605 LDAP_MUTEX_LOCK(&ldap_int_resolv_mutex);
(gdb)
607 err = getaddrinfo( host, serv, &hints, &res );
(gdb)
609 LDAP_MUTEX_UNLOCK(&ldap_int_resolv_mutex);
(gdb)
611 if ( err != 0 ) {
(gdb)
612 osip_debug(ld, "ldap_connect_to_host: getaddrinfo
failed: %s\n",
(gdb) print host
$3 = <optimized out>
(gdb) print serv
$4 = "636\000\000\000"
(gdb) next
614 return -1;
(gdb)
The ldap_connect_to_host() function needs to return proper error codes.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month
[Issue 9303] New: Add support for WolfSSL as an alternative to OpenSSL
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9303
Issue ID: 9303
Summary: Add support for WolfSSL as an alternative to OpenSSL
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
For OpenLDAP 2.6, we should investigate adding support for WolfSSL as an
alternative to OpenSSL.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month