openldap-bugs November 2021

openldap-bugs@openldap.org

1 participants
107 discussions

[Issue 9729] New: Allow setting multiprovider before adding syncrepl stanzas
by openldap-its＠openldap.org 12 Jan '22

12 Jan '22

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 3

[Issue 9739] New: Undefined reference to ber_sockbuf_io_udp in 2.6.0
by openldap-its＠openldap.org 15 Dec '21

15 Dec '21

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.

1 7

[Issue 9493] New: slapo-accesslog handling of deletion of multi-valued configuration attributes removes wrong value from list
by openldap-its＠openldap.org 14 Dec '21

14 Dec '21

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 21

[Issue 9282] New: Syncrepl re-creates deleted entry
by openldap-its＠openldap.org 13 Dec '21

13 Dec '21

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 22

[Issue 9757] New: The private key of the ldap certificate
by openldap-its＠openldap.org 02 Dec '21

02 Dec '21

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.

1 2

[Issue 9754] New: segfault after adding olcAccess
by openldap-its＠openldap.org 02 Dec '21

02 Dec '21

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.

1 4

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 29 Nov '21

29 Nov '21

https://bugs.openldap.org/show_bug.cgi?id=6467 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9756 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9755] New: gitlab emits “time="2021-11-27T09:23:59Z" level=info msg="SSL_CERT_DIR is configured" ssl_cert_dir=/opt/gitlab/embedded/ssl/certs/”
by openldap-its＠openldap.org 28 Nov '21

28 Nov '21

https://bugs.openldap.org/show_bug.cgi?id=9755 Issue ID: 9755 Summary: gitlab emits “time="2021-11-27T09:23:59Z" level=info msg="SSL_CERT_DIR is configured" ssl_cert_dir=/opt/gitlab/embedded/ssl/certs/” Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- In my .git/config I have: [remote "gl"] url = git@git.openldap.org:dpa-openldap/openldap.git fetch = +refs/heads/*:refs/remotes/gl/* Calling `git fetch gl` prints: time="2021-11-27T09:23:59Z" level=info msg="SSL_CERT_DIR is configured" ssl_cert_dir=/opt/gitlab/embedded/ssl/certs/ Since I see this message nowhere else, I assume the message is sent by the git server. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9356] New: Add list of peerSIDs to consumer cookie to reduce cross traffic
by openldap-its＠openldap.org 16 Nov '21

16 Nov '21

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 9

[Issue 9746] New: Local Logging - Hostname and PID formatting
by openldap-its＠openldap.org 15 Nov '21

15 Nov '21

https://bugs.openldap.org/show_bug.cgi?id=9746 Issue ID: 9746 Summary: Local Logging - Hostname and PID formatting Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gnoe(a)symas.com Target Milestone: --- With the new local logging feature in 2.6+, each log line displays a pointer (ex: "0x7fa63e866880") instead of the hostname and slapd PID. These fields in the log lines should be in syslog format. * Related to ITS #9745 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2021