openldap-bugs November 2021

openldap-bugs@openldap.org

1 participants
118 discussions

[Issue 9538] New: Accesslog entryCSN ordering is not always monotonous
by openldap-its＠openldap.org 12 Jan '22

12 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9538 Issue ID: 9538 Summary: Accesslog entryCSN ordering is not always monotonous Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- For delta-sync replication, we rely on CSN order being preserved at all times. When logops includes anything more than "writes", we don't use li_op_rmutex to maintain serialisation. A concurrent write and another operation (like bind) can have the write have its csn assigned before the bind. But before the write finishes on the main DB and is logged, the bind has already hit accesslog. This entry out of order doesn't match the usual filter, so non-persist sessions will not notice, however running persist sessions could get a new cookie sent, depending on how things are ordered when they hit syncprov. A sample: ---- 8< ---- Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 ADD dn="uid=dm01-R1H2-41660,ou=People,dc=example,dc=com" Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 syncprov_matchops: recording uuid for dn=reqStart=20210426195604.000350Z,cn=accesslog on opc=0x7d3d2800dc50 Apr 26 19:56:04 localhost slapd[43930]: slap_get_csn: conn=1003 op=42 generated new csn=20210426195604.556053Z#000000#002#000000 manage=1 Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x7d3d38148f60 20210426195604.556053Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 BIND dn="dc=example,dc=com" method=128 Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 BIND dn="dc=example,dc=com" mech=SIMPLE bind_ssf=0 ssf=256 Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 RESULT tag=105 err=0 qtime=0.005874 etime=0.015182 text= Apr 26 19:56:04 localhost slapd[43930]: slap_get_csn: conn=1005 op=1 generated new csn=20210426195604.558683Z#000000#002#000000 manage=1 Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x561f09113f80 20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 syncprov_matchops: recording uuid for dn=reqStart=20210426195604.000364Z,cn=accesslog on opc=0x561f0900fcf0 Apr 26 19:56:04 localhost slapd[43930]: conn=1002 op=2 syncprov_qresp: set up a new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1001 op=2 syncprov_qresp: set up a new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1000 op=2 syncprov_qresp: set up a new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing 0x561f09113f80 20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 RESULT tag=97 err=0 qtime=0.000020 etime=0.004297 text= Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x7d3d38148250 20210426195604.556053Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing 0x7d3d38148250 20210426195604.556053Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing 0x7d3d38148f60 20210426195604.556053Z#000000#002#000000 ---- 8< ---- Example entries in the order slapcat sees them: ---- 8< ---- dn: reqStart=20210426195604.000364Z,cn=accesslog objectClass: auditBind reqStart: 20210426195604.000364Z reqEnd: 20210426195604.000365Z reqType: bind entryCSN: 20210426195604.558683Z#000000#002#000000 dn: reqStart=20210426195604.000351Z,cn=accesslog objectClass: auditAdd reqStart: 20210426195604.000351Z reqEnd: 20210426195604.000366Z reqType: add entryCSN: 20210426195604.556053Z#000000#002#000000 ---- 8< ---- -- You are receiving this mail because: You are on the CC list for the issue.

1 20

[Issue 9556] New: slapd-config should return invalidAttributeSyntax if parsing schema description fails
by openldap-its＠openldap.org 12 Jan '22

12 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9556 Issue ID: 9556 Summary: slapd-config should return invalidAttributeSyntax if parsing schema description fails Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I'm currently testing error handling and interacting with LDAP clients (e.g. my web2ldap). Sending an invalid attribute type description results in an error (as expected) returned by slapd-config: RESULT tag=103 err=80 qtime=0.000032 etime=0.001271 text=olcAttributeTypes: Unexpected token before SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) But result code other(80) seems not very useful. It's too unspecific to decide on specific error handling. It would be much more useful if slapd-config returns invalidAttributeSyntax(21) in this case. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9576] New: Add ConfigTable link into ConfigArgs
by openldap-its＠openldap.org 12 Jan '22

12 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9576 Issue ID: 9576 Summary: Add ConfigTable link into ConfigArgs Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Would make it possible to examine defaults if necessary. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[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 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2021