openldap-bugs January 2008

openldap-bugs@openldap.org

36 participants
144 discussions

Re: (ITS#5342) DN and naming attribute mismatch
by hyc＠symas.com 29 Jan '08

29 Jan '08

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.40 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > $ ldapsearch -LLL '(cn=172.23.58.210)' > dn:: Y249MbcyLjIzLjU4LjIxMCxjbj1DbGllbnRzLGNuPVJlc05ldCBTZXJ2aWNlIENvbmZpZyxvd > T1Ib3N0IENvbmZpZyxvPVJ1dGdlcnMgQ0NGLGM9VVM= > objectClass: top > objectClass: dhcpHost > cn: 172.23.58.210 > dhcpStatements: fixed-address 172.23.58.210 > dhcpHWAddress: ethernet 00:17:3f:bf:c2:04 > > > Is it just me, or does my cn attribute not match the cn in the dn? Uhhh...now > what? > (and no, I wasn't using an editor on the bdb files, or whatever other conspiracy > theory is out there.) Also, if it helps, you can see on openldap-software my > other misadventures with 2.3.40...this is just one that's really easy to prove. You didn't mention what backend you're using. I'd examine the dn2id.bdb file (use db_dump -p) and see if this DN is corrupted there. Also, was this entry created using 2.3.40, or using an earlier version? Interesting that the byte differs from the expected value by a single bit (it has its high bit set). Personally I suspect the hardware is flaking out. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5342) DN and naming attribute mismatch
by richton＠nbcs.rutgers.edu 29 Jan '08

29 Jan '08

> does this help? the "7" in 172 is something else (octal 267, I believe). Precisely. How did that get in my database? It MUST match the dn per spec, right? And it doesn't. (The character almost certainly should be '7.' If I go back in my logs far enough, I'll bet I can even find an ADD log showing it as such...)

1 0

Re: (ITS#5342) DN and naming attribute mismatch
by ando＠sys-net.it 29 Jan '08

29 Jan '08

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.40 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > $ ldapsearch -LLL '(cn=172.23.58.210)' > dn:: Y249MbcyLjIzLjU4LjIxMCxjbj1DbGllbnRzLGNuPVJlc05ldCBTZXJ2aWNlIENvbmZpZyxvd > T1Ib3N0IENvbmZpZyxvPVJ1dGdlcnMgQ0NGLGM9VVM= > objectClass: top > objectClass: dhcpHost > cn: 172.23.58.210 > dhcpStatements: fixed-address 172.23.58.210 > dhcpHWAddress: ethernet 00:17:3f:bf:c2:04 > > > Is it just me, or does my cn attribute not match the cn in the dn? Uhhh...now > what? > (and no, I wasn't using an editor on the bdb files, or whatever other conspiracy > theory is out there.) Also, if it helps, you can see on openldap-software my > other misadventures with 2.3.40...this is just one that's really easy to prove. bash-3.00$ echo -n "Y249MbcyLjIzLjU4LjIxMCxjbj1DbGllbnRzLGNuPVJlc05ldCBTZXJ2aWNlIENvbmZpZyxvdT1Ib3N0IENvbmZpZyxvPVJ1dGdlcnMgQ0NGLGM9VVM=" | base64 -d | od -c 0000000 c n = 1 267 2 . 2 3 . 5 8 . 2 1 0 0000020 , c n = C l i e n t s , c n = R 0000040 e s N e t S e r v i c e C o 0000060 n f i g , o u = H o s t C o n 0000100 f i g , o = R u t g e r s C C 0000120 F , c = U S 0000126 does this help? the "7" in 172 is something else (octal 267, I believe). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5342) DN and naming attribute mismatch
by richton＠nbcs.rutgers.edu 29 Jan '08

29 Jan '08

Full_Name: Aaron Richton Version: 2.3.40 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) $ ldapsearch -LLL '(cn=172.23.58.210)' dn:: Y249MbcyLjIzLjU4LjIxMCxjbj1DbGllbnRzLGNuPVJlc05ldCBTZXJ2aWNlIENvbmZpZyxvd T1Ib3N0IENvbmZpZyxvPVJ1dGdlcnMgQ0NGLGM9VVM= objectClass: top objectClass: dhcpHost cn: 172.23.58.210 dhcpStatements: fixed-address 172.23.58.210 dhcpHWAddress: ethernet 00:17:3f:bf:c2:04 Is it just me, or does my cn attribute not match the cn in the dn? Uhhh...now what? (and no, I wasn't using an editor on the bdb files, or whatever other conspiracy theory is out there.) Also, if it helps, you can see on openldap-software my other misadventures with 2.3.40...this is just one that's really easy to prove.

1 0

Re: (ITS#5341) Invalid TLSCipherSuite causes hang
by vorlon＠debian.org 29 Jan '08

29 Jan '08

On Tue, Jan 29, 2008 at 11:31:43AM -0800, Quanah Gibson-Mount wrote: > --On Tuesday, January 29, 2008 11:09 AM -0800 Steve Langasek > <vorlon(a)debian.org> wrote: > > Anyway, the documented syntax for TLSCipherSuite is "$cipher1:$cipher2", > > not "$cipher1 $cipher2"; but setting such values gives me a hang on > > startup (which should be investigated). > Filed upstream: > <http://www.OpenLDAP.org/its/index.cgi?findid=5341> Sorry, the description of this ITS is inverted. It's *valid* ciphersuite values (i.e., "cipher1:cipher2") that cause the hang; invalid space-separated values are merely truncated after the first cipher in the list, which doesn't cause a hang, it just prevents the cipher list from being useful. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org

1 0

(ITS#5341) Invalid TLSCipherSuite causes hang
by quanah＠OpenLDAP.org 29 Jan '08

29 Jan '08

Full_Name: Quanah Gibson-Mount Version: 2.4.7 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) Setting TLSCipherSuite to "cipher1 cipher2" rather than "cipher1:cipher2" causes slapd to hang on startup (at least when using GnuTLS). It appears to be hanging indefinitely in ldap_pvt_tls_set_option() --Quanah

1 0

Re: (ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 29 Jan '08

29 Jan '08

Other bugs: * be->be_chk_referrals: back-bdb and back-ldif can send errors from be->be_chk_referrals. As far as I can tell that is wrong: It should return an LDAP result code, but only send it if it is LDAP_REFERRAL. backend_check_referrals() will send other errors, and success means it'll proceed to the be->be_<operation>() call. * be->be_fetch() (bi->bi_entry_get_rw()): The LDAP result code matters to at least aci.c:dynacl_aci_mask() and frontendDB->be_compare() (compare.c:fe_op_compare()). These use it via backend_attribute(), using frontendDB->be_attribute() (fe_acl_attribute()), using backend.c:be_entry_get_rw(). It can return just a boolean in back-null, back-ldif, back-relay and back-config. back-null usually pretends the entries are present, so maybe it should do "return oc ? LDAP_NO_SUCH_ATTRIBUTE : LDAP_BUSY;". * Internal slapd errors. back-ldap:ldap_back_entry_get() can return LDAP_NO_MEMORY. Maybe that's OK and instead send_ldap_response() should change negative negative result codes to LDAP_OTHER? -- Hallvard

1 0

(ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 29 Jan '08

29 Jan '08

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard overlays/dynlist.c lines 371-376 sets REP_ENTRY_MUSTBEFREED in rs->sr_flags without duplicating the entry, if REP_ENTRY_MODIFIABLE was set. Thus the entry gets freed twice. Breaks test044-dynlist with back-ldif. This code snippet fixes it for test044, but it may be the wrong fix: e = rs->sr_entry; e_flags = rs->sr_flags; if ( !( e_flags & REP_ENTRY_MODIFIABLE ) ) { e = entry_dup( e ); if ( e_flags & REP_ENTRY_MUSTBEFREED ) entry_free( rs->sr_entry ); e_flags |= REP_ENTRY_MODIFIABLE | REP_ENTRY_MUSTBEFREED; } First, can something have references into the old sr_entry at this point? Second, there is also a REP_ENTRY_MUSTRELEASE flag which means to call be_entry_release_rw(), maybe that must be handled. Also overlays collect, pcache & valsort ignore REP_ENTRY_MUSTRELEASE. A common function to handle this might be useful - pass it a SlapResponse, BackendDB and flags to set and flags to unset, and let it free, release or dup what is needed.

1 0

Re: (ITS#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 29 Jan '08

29 Jan '08

I wrote: > !be_issuffix( op->o_bd,&op->o_req_ndn ) > which looks to me like a test for whether this function is _not_ to be > called for this database. No, that's a test if the DN is the exact suffix, not if it has the suffix. Anyway, for what it's worth "make test" succeeds with an "assert(0)" after the !be_issuffix test. -- Hallvard

1 0

ldap_result error
by Fabio Ubaldi 29 Jan '08

29 Jan '08

Hi all, I have two processes running on the same PC that receive data from an LDAP server. Each process opens a connection with a different "slapd" server (i.e each server runs on a different PC) and launches "search" requests at a fixed rate (about 100 searches/s). Each process creates a thread that polls the server responses using the API "ldap_result" the used macro are LDAP_RES_ANY and LDAP_MSG_ONE. When the two processes send the requestes one of the two "ldap_result" return with error (-1) and the error is "Can't contact the LDAP server". I tried to launch one processes and it works fine (the maximum measured rate is 800 searches/s). Also I launch the two processes alternating the search requestes and it works fine. It seems that the error happens only if the two process runs simultaneously (I use a dual core PC). Thinking of a race condition error , I used the libldap_r library to build process, but the error still remains. The openldap version is 2.3.27 both for slapd servers and the libraries. Have anyone encountered a similar error ? Thanks in advance for the reply

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2008