openldap-bugs March 2021

openldap-bugs@openldap.org

1 participants
318 discussions

[Issue 8545] Undesired timeout when polling for results
by openldap-its＠openldap.org 21 Mar '21

21 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=8545 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- (In reply to shalopo(a)gmail.com from comment #0) > Full_Name: Shahar Lupu > Version: 2.4.44 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.218.29.26) > > > When calling ldap_result with a timeout={0,0} (polling), it returns > LDAP_TIMEOUT > even though there are available messages in the socket. > This occurs when calling ldap_results with all=true and a multi-message > response > has arrived. In this case, if the client has already received on the socket > every message for the response, it is desirable that all the messages are > collected within this ldap_result call. Instead of only polling for the > specified timeout, ldap_result applies the timeout (zero when polling) on the > wait4msg loop. Consequently, ldap_result returns LDAP_TIMEOUT after the first > message if the response is composed of more than one message. > While it may be a good idea to apply a timeout for the wai4msg loop (rather > than > only the polling on the socket), it is undesirable in some cases and should > at > least be configurable. Or perhaps timeout=polling should never be applied on > the > wait4msg loop. None of this will make any difference. In try_read1msg, there is a check to see if the socket is still readable at the end, in which case it will loop back and read the next message. As such, when it returns to wait4msg, all readable messages have already been processed. So even if it returns LDAP_TIMEOUT, it returns all available messages. If it only returns one message, that means no others were available. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8458] syncrepl ppolicy with LDIF backend fails
by openldap-its＠openldap.org 21 Mar '21

21 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=8458 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- The bug report makes no sense. (In reply to mozo(a)mozo.jp from comment #0) > As LDIF backend tries to store the values for the attributes in "prettified" > form and the value is transferred verbatim in wire, replication of > pwdAttribute > (1.3.6.1.4.1.42.2.27.8.1.1) ends up with the following error: > > > syncrepl_message_to_entry: rid=001 mo cheheck (pwdAttribute: value #0 invalid > per syntax) > > The validation causing the error itself is done in the following part in > servers/slapd/modify.c: > > /* > * check that each value is valid per syntax > * and pretty if appropriate > */ > for ( nvals = 0; !BER_BVISNULL( &ml->sml_values[nvals] ); > nvals++ ) > { > struct berval pval; > > if ( pretty ) { > rc = ordered_value_pretty( ad, > &ml->sml_values[nvals], &pval, ctx ); > } else { > rc = ordered_value_validate( ad, > &ml->sml_values[nvals], ml->sml_op ); > } > > if( rc != 0 ) { > snprintf( textbuf, textlen, > "%s: value #%ld invalid per syntax", > ml->sml_type.bv_val, (long) nvals ); > *text = textbuf; > return LDAP_INVALID_SYNTAX; > } > > if( pretty ) { > ber_memfree_x( ml->sml_values[nvals].bv_val, ctx ); > ml->sml_values[nvals] = pval; > } > } > > where pwdAttribute has the corresponding prettifier assigned to its schema > (servers/slapd/overlays/ppolicy.c), which eventually is fed with the value in > prettified form that will effectively make slap_bv2ad() in attrPretty() fail. attrPretty will only fail if the item it's passed has not been defined in the schema. > > { > Syntax *syn; > MatchingRule *mr; > > syn = ch_malloc( sizeof( Syntax )); > *syn = *ad_pwdAttribute->ad_type->sat_syntax; > syn->ssyn_pretty = attrPretty; > ad_pwdAttribute->ad_type->sat_syntax = syn; > > mr = ch_malloc( sizeof( MatchingRule )); > *mr = *ad_pwdAttribute->ad_type->sat_equality; > mr->smr_normalize = attrNormalize; > ad_pwdAttribute->ad_type->sat_equality = mr; > } > > The replication works fine for other such attributes that have the same > syntax > (OID, 1.3.6.1.4.1.1466.115.121.1.38) like objectClass because those > attributes > are accompanied by the validators as well as prettifiers which validate the > value both in prettified and OID form. For instance, objectClass has the > corresponding validator oialalidate() besides the prettifier > objectClassPretty(). The code you quoted from slapd/modify.c clearly shows that if a prettifier is defined, then the validator is ignored, therefore it is irrelevant. So again, this only fails if the schema element in question is not defined, which means you have a configuration error. Closing this ITS. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7295] Problem with TLS: threads and OpenSSL
by openldap-its＠openldap.org 21 Mar '21

21 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=7295 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|UNCONFIRMED |RESOLVED --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- Fixed in master -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8246] defining multiple frontend DBs should probably not be allowed
by openldap-its＠openldap.org 21 Mar '21

21 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=8246 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |TEST --- Comment #1 from Howard Chu <hyc(a)openldap.org> --- fixed in master -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9016] cn=config should fail on EMIT if target directory not empty
by openldap-its＠openldap.org 18 Mar '21

18 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9016 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Keywords|OL_2_5_REQ, reviewed | --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 3c12993f by Ondřej Kuzník at 2021-03-18T21:07:43+00:00 ITS#9016 Check confdir is empty before generating from scratch • 1d5e16fa by Ondřej Kuzník at 2021-03-18T21:07:43+00:00 ITS#9438 Do not regenerate config on startup -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6830] slapo-ppolicy.5 has incorrect schema fragments
by openldap-its＠openldap.org 18 Mar '21

18 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=6830 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.4 |2.5.3 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6830] slapo-ppolicy.5 has incorrect schema fragments
by openldap-its＠openldap.org 18 Mar '21

