https://bugs.openldap.org/show_bug.cgi?id=10173
Issue ID: 10173
Summary: Accesslog bootstrap doesn't populate minCSN internally
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 a new accesslog DB is being set up from zero but a main DB exists, the
correct minCSN is pushed into the auditContainer entry but li_mincsn et al are
not set up internally. Fix is coming.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10177
Issue ID: 10177
Summary: back-perl build for clang15
Product: OpenLDAP
Version: 2.5.17
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
back-perl cannot be built with clang15 on RHEL9.
The following error occurs:
```
libtool: link: clang -shared -fPIC -DPIC .libs/init.o .libs/search.o
.libs/close.o .libs/config.o .libs/bind.o .libs/compare.o .libs/modify.o
.libs/add.o .libs/modrdn.o .libs/delete.o .libs/version.o -Wl,-rpath
-Wl,/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/libldap/.libs
-Wl,-rpath
-Wl,/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs
-Wl,-rpath -Wl,/usr/local/lib
-L/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs
-L/usr/local/lib -L/usr/lib64/perl5/CORE -lperl -lpthread -lresolv -ldl -lm
-lcrypt -lutil ../../../libraries/libldap/.libs/libldap.so
/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs/liblber.so
-lsasl2 -lssl -lcrypto ../../../libraries/liblber/.libs/liblber.so -g -O0
-Wl,--enable-new-dtags -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -Wl,-z
-Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -fstack-protector-strong -Wl,-soname
-Wl,back_perl-2.5.so.0 -o .libs/back_perl-2.5.so.0.1.12
.libs/init.o: file not recognized: file format not recognized
clang-15: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [Makefile:348: back_perl.la] Error 1
make: Leaving directory
'/home/hamano/tmp/openldap-2.5.17/build-clang15/servers/slapd/back-perl'
```
The cause is that the `-flto=auto` flag prevents the generation with ELF
format.
```
$ file servers/slapd/back-perl/.libs/init.o
servers/slapd/back-perl/.libs/init.o: LLVM IR bitcode
```
I'll open gitlab PR.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10179
Issue ID: 10179
Summary: back-asyncmeta(5) man page incorrectly mentions
"rewrite"
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Man page for back-asyncmeta mentions the rewrite options, yet asyncmeta does
not support the rewrite engine at the moment.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10164
Issue ID: 10164
Summary: back-meta hangs when used with dynlist overlay
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
When back-meta is configured with the dynlist overlay, on a search request that
triggers dynlist, it will hang. This happens because of a bug in back-meta that
is only revealed when an overlay issues an internal operation while processing
a result or an entry, as dynlist does, as apposed to issuing it when the client
op is first received ( on the way "down" to the backend).
The issue is reproduced by configuring dynlist over a back-meta database, and
sending a subtree search request with the database suffix as dn.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9921
Issue ID: 9921
Summary: Tautology in clients/tools/common.c:print_vlv()
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm…
contains:
tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
ldif ? "vlvResult" : "vlvResult", buf, rc );
The second parameter is always vlvResult, irrespective of the value of ldif.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10082
Issue ID: 10082
Summary: More dynlist eval tweaks
Product: OpenLDAP
Version: 2.5.14
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: ---
When the memberOf attribute is a user attribute instead of operational, it will
be expanded on any search for (all user attributes). If the search is filtering
on objectclasses that don't contain this attribute, that's wasted work. Check
for a matching objectclass in the filter before doing that.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9193
Bug ID: 9193
Summary: HTML in mailing list description
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
e.g. https://lists.openldap.org/postorius/lists/openldap-devel.openldap.org/
contains code for links and formatting, but all inside of a <pre> block.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=10184
Issue ID: 10184
Summary: slapo-translucent
Product: OpenLDAP
Version: 2.6.3
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: marco.esposito(a)gmail.com
Target Milestone: ---
I am currently experiencing an issue with an OpenLDAP instance configured with
the slapo-translucent overlay.
After performing an ldapmodify:
# ldapmodify -x -D cn=Manager,dc=example,dc=com -W -H ldap:/// <<EOF
dn: uid=user,ou=People,dc=example,dc=com
changetype: modify
replace: uidNumber
uidNumber: 99
EOF
LDAP queries requesting only translucent local attributes do not return results
unless both the remote and local attributes are included in the filter. Here is
an example illustrating the behavior:
Query with both remote and local attributes in the filter after ldapmodify
(works correctly):
# ldapsearch -x -D "cn=Manager,dc=example,dc=com" -W -H ldap:/// -b
"ou=People,dc=example,dc=com" "(uid=user)" uid uidNumber
# extended LDIF
#
# LDAPv3
# base <ou=People,dc=example,dc=com> with scope subtree
# filter: uid=user
# requesting: uid uidNumber
#
# user, People, example.com
dn: uid=user,ou=People,dc=example,dc=com
uidNumber: 99
uid: user
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Query with only local attributes in the filter after ldapmodify (does not
return results):
# ldapsearch -x -D "cn=Manager,dc=example,dc=com" -W -H ldap:/// -b
"ou=People,dc=example,dc=com" "(uid=user)" uidNumber
# extended LDIF
#
# LDAPv3
# base <ou=People,dc=example,dc=com> with scope subtree
# filter: uid=user
# requesting: uidNumber
#
# search result
search: 2
result: 0 Success
# numResponses: 1
While attempting to debug the issue, I believe the problem may be related to
the code in lines 928 - 940 of the file overlays/translucent.c:
https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/over…
Specifically, I suspect that the issue may be related to the conditions within
the 'if' statement.
I have carefully reviewed the slapd instance configuration and overlay
settings, but I have not been able to identify the root cause. Any assistance
or advice on resolving this issue would be greatly appreciated.
Thank you for your time and support.
Best regards,
Marco
--
You are receiving this mail because:
You are on the CC list for the issue.