(ITS#7817) Wrong if condition for string length
by fschmaus＠gmail.com
--bcaec53969d8ce043204f45455b2
Content-Type: text/plain; charset=ISO-8859-1
Of course the if condition for string length should be '>0' not '>=0'.
--bcaec53969d8ce043204f45455b2
Content-Type: text/html; charset=ISO-8859-1
<div dir="ltr">Of course the if condition for string length should be '>0' not '>=0'.</div>
--bcaec53969d8ce043204f45455b2--
9 years, 6 months
(ITS#7818) err=52 - unsuccessful bind due to lack of unbind
by maciej.uhlig＠us.edu.pl
Full_Name: Maciej Uhlig
Version: 2.4.39
OS: CentOS release 6.5 (Final)
URL: http://usnet.us.edu.pl/files/openldap/err52.txt
Submission from: (NULL) (155.158.97.72)
There are two OpenDJ servers and one OpenLDAP server. OpenLDAP server acts as a
proxy to OpenDJ servers. OpenLDAP server is used by Dovecot mailbox server (here
LDAP client) for user authentication.
/---OpenDJ1
Dovecot---OpenLDAP
\---OpenDJ2
OpenLDAP server runs 2.4.39 software. The problem is observed during OpenLDAP
and OpenDJ servers interaction. Users can't send their mail. Dovecot server logs
"ldap_bind() failed: Server is unavailable". OpenLDAP server logs "err=52".
Restart of OpenLDAP server is required to resume normal operation.
Analysis of OpenDJ log shows:
- conn=40822 (correct) takes not more than one second
- conn=40823 (incorrect) takes more than eleven minutes (it persists until
OpenLDAP server is stopped)
Analysis of OpenLDAP log shows:
- op=29970 (conn=40822 in OpenDJ server) ends with err=0
- op=29972 (conn=40823 in OpenDJ server) ends with err=0
- op=29976 (not seen in OpenDJ server) ends with err=52
- similarly op=29979 and all subsequent end with err=52
Looks like OpenLDAP server doesn't unbind (eleven minutes above) from OpenDJ
server. Instead it tries to make next bind which is unsuccesful (err=52).
9 years, 6 months
(ITS#7817) jldap DigesetMD5SaslClient is using authzid for username when it should use authcid
by flo＠geekplace.eu
Full_Name: Florian Schmaus
Version:
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (88.217.98.14)
The openldap-jldap's com.novell.sasl.cient.DigestMD5SaslClient is using
authorization id (authzid) as value for the username. But the relevant RFC2831
states in section 2.1.2 that there is an extra attribute 'authzid' when
assembling the response. The value of username should use m_name (the authcid)
and the response should only add the authzid if it's set (Note that authzid is
*optional*).
--- a/com/novell/sasl/client/DigestMD5SaslClient.java
+++ b/com/novell/sasl/client/DigestMD5SaslClient.java
@@ -661,7 +661,7 @@ public class DigestMD5SaslClient implements SaslClient
true);
digestResponse.append("username=\"");
- digestResponse.append(m_authorizationId);
+ digestResponse.append(m_name);
if (0 != m_realm.length())
{
digestResponse.append("\",realm=\"");
@@ -679,8 +679,12 @@ public class DigestMD5SaslClient implements SaslClient
digestResponse.append(response);
digestResponse.append(",charset=utf-8,nonce=\"");
digestResponse.append(m_dc.getNonce());
+ if (m_authorizationId != null && m_authorizationId.length() >= 0)
+ {
+ digestResponse.append("\",authzid=\"");
+ digestResponse.append(m_authorizationId);
+ }
digestResponse.append("\"");
-
return digestResponse.toString();
}
9 years, 6 months
Re: ITS#7796 "not indexed" log messages
by ck＠cksoft.de
Hi,
On Sun, 9 Mar 2014, michael(a)stroeder.com wrote:
> hyc(a)symas.com wrote:
>> I'd consider instead, resurrecting the LDAP_DEBUG_INDEX debug flag, or putting
>> these in LDAP_DEBUG_FILTER. TRACE is already too verbose.
>
> I'm fine with any solution which avoids that these messages are sent to the
> log in case of "loglevel stats stats2".
I would also welcome a separate loglevel for these daemon messages:
Mar 9 11:00:24 ldap1 slapd[19539]: daemon: read activity on 9
Mar 9 11:00:24 ldap1 slapd[19539]: daemon: select: listen=6 active_threads=0 tvp=zero
Mar 9 11:00:24 ldap1 slapd[19539]: daemon: select: listen=7 active_threads=0 tvp=zero
Mar 9 11:00:24 ldap1 slapd[19539]: daemon: activity on 1 descriptor
Mar 9 11:00:24 ldap1 slapd[19539]: daemon: waked
Mar 9 11:00:24 ldap1 slapd[19539]: daemon: select: listen=6 active_threads=0 tvp=zero
Mar 9 11:00:24 ldap1 slapd[19539]: daemon: select: listen=7 active_threads=0 tvp=zero
They currently seem to be triggered by loglevel conns.
So what about adding loglevel daemon or even conns2 for these.
Greetings
Christian
--
Christian Kratzer CK Software GmbH
Email: ck(a)cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
9 years, 6 months
Re: ITS#7796 "not indexed" log messages
by michael＠stroeder.com
hyc(a)symas.com wrote:
> I'd consider instead, resurrecting the LDAP_DEBUG_INDEX debug flag, or putting
> these in LDAP_DEBUG_FILTER. TRACE is already too verbose.
I'm fine with any solution which avoids that these messages are sent to the
log in case of "loglevel stats stats2".
Ciao, Michael.
9 years, 6 months
Re: (ITS#7816) Bug in LMDB's mdb_cmp_memn[r] functions
by hyc＠symas.com
dror.harari(a)gmail.com wrote:
> Full_Name: Dror Harari
> Version:
> OS: Windows 7 64bit
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (79.181.198.22)
>
>
> The default compare functions start with:
>
> mdb_cmp_memn(const MDB_val *a, const MDB_val *b)
> {
> int diff;
> ssize_t len_diff;
> unsigned int len;
>
> len = a->mv_size;
> len_diff = (ssize_t) a->mv_size - (ssize_t) b->mv_size;
> if (len_diff > 0) {
>
> This code assumes that ssize_t is signed and in all normal platforms it is.
> However, on Windows Visal Studio 2010 (did not check others) it is defined as:
>
> #ifndef _SSIZE_T_DEFINED
> #ifdef _WIN64
> typedef unsigned __int64 ssize_t;
> #else
> typedef _W64 unsigned int ssize_t;
> #endif
> #define _SSIZE_T_DEFINED
> #endif
>
> So it is unsigned and len_diff would never become <0.
If this is true, then you've found a bug in MSVC. The extra S in "SSIZE_T"
means "signed." This is part of the C standard, and even the Microsoft
documentation agrees with the standard (for once).
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.8...
You should file a bug report with Microsoft. Closing this ITS.
>
> There's a workaround to defined a custom compare function but one can rewrite
> the default compare around this bug (that is, avoiding subtraction).
>
> This issue was detected with SET_KEY_RANGE on a key value of 00 00 00 02 where
> the database had keys:
> 00 00 00 01 65
> 00 00 00 02 65
> 00 00 00 03 65
>
> Instead of getting the 00 00 00 02 65, the code returns 00 00 00 03 65
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 6 months
(ITS#7816) Bug in LMDB's mdb_cmp_memn[r] functions
by dror.harari＠gmail.com
Full_Name: Dror Harari
Version:
OS: Windows 7 64bit
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (79.181.198.22)
The default compare functions start with:
mdb_cmp_memn(const MDB_val *a, const MDB_val *b)
{
int diff;
ssize_t len_diff;
unsigned int len;
len = a->mv_size;
len_diff = (ssize_t) a->mv_size - (ssize_t) b->mv_size;
if (len_diff > 0) {
This code assumes that ssize_t is signed and in all normal platforms it is.
However, on Windows Visal Studio 2010 (did not check others) it is defined as:
#ifndef _SSIZE_T_DEFINED
#ifdef _WIN64
typedef unsigned __int64 ssize_t;
#else
typedef _W64 unsigned int ssize_t;
#endif
#define _SSIZE_T_DEFINED
#endif
So it is unsigned and len_diff would never become <0.
There's a workaround to defined a custom compare function but one can rewrite
the default compare around this bug (that is, avoiding subtraction).
This issue was detected with SET_KEY_RANGE on a key value of 00 00 00 02 where
the database had keys:
00 00 00 01 65
00 00 00 02 65
00 00 00 03 65
Instead of getting the 00 00 00 02 65, the code returns 00 00 00 03 65
9 years, 6 months
Re: (ITS#7809) cross-compiling and openldap-thread-check.m4
by h.b.furuseth＠usit.uio.no
On Mon, 2014-03-03 at 02:09 +0000, stenn(a)ntp.org wrote:
> openldap-thread-check.m4 seems to hand-code an equivalent of AC_ARG_WITH()
> processing for the with_yielding_select stuff. This code has at least one typo
> and at least one bug; it does not work in the case where one is
> cross-compiling.
OpenLDAP has no openldap-thread-check.m4. Maybe you're referring
to some other package which checks how OpenLDAP uses threads. It
could be doing something to match how OpenLDAP handles threads.
9 years, 6 months
Re: (ITS#7815) mdb cannot retrieve inserted word
by hyc＠symas.com
clayton.stangeland(a)gmail.com wrote:
> Full_Name: Clayton Stangeland
> Version: gitorious mdb 2014-02-19 e2bdd44624a525
> OS: Fedora 20 64 bit
> URL: http://www.strerror.com/mdb_bug_report/
> Submission from: (NULL) (192.94.73.31)
>
>
> DUPLICATE bug report. New URL: for data file
> http://www.strerror.com/mdb_bug_report/.
> You can use the 3 non tgz files or download the tgz file which includes all of
> them.
Thanks for the report. This is now fixed in mdb.master.
> I have a text file of words (words.txt). Each is 511 or less characters. When
> inserting them into the database there comes a point when I can no longer
> retrieve words that were successfully added with mdb_cursor_put.
>
> It should be put in the libraries/liblmdb directory. The Makefile has an added
> command at the end. So put that, words.txt, and word_test.c in liblmdb directory
> and run 'make words'.
>
> It will build and run a failing test. First it reads each line of words.txt.
> Then it inserts them with their index as the value into mdb. If you change count
> = 29523 on line 145 to be count = 29522 then it works. Inserting the next word
> causes it to fail.
>
> It doesn't fail at the insert but it fails later. When iterating the cursor the
> words are not in order and looking up individually not all words can be
> retrieved.
>
> Also, changing line 151 to set val.mv_data, and val.mv_size to a string version
> of i (the index, using sprintf), it works.
>
> This fails the same way on 64 bit Fedora and 64 bit Windows 7.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 6 months
