https://bugs.openldap.org/show_bug.cgi?id=9769
Issue ID: 9769
Summary: Patch new feature batch get
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: rouzier(a)gmail.com
Target Milestone: ---
Created attachment 859
--> https://bugs.openldap.org/attachment.cgi?id=859&action=edit
New functionality mdb_cursor_get_batch
New functionality mdb_cursor_get_batch
mdb_cursor_get_batch retrieves a page worth of key/values.
This is to reduce the number of function calls when doing a scan of the
database.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8988
--- Comment #22 from noloader(a)gmail.com <noloader(a)gmail.com> ---
On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote:
>
> noloader(a)gmail.com wrote:
> > On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote:
> >>
> >> noloader(a)gmail.com wrote:
> >> ...
> >>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an
> >>> important project, and the undefined behavior is causing too many
> >>> tangential problems.
> >>
> >> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary
> >> part of the language for its intended use as a system programming language, writing
> >> machine-specific programs. Anyone who says it is prohibited by the spec is wrong.
The kernel recently got bitten using the same pattern of unaligned
short pointers through casts. GCC produced code which corrupted
initramfs during unpacking.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363.
OpenLDAP should fix that code.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9739
Issue ID: 9739
Summary: Undefined reference to ber_sockbuf_io_udp in 2.6.0
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: simon.pichugin(a)gmail.com
Target Milestone: ---
While I was trying to build OpenLDAP 2.6 on Fedora Rawhide I've got the error
message:
/usr/bin/ld: ./.libs/libldap.so: undefined reference to
`ber_sockbuf_io_udp'
I've checked commits from https://bugs.openldap.org/show_bug.cgi?id=9673 and
found that 'ber_sockbuf_io_udp' was not added to
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/…
I've asked on the project's mailing list and got a reply:
"That symbol only exists if OpenLDAP is built with LDAP_CONNECTIONLESS
defined, which is not a supported feature. Feel free to file a bug report
at https://bugs.openldap.org/"
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
Hence, creating the bug.
--
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=9765
Issue ID: 9765
Summary: slapd crash
Product: OpenLDAP
Version: 2.4.46
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: shivaprasadtp(a)yahoo.in
Target Milestone: ---
Start-up two slapd server instances. Configure syncreply overlay with one of
the servers as a provider and the other one as consumer. Create around 100
users. Now start changing syncrepl configuration for one of the slapd servers,
lets say the consumer server, in a loop with 5 seconds delay. After few mins
the slapd server crashes.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9757
Issue ID: 9757
Summary: The private key of the ldap certificate
Product: OpenLDAP
Version: 2.4.59
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ydgdsnn(a)163.com
Target Milestone: ---
Created attachment 856
--> https://bugs.openldap.org/attachment.cgi?id=856&action=edit
prikey.key
Current situation: The private key of the ldap certificate is used to set
LDAP_OPT_X_TLS_KEYFILE when bind, and this file is currently stored in plain
text.
Appeal: Can we store the ciphertext of the file, and then decrypt it when we
use it?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8485
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ydgdsnn(a)163.com
--- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
*** Issue 9757 has been marked as a duplicate of this issue. ***
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9754
Issue ID: 9754
Summary: segfault after adding olcAccess
Product: OpenLDAP
Version: 2.6.0
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: goudal(a)enseirb.fr
Target Milestone: ---
On a new production server 2.6.0 on ubuntu 20.04 LTS uptodate.
After adding an olcAccess attribute I got a segfault.
The aclValue added is
{9}to attrs=ipbCompteValide,ipbEtendue,mailForwardingAddress by
dn.base="uid=cptadmin,ou=people,dc=ipb,dc=fr" write by * read
(the ipbXXX attrs are local ones).
I have tried to add it twice and it did segfault twice.
Here are the last logs for the server (logLevel was on sync).
Nov 25 14:34:32 ldap2021 slapd[67824]: slap_graduate_commit_csn: removing
0x7f3a475615c0 20211125133351.609580Z#000000#00a#000000
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291397 MOD
dn="dc=ipb,dc=fr"
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291397 MOD attr=contextCSN
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291397 syncprov_matchops:
recording uuid for dn=dc=ipb,dc=fr on opc=0x7f3a48001440
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1053 op=1 syncprov_qresp: set up a
new syncres mode=2 csn=
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291397 RESULT tag=103 err=0
qtime=0.000017 etime=0.003762 text=
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291398 SRCH
base="dc=ipb,dc=fr" scope=2 deref=0
filter="(entryUUID=29a4991c-9dda-103b-98c2-c3fe49d4fff9)"
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291398 SRCH attr=* +
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291398 SEARCH RESULT
tag=101 err=0 qtime=0.000028 etime=0.000285 nentries=1 text=
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291399 MOD
dn="uid=pbouchevrea,ou=people,dc=ipb,dc=fr"
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291399 MOD attr=ipbDateFin
entryCSN modifiersName modifyTimestamp
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291399 syncprov_matchops:
recording uuid for dn=uid=pbouchevrea,ou=people,dc=ipb,dc=fr on
opc=0x7f3a48001630
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291399 syncprov_findbase:
searching
Nov 25 14:34:32 ldap2021 slapd[67824]: slap_queue_csn: queueing 0x7f3a438bc700
20211125133351.654596Z#000000#00a#000000
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1053 op=1 syncprov_qresp: set up a
new syncres mode=2 csn=20211125133351.654596Z#000000#00a#000000
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291399 RESULT tag=103 err=0
qtime=0.000025 etime=0.022224 text=
Nov 25 14:34:32 ldap2021 slapd[67824]: slap_graduate_commit_csn: removing
0x7f3a438bc700 20211125133351.654596Z#000000#00a#000000
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291400 MOD
dn="dc=ipb,dc=fr"
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291400 MOD attr=contextCSN
Nov 25 14:34:32 ldap2021 slapd[67824]: conn=1000 op=291400 syncprov_matchops:
recording uuid for dn=dc=ipb,dc=fr on opc=0x7f3a50003440
Nov 25 14:34:32 ldap2021 kernel: [262778.995540] slapd[68072]: segfault at 0 ip
00007f4ea0d3553e sp 00007f4e9dae9f48 error 4 in
libc-2.31.so[7f4ea0cad000+178000]
Nov 25 14:34:32 ldap2021 kernel: [262778.995584] Code: b6 07 29 c8 c3 0f 1f 80
00 00 00 00 f3 0f 1e fa 89 f8 31 d2 66 0f ef ff 09 f0 25 ff 0f 00 00 3d c0 0f
00 00 0f 8f 74 02 00 00 <f3> 0f 6f 0f f3 0f 6f 06 66 0f 74 c1\
66 0f da c1 66 0f ef c9 66 0f
Nov 25 14:34:36 ldap2021 slapd[70083]: * Stopping OpenLDAP slapd
--
You are receiving this mail because:
You are on the CC list for the issue.