openldap-bugs September 2021

openldap-bugs@openldap.org

1 participants
193 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 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 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 9492] New: Add local logging capa
by openldap-its＠openldap.org 26 Oct '21

26 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9492 Issue ID: 9492 Summary: Add local logging capa Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: mhardin(a)symas.com Target Milestone: --- Enhancement request: Add capability to slapd to log to a local file with log rotation features. Log format should not change from syslog-generated log style. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9641] New: accesslog when logging failed operations interferes with deltasync
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9641 Issue ID: 9641 Summary: accesslog when logging failed operations interferes with deltasync Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Take delta-MPR setup and accesslog configured with logsuccess off. We encounter a conflicting write (one that fails to apply in the DB) and fall back to plain syncrepl. Since we are configured to log that write, syncprov sees it (it is a failure, so doesn't match filter, which should contain reqResult=0) and sends a LDAP_SYNC_NEW_COOKIE with that CSN to our delta-consumers. While we apply this write locally in the fallback session, the consumers will skip what they see as a duplicate and lose the change. My understanding is that for failed operations, we should ignore the CSN we received with the operation and instead set up a new one (with our own sid). -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9700] New: Need to determine new library ABI versioning starting point
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9700 Issue ID: 9700 Summary: Need to determine new library ABI versioning starting point Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- With the change in how OpenLDAP client libraries are versioned vs prior releases, we need to determine a useful starting point for the current ABI prior to release. Since current libldap is versioned as libldap.so.2, we may want to start with ol_api_current=2 -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9666] New: 2.5 to 2.6 upgrade documentation
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9666 Issue ID: 9666 Summary: 2.5 to 2.6 upgrade documentation Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Need to document any upgrade issues for going from 2.5 to 2.6 -- You are receiving this mail because: You are on the CC list for the issue.

1 11

← Newer
1
...
4
5
6
7
8
9
10
...
20
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2021