openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#4703) mirrormode hole
by hyc＠OpenLDAP.org 06 Oct '06

06 Oct '06

Full_Name: Howard Chu Version: HEAD/re24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.126.120.178) Submitted by: hyc If the current master commits an update but crashes before the change is propagated to the mirror, and then new updates are subsequently committed on the new master, the non-propagated changes will never be picked up, because the new master's context is newer than everything on the crashed master. The hole can be plugged by keeping a per-consumer contextCSN in addition to the overall contextCSN, so that the old state isn't lost. While we're at it, we should add a consumer option for specifying additional locations in which to store contextCSNs. This would e.g. solve ITS#4626 by allowing a consumer in a glued subordinate to keep its parent context up to date.

1 0

Re: authz-regexp matches twice on same dse (ITS#4698)
by ando＠sys-net.it 06 Oct '06

06 Oct '06

> Pierangelo Masarati wrote: > >> I don't see an error in OpenLDAP software here. authz regexp matching >> is >> designed to succeed only if the identity is univoquely resolved to >> exactly one >> DN. I'm afraid but I cannot even imagine how slapd could decide to pick >> one out >> of many DNs when authenticating a user; I guess noone else can. >> >> p. >> > > Matched dn's are unique, as they describing the same Entry: > > dn: uid=works,dc=example,dc=org > objectClass: extensibleObject > uid: works > > dn: cn=worksalso,dc=example,dc=org > objectClass: extensibleObject > cn: worksalso > > dn: uid=fails,dc=example,dc=org > objectClass: extensibleObject > uid: fails > cn: fails > > "(|(cn=works)(uid=works))" and "(|(cn=worksalso)(uid=worksalso))" matching > either attribute, whereas "(|(cn=works)(uid=works))" matches twice, but > describes the same object. > > ldapsearching for "(|(cn=fails)(uid=fails))" will also return only the one > and unique entry "uid=fails,dc=example,dc=org" What authz-regexp does is run an internal search. If the search returns exactly one entry, then there's no way it can be, say, returned twice, otherwise it would also when running aregular search. Moreover, I've recrated you scenario in 2.3.27 and HEAD, and everything seems to work as expected in all cases. I suspect something else is wrong, for example data in your DB is not like it appears. Usually, guessing and expecting is a bad practice when debugging software. Please perform offending operations with full logs on; check that your data is not duplicated (for example, you might not see duplicates because they're hidden by ACLs) and so. Unless you can show a clear malfunction of the software (which I don't see here) I'm inclined towards closing this ITS. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4702) out-of-memory on huge DB ?
by Paolo.Rossi.con＠h3g.it 06 Oct '06

06 Oct '06

