openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#5308) test034-translucent crashes with back-ldif
by h.b.furuseth＠usit.uio.no 15 Jan '08

15 Jan '08

ando(a)sys-net.it writes: > It is now fixed in HEAD; please test. Please, also check and test for > any side-effect introduced by the fix, as it impacts all calls to > str2entry (many, I believe). Tested, works fine so far. Haven't looked much for those side effects though. Would need to dig in the code and then construct test cases for it, I guess. -- Hallvard

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by hyc＠symas.com 15 Jan '08

15 Jan '08

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by ando＠sys-net.it 15 Jan '08

15 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> I understand that unfortunately in slapadd this would require either >> to keep track of inserted DNs, or to issue quite a few be_entry_get(), >> possibly resulting in a sensible penalization. Perhaps it could be an >> option, relying on the fact that slapadd is basically intended to >> operate on "well-behaved" data? > > It had better, since slapadd accepts entries out of order. (It returns > failure at the end if some child has not received a parent.) This could be treated specially by performing renames as soon as info becomes available. This pushes more and more towards making this either an option or a no-go for slapadd (i.e. rely on LDIF massaging to have things nice). Note that having data not compliant with the requirement of this ITS would by no means be a violation of LDAP nor cause any operational issue to slapd. It would just be a matter of having more well-behaved data if this does not impact too much operations (and it shouldn't for run-time adds, since we already lookup the parent when adding an entry). 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

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by h.b.furuseth＠usit.uio.no 15 Jan '08

15 Jan '08

ando(a)sys-net.it writes: > I understand that unfortunately in slapadd this would require either > to keep track of inserted DNs, or to issue quite a few be_entry_get(), > possibly resulting in a sensible penalization. Perhaps it could be an > option, relying on the fact that slapadd is basically intended to > operate on "well-behaved" data? It had better, since slapadd accepts entries out of order. (It returns failure at the end if some child has not received a parent.) -- Hallvard

1 0

Re: (ITS#5327) slapo-constraint seg faults on regex
by ando＠sys-net.it 15 Jan '08

15 Jan '08

michael(a)stroeder.com wrote: > Guess it's not that helpful: No problem, easy to reproduce (as much as easy to fix :) 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

Re: (ITS#5327) slapo-constraint seg faults on regex
by michael＠stroeder.com 15 Jan '08

15 Jan '08

Guess it's not that helpful: (gdb) bt full #0 0x0815903b in ldap_pvt_sasl_mutex_dispose () No symbol table info available. #1 0x0000002c in ?? () No symbol table info available. #2 0x00000000 in ?? () No symbol table info available. (gdb)

1 0

(ITS#5327) slapo-constraint seg faults on regex
by michael＠stroeder.com 15 Jan '08

15 Jan '08

Full_Name: Michael Ströder Version: HEAD OS: OpenSUSE Linux 10.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.61.186) slapo-constraint seg faults if slapd.conf contains this line: constraint_attribute gender regex ^[0129]?$ The very same config works with RE24 just fine.

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by ando＠sys-net.it 15 Jan '08

15 Jan '08

ando(a)sys-net.it wrote: > I think it is reasonable to reconstruct an entry's DN by using the parent's DN > and the entry's RDN. The rationale consists in ensuring the tree naming is as > uniform as possible. I understand that unfortunately in slapadd this would require either to keep track of inserted DNs, or to issue quite a few be_entry_get(), possibly resulting in a sensible penalization. Perhaps it could be an option, relying on the fact that slapadd is basically intended to operate on "well-behaved" data? 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

Re: (ITS#5325) Build error: __lock_getlocker undefined symbol
by ando＠sys-net.it 14 Jan '08

14 Jan '08

[Please CC messages to the ITS] Tim Bishop wrote: > On Sat, Jan 12, 2008 at 10:07:57AM +0100, Pierangelo Masarati wrote: >> tim(a)bishnet.net wrote: >> >>> For reference, it's because my libdb is built using --with-uniquename. >>> This means the function name is actually __lock_getlocker_4006. >>> >>> I didn't see this in the documentation. OpenLDAP should either correctly >>> handle this case, or document that it's not supported. >> I think using that option is a Bad Idea (TM); it is the Wrong Solution >> to the problem of having multiple coexisting versions of a library. In >> any case, adding support for that feature would be problematic and >> definitely prone to user (and developer) errors, since the value used to >> make names unique is not exposed in any header file, so it would have to >> be manually defined. There are tons of (sysadmin side) ways to make >> sure the right library is loaded, so I vote against supporting this >> feature. Of course, I'm fine about documenting that --with-uniquename >> is not supported. > > I notice lots of other functions have a mapping in the bdb header file > so you don't need to know the unique value. Is this issue occuring > because the __lock_getlocker function is not meant to be called by > external applications? The mapping depends on the version of Berkeley, so mapping names would require to know what the mapping is; but as far as I can see, it does not provide any means to expose it. Other mappings are basically needed to work around uneven cross-version naming issues in Berkeley, or for OpenLDAP internal purposes, like separating back-bdb and back-hdb names. As Hallvard pointed out, probably that function was not meant to be exposed, since it's not declared in Berkeley's headers, but unfortunately OpenLDAP code seems to need it. Of course, you can still manually CPPFLAGS=-D__lock_getlocker=__lock_getlocker_4006 to workaround your issue. 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#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by ando＠sys-net.it 14 Jan '08

14 Jan '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I think it is reasonable to reconstruct an entry's DN by using the parent's DN and the entry's RDN. The rationale consists in ensuring the tree naming is as uniform as possible. p.

1 0

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