Re: (ITS#5342) DN and naming attribute mismatch
by hyc＠symas.com
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/
15 years, 10 months
Re: (ITS#5342) DN and naming attribute mismatch
by richton＠nbcs.rutgers.edu
> 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...)
15 years, 10 months
Re: (ITS#5342) DN and naming attribute mismatch
by ando＠sys-net.it
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
---------------------------------------
15 years, 10 months
(ITS#5342) DN and naming attribute mismatch
by richton＠nbcs.rutgers.edu
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.
15 years, 10 months
Re: (ITS#5341) Invalid TLSCipherSuite causes hang
by vorlon＠debian.org
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
15 years, 10 months
(ITS#5341) Invalid TLSCipherSuite causes hang
by quanah＠OpenLDAP.org
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
15 years, 10 months
Re: (ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no
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
15 years, 10 months
(ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no
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.
15 years, 10 months
Re: (ITS#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no
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
15 years, 10 months
ldap_result error
by Fabio Ubaldi
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
15 years, 10 months