Full_Name: Paolo Rossi Version: 2.3.27 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.149.168.114) Hi, during some test on very huge DB, due to see how syncrepl works in this scenario, I've found a strange behavior: Solaris 8 on 2xUSIII+ 4GB RAM openLDAP 2.3.27 BDB 4.2.52.4 backend hdb 1 provider, 1 consumer, 1 consumer with filter. on 1 million dn LDAP whit 2 sub-dn for each dn, all the systems works fine, when I've tried to use a 10m dn with 3 sub-dn (very big ldap, openldap-data dir about 20GB): slapadd with -w on producer. it works. some ldapsearch, it works. stop producer, slapcat the producer to obtain the ldif for consumer preload and... bum after about 150 minutes of slapcat, memory full (look the screenshot of top ) PID |USERNAME | SIZE |RES |TIME | CPU |COMMAND 21495 | ldap |4072M |3591M |150:07 | 21.36% |slapd memory full, then coredump and a console messages: ch_malloc of 16392 bytes failed ch_malloc.c:57: failed assertion `0' the out ldif was about 85% of the full LDAP I've tried again with same results. Then I've tried to syncrepl the entire DB, turning on the empty consumers (crazy idea ;) i know ) but the provider memory allocated, again reached 4GB and... bum core dumped in the slapd.log ch_calloc of 1 elems of 80 bytes failed second try: ch_malloc of 16 bytes failed seems to be a issue like ITS#4010 some ideas? Regards

1 0

Re: (ITS#4701) slapd crash using slapmodrdn
by ando＠sys-net.it 06 Oct '06

06 Oct '06

> slapd crashed with an "assert failure" in lastmod.c line 593 when using > slapmodrn command. Fault is reproducable. Get around is to remove lastmod > overlay from config file. There is no slapmodrdn tool in OpenLDAP suite; I assume you mean ldapmodrdn. In any case, slapo-lastmod(5) is essentially unmaintained and basically useless. I suggest you use slapo-accesslog(5) instead. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4701) slapd crash using slapmodrdn
by andy.n.parker＠unilever.com 06 Oct '06

06 Oct '06

Full_Name: Andrew Neil Parker Version: 2.3.27 OS: RHEL 3.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.60.106.5) slapd crashed with an "assert failure" in lastmod.c line 593 when using slapmodrn command. Fault is reproducable. Get around is to remove lastmod overlay from config file. Trace output using -d 1 is provided on ftp site. 150 Opening BINARY mode data connection for 'andy.n.parker-061006.ext'. 226 Transfer complete (unique file name:andy.n.parker-061006.ext). 3036 bytes sent in 0.00025 seconds (1.2e+04 Kbytes/s)

1 0

(ITS#4700) slapd crash using slapmodrdn
by andy.n.parker＠unilever.com 06 Oct '06

06 Oct '06

1 0

Re: (ITS#4699) snacc-2.3.3beta doesn't compile
by Kurt＠OpenLDAP.org 05 Oct '06

05 Oct '06

I suggest that anyone wanting to toy with LDAP component matching in OpenLDAP Software use HEAD... the feature needs work. At 02:18 PM 10/5/2006, dieter(a)dkluenter.de wrote: >Full_Name: Dieter Kluenter >Version: openldap-snacc-2.3.3beta Not sure why you didn't try 2.3.6, but regardless, see above. Kurt

1 0

(ITS#4699) snacc-2.3.3beta doesn't compile
by dieter＠dkluenter.de 05 Oct '06

05 Oct '06

Full_Name: Dieter Kluenter Version: openldap-snacc-2.3.3beta OS: linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.210.55) Hi, This are the errors from my attempt to compile snacc /usr/include/c++/3.3.5/backward/backward_warning.h:32:2: Warnung: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning use -Wno-deprecated. vdatest.cpp: In function `void test_timingDoTestPrint(long int, long int, int, long int)': vdatest.cpp:1048: Warnung: int Format, anderer Typ Argument (Argument 4) vdatest.cpp: In function `void AsnIntTest()': vdatest.cpp:1283: error: no matching function for call to `SNACC::AsnInt:: getPadded(unsigned char*&, unsigned int&, int)' ../../c++-lib/inc/asn-incl.h:645: error: candidates are: void SNACC::AsnInt::getPadded(unsigned char*&, size_t&, long unsigned int) const vdatest.cpp:1335: error: no matching function for call to `SNACC::AsnInt:: getPadded(unsigned char*&, unsigned int&, int)' ../../c++-lib/inc/asn-incl.h:645: error: candidates are: void SNACC::AsnInt::getPadded(unsigned char*&, size_t&, long unsigned int) const make[3]: *** [vdatest.o] Fehler 1 make[3]: Leaving directory `/work/openldap-snacc-2.3.3beta/c++-examples/src' make[2]: *** [all] Fehler 2 make[2]: Leaving directory `/work/openldap-snacc-2.3.3beta/c++-examples/src' make[1]: *** [all] Fehler 2 make[1]: Leaving directory `/work/openldap-snacc-2.3.3beta/c++-examples' make: *** [all] Fehler 2 -Dieter

1 0

Re: authz-regexp matches twice on same dse (ITS#4698)
by ap＠d-dt.de 05 Oct '06

05 Oct '06

Pierangelo Masarati wrote: > I don't see an error in OpenLDAP software here. authz regexp matching is > designed to succeed only if the identity is univoquely resolved to exactly one > DN. I'm afraid but I cannot even imagine how slapd could decide to pick one out > of many DNs when authenticating a user; I guess noone else can. > > p. > Matched dn's are unique, as they describing the same Entry: dn: uid=works,dc=example,dc=org objectClass: extensibleObject uid: works dn: cn=worksalso,dc=example,dc=org objectClass: extensibleObject cn: worksalso dn: uid=fails,dc=example,dc=org objectClass: extensibleObject uid: fails cn: fails "(|(cn=works)(uid=works))" and "(|(cn=worksalso)(uid=worksalso))" matching either attribute, whereas "(|(cn=works)(uid=works))" matches twice, but describes the same object. ldapsearching for "(|(cn=fails)(uid=fails))" will also return only the one and unique entry "uid=fails,dc=example,dc=org" A --

1 0

Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by tim＠dcs.qmul.ac.uk 05 Oct '06

05 Oct '06

Howard Chu wrote: > tim(a)dcs.qmul.ac.uk wrote: >> Full_Name: Tim Kay >> Version: OS: Linux (Fedora core 5 RPM) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (138.37.95.144) >> >> >> Modifying a DN on the syncrepl provider fails to propogate to the >> consumer. The >> provider "sends" a valid modify but the consumer, having received the >> modify >> request walks the tree, returns the parent DN to the entry, >> determines that >> write access is permitted and the iterates, at this point >> newSuperior->bv_val is >> set to "*" !? bdb_dn2entry is now searching for "�UUU" which >> looks like >> some unicode screw up. > > Try the patch in CVS slapd/syncrepl.c 1.272 -> 1.273 > That appears to have nailed it. Thank you very much and bug closed I think. Seven hours between bug report and patch release is something to shout from the rooftops too. Best, Tim -- Tim Kay Systems Programmer Department of Computer Science Queen Mary, University of London. Tel: +44 (0) 207 882 7521 Fax: +44 (0) 208 980 6533

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