18 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=6830 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • eafcc405 by Ondřej Kuzník at 2021-03-18T17:32:30+00:00 ITS#6830 Enable NO-USER-MODIFICATION on ppolicy attributes -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9051] slapo-accesslog fails to log compare, search
by openldap-its＠openldap.org 18 Mar '21

18 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9051 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 6809a942 by Quanah Gibson-Mount at 2021-03-18T16:36:56+00:00 ITS#9051 Regression test • 152c12d4 by Ondřej Kuzník at 2021-03-18T16:36:56+00:00 ITS#9051 Do not remove callback on intermediate responses • 4d6b0180 by Ondřej Kuzník at 2021-03-18T16:36:56+00:00 ITS#9051 Check for more success result codes -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9505] New: Should be admin guide section on logging detail
by openldap-its＠openldap.org 17 Mar '21

17 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9505 Issue ID: 9505 Summary: Should be admin guide section on logging detail Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently we do not document information about the log levels, particularly stats. For example, we don't document anywhere outside the slap.h header what time units etime and qtime use (microseconds). This would be helpful, since other directory servers use (and DOCUMENT) milliseconds. Overall it would likely be helpful to end users so they understand more about what the information stats logging is providing. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9449] New: When the "lockdetect" is setted in slapd.conf, the db deadlock detected policy is setted incorrected
by openldap-its＠openldap.org 16 Mar '21

16 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9449 Issue ID: 9449 Summary: When the "lockdetect" is setted in slapd.conf, the db deadlock detected policy is setted incorrected Product: OpenLDAP Version: 2.4.57 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: li(a)lihaitao.cn Target Milestone: --- I have the "lockdetect random" setted in slapd.conf,the expected deadlock detected policy is "DB_LOCK_RANDOM" but I got the valude "DB_LOCK_EXPIRE". After many search of the source file, the lockdetect parse source is found on openldap-2.4.57\servers\slapd\back-bdb\config.c :Line 894-903 --------------------- case BDB_LOCKD: rc = verb_to_mask( c->argv[1], bdb_lockd ); if ( BER_BVISNULL(&bdb_lockd[rc].word) ) { fprintf( stderr, "%s: " "bad policy (%s) in \"lockDetect <policy>\" line\n", c->log, c->argv[1] ); return 1; } bdb->bi_lock_detect = (u_int32_t)rc; break; --------------------- After analyse the verb_to_mask's return value, the "rc" is the index of the bdb_lockd's setting items. So it can't be passwd to bi_lock_detect. The right value is The "bdb_lockd[rc].mask". I think it is a bug, my recommendation fix is like the next. bdb->bi_lock_detect = (u_int32_t)rc; -> bdb->bi_lock_detect = bdb_lockd[rc].mask; -- You are receiving this mail because: You are on the CC list for the issue.

1 5

← Newer
1
...
14
15
16
17
18
19
20
...
32
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2021