openldap-bugs

openldap-bugs@openldap.org

20960 discussions

Re: (ITS#6626) NDB Backend with Syncrepl failure
by mhardin＠symas.com 24 Aug '10

24 Aug '10

This was an error on my part and I was promptly corrected by Howard Chu = (Thanks, Howard!). syncrepl is supported for back-ndb and did work when = the code was contributed. We don't know what's happened in the = intervening time, though. Perhaps George will open an ITS? Sorry for any confusion this may have caused. Cheers, -Matt Matthew Hardin Symas Corporation - The LDAP Guys http://www.symas.com On Aug 24, 2010, at 12:13 AM, gtzanetis(a)pylones.gr wrote: > I've received a confirmation from Symas, which is the back_ndb = developer th=3D > at replication does not apply to this backend. They explained that by = desig=3D > n each slapd instance is intended to connect directly to the NDB = cluster by=3D > way of back-ndb. High availability is handled by the cluster. >=20 >=20

1 0

RE: (ITS#6626) NDB Backend with Syncrepl failure
by gtzanetis＠pylones.gr 24 Aug '10

24 Aug '10

I've received a confirmation from Symas, which is the back_ndb developer th= at replication does not apply to this backend. They explained that by desig= n each slapd instance is intended to connect directly to the NDB cluster by= way of back-ndb. High availability is handled by the cluster.

1 0

RE: (ITS#6626) NDB Backend with Syncrepl failure
by gtzanetis＠pylones.gr 23 Aug '10

23 Aug '10

I forgot to state that the operating system is Red Hat 5 Enterprise 64 bit -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org]=20 Sent: Friday, August 20, 2010 4:24 PM To: George Tzanetis Subject: Re: (ITS#6626) NDB Backend with Syncrepl failure *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#6626. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#6626) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#6626) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D6626 Please remember to retain your issue tracking number (ITS#6626) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

Re: (ITS#6627) Empty suffix and dn for root node should be avoided
by masarati＠aero.polimi.it 20 Aug '10

20 Aug '10

> Full_Name: SEAK T.F. > Version: 2.4.18 > OS: Windows XP/7 & Ubuntu 9 > URL: > Submission from: (NULL) (213.41.124.254) > > > Currently it is possible to create a DIT with empty suffix and empty dn > for root > node! Side-note: Such DIT can be used for redirection. > > I've no idea what LDAP standards state, but common sense tells me that > name-less > node doesn't make sense. It's as meaningless as creating a name-less > directory > or name-less file. > > So, when such incorrect parameters are supplied in the conf file, OpenLDAP > service should not start and should exit with error. This issue should be discussed on openldap-technical rather than on the ITS, and should focus on the latest release. In any case, OpenLDAP allows to create an object with empty suffix for a specific technical reason, in two steps: 1) it allows the empty DN ("") to be used as the suffix of a database; the database cannot contain an entry with the empty DN, but it can contain immediate children of it. 2) in some versions, the database may technically contain an empty entry in order to store replication-related information (the contextCSN). I think this is now superseded by the use of a "cn=ldapsync" subentry of "" for this specific purpose. In any case, this ITS will be closed. p.

1 0

(ITS#6627) Empty suffix and dn for root node should be avoided
by lapsap7+bug＠gmail.com 20 Aug '10

20 Aug '10

Full_Name: SEAK T.F. Version: 2.4.18 OS: Windows XP/7 & Ubuntu 9 URL: Submission from: (NULL) (213.41.124.254) Currently it is possible to create a DIT with empty suffix and empty dn for root node! Side-note: Such DIT can be used for redirection. I've no idea what LDAP standards state, but common sense tells me that name-less node doesn't make sense. It's as meaningless as creating a name-less directory or name-less file. So, when such incorrect parameters are supplied in the conf file, OpenLDAP service should not start and should exit with error.

1 0

(ITS#6626) NDB Backend with Syncrepl failure
by gtzanetis＠pylones.gr 20 Aug '10

20 Aug '10

Full_Name: George Tzanetis Version: 2.4.23 OS: Red Hat Enterprise 5 URL: (I've attached outputs from slapd in the above box) Submission from: (NULL) (62.169.213.126) Your e-mail address: Subject: Your full name: OpenLDAP version: OS you are using: Major Security Issue? yes no I ve configured Openldap-2.4.23, which I downloaded from openldap.org, with only back_ndb support (using /configure --enable-ndb --disable-hdb --disable-bdb --prefix=/usr/local/openldap ) And the binaries of MySQL Cluster 7.1.5 (the latest) With the following slapd.conf the slapd worked perfectly: include /usr/local/openldap/etc/openldap/schema/core.schema pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args ####################################################################### # NDB database definitions ####################################################################### #NDB database defintions database ndb suffix "dc=test,dc=org" rootdn "cn=root,dc=test,dc=org" rootpw secret1 dbconnect 192.168.2.175 dbhost 192.168.2.174 dbname openldap dbuser root dbpass "" dbconnections 1 dbsocket /tmp/mysql.sock i.e. I was able to ldapadd, slapadd ldapsearch etc. I then tried to configure this instance of openldap as the PROVIDER of a SYNCREPL replication by adding overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 in the slapd.conf, bellow the database configurations. When I tried to start the slapd service I get: <<< dnNormalize: <cn=root,dc=test,dc=org> *** glibc detected *** slapd: free(): invalid pointer: 0x000000000506c938 *** ======= Backtrace: ========= /lib64/libc.so.6[0x314a27230f] /lib64/libc.so.6(cfree+0x4b)[0x314a27276b] slapd(ber_bvarray_free_x+0x58)[0x4f4be8] slapd(ndb_entry_get+0x1d5)[0x4ad475] slapd(overlay_entry_get_ov+0xfa)[0x49414a] slapd[0x4bf1bf] slapd[0x493ec7] slapd(backend_startup_one+0xb9)[0x441039] slapd(backend_startup+0x1eb)[0x4412fb] slapd(main+0xf13)[0x41bb53] /lib64/libc.so.6(__libc_start_main+0xf4)[0x314a21d994] slapd[0x41a7a9] ======= Memory map: ======== 00400000-00569000 r-xp 00000000 fd:00 1998969 /usr/local/openldap/libexec/slapd 00768000-00771000 rw-p 00168000 fd:00 1998969 /usr/local/openldap/libexec/slapd 00771000-007d6000 rw-p 00771000 00:00 0 04f08000-051b2000 rw-p 04f08000 00:00 0 [heap] 40fd4000-40fd5000 ---p 40fd4000 00:00 0 40fd5000-419d5000 rw-p 40fd5000 00:00 0 419d5000-419d6000 ---p 419d5000 00:00 0 419d6000-419f6000 rw-p 419d6000 00:00 0 419f6000-419f7000 ---p 419f6000 00:00 0 419f7000-41a17000 rw-p 419f7000 00:00 0 41a17000-41a18000 ---p 41a17000 00:00 0 41a18000-41a38000 rw-p 41a18000 00:00 0 41a38000-41a39000 ---p 41a38000 00:00 0 41a39000-41a59000 rw-p 41a39000 00:00 0 41a59000-41a5a000 ---p 41a59000 00:00 0 41a5a000-41a7a000 rw-p 41a5a000 00:00 0 3149e00000-3149e1c000 r-xp 00000000 fd:00 1212420 /lib64/ld-2.5.so 314a01b000-314a01c000 r--p 0001b000 fd:00 1212420 /lib64/ld-2.5.so 314a01c000-314a01d000 rw-p 0001c000 fd:00 1212420 /lib64/ld-2.5.so 314a200000-314a34e000 r-xp 00000000 fd:00 1212427 /lib64/libc-2.5.so 314a34e000-314a54d000 ---p 0014e000 fd:00 1212427 /lib64/libc-2.5.so 314a54d000-314a551000 r--p 0014d000 fd:00 1212427 /lib64/libc-2.5.so 314a551000-314a552000 rw-p 00151000 fd:00 1212427 /lib64/libc-2.5.so 314a552000-314a557000 rw-p 314a552000 00:00 0 314a600000-314a682000 r-xp 00000000 fd:00 1212453 /lib64/libm-2.5.so 314a682000-314a881000 ---p 00082000 fd:00 1212453 /lib64/libm-2.5.so 314a881000-314a882000 r--p 00081000 fd:00 1212453 /lib64/libm-2.5.so 314a882000-314a883000 rw-p 00082000 fd:00 1212453 /lib64/libm-2.5.so 314aa00000-314aa02000 r-xp 00000000 fd:00 1212433 /lib64/libdl-2.5.so 314aa02000-314ac02000 ---p 00002000 fd:00 1212433 /lib64/libdl-2.5.so 314ac02000-314ac03000 r--p 00002000 fd:00 1212433 /lib64/libdl-2.5.so 314ac03000-314ac04000 rw-p 00003000 fd:00 1212433 /lib64/libdl-2.5.so 314ae00000-314ae16000 r-xp 00000000 fd:00 1212435 /lib64/libpthread-2.5.so 314ae16000-314b015000 ---p 00016000 fd:00 1212435 /lib64/libpthread-2.5.so 314b015000-314b016000 r--p 00015000 fd:00 1212435 /lib64/libpthread-2.5.so 314b016000-314b017000 rw-p 00016000 fd:00 1212435 /lib64/libpthread-2.5.so 314b017000-314b01b000 rw-p 314b017000 00:00 0 314b200000-314b214000 r-xp 00000000 fd:00 461719 /usr/lib64/libz.so.1.2.3 314b214000-314b413000 ---p 00014000 fd:00 461719 /usr/lib64/libz.so.1.2.3 314b413000-314b414000 rw-p 00013000 fd:00 461719 /usr/lib64/libz.so.1.2.3 314ba00000-314ba3b000 r-xp 00000000 fd:0Aborted If I delete the database from the mysql cluster and restart the opendap it starts fine but if I use LdapAdd I get: ndb_modify_internal: replace contextCSN Segmentation fault

1 0

(ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by doug.leavitt＠oracle.com 19 Aug '10

19 Aug '10

Full_Name: Douglas Leavitt Version: 2.4.23 (HEAD) OS: OpenSolaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.18.43.225) I would like to propose a patch to the OpenLDAP C APIs to support the operation thread safe features described in the draft-zeilenga-ldap-c-api-concurrency drafts. The enhancements add upwardly compatible interfaces and should have no behavioral regressions w.r.t. any existing libldap interfaces. The new concurrency APIs include: ldap_dup and ldap_destroy They are described in more detail in the concurrency draft and in the applicable man paged. The related feature options are also provided. Additionally I would like to propose 1 new public error API ldap_get_lderror which returns all three ldap_get_option results: LDAP_OPT_MATCHED_DN LDAP_OPT_DIAGNOSTIC_MESSAGE LDAP_OPT_RESULT_CODE in a single API, and 1 new depreciated public API: ldap_get_lderrno which performs almost the same function as ldap_get_error but does so in a mt-unsafe manner, but that is compatible with Mozilla's libldap API of the same name. The point of the two new error APIs is to provide a transition path from Mozilla libldap users that still use ldap_get_lderrno to either a similar API that obeys OpenLDAP like practices (ldap_get_error) or as a transition until any existing code can be converted away from ldap_get_lderrno to just using ldap_get_options as needed. The patch includes a new test case to test the new functionality and man pages. The new test case needs additional work for some of the threading models. Any input here is requested, since I do not have testing resources for all the threading combination and do not have the ability to test the Windows model. I am looking forward to any and all comments. I plan to submit a formal ITS with a finalized version of changes once any and all issues are thrashed out and resolved to a level that they are acceptable for integration. For the record: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Oracle Corporation.Oracle Corporation has not assigned rights and/or interest in this work to any party. I, Douglas Leavitt am authorized by Oracle Corporation, my employer, to release this work under the following terms. The initial version of my proposed patch can be found here: http://cr.opensolaris.org/~djl/openldap-codereview This includes a diff -U of the full patch (/diffU) http://cr.opensolaris.org/~djl/openldap-codereview/diffU a webrev diff (/webrev) for on-line review http://cr.opensolaris.org/~djl/openldap-codereview/webrev/index.html and a tar ball image of the OpenLDAP HEAD as of 8/13/10 with the current patch applied. http://cr.opensolaris.org/~djl/openldap-codereview/openldap-cr1.tar.gz Thank you for you consideration, and I look forward to any and all comments.

1 0

Re: ITS#6611
by leonardo＠ngdn.org 17 Aug '10

17 Aug '10

On Mon, Aug 16, 2010 at 8:06 PM, <masarati(a)aero.polimi.it> wrote: >> On Fri, Jul 30, 2010 at 11:34 PM, =A0<masarati(a)aero.polimi.it> wrote: >>> Likely your ACL is exceeding ACLBUF_MAXLEN (8192, defined in >>> servers/slapd/aclparse.c); you can workaround this issue by increasing >>> that value to something *very* large, while the code is fixed. >>> =3DA0However=3D >> , >>> you should fix your configuration by assigning those DNs to a group, an= d >>> using a group ACL instead. >> >> Thanks for the suggestion. We're now using group ACLs to workaround the >> problem. > > The issue should now be fixed in HEAD; please test and report, if you can= . I just tested and confirmed it's fixed. Thanks a lot! Leonardo

1 0

Re: ITS#6611
by masarati＠aero.polimi.it 17 Aug '10

17 Aug '10

> On Fri, Jul 30, 2010 at 11:34 PM, <masarati(a)aero.polimi.it> wrote: >> Likely your ACL is exceeding ACLBUF_MAXLEN (8192, defined in >> servers/slapd/aclparse.c); you can workaround this issue by increasing >> that value to something *very* large, while the code is fixed. >> =A0However= > , >> you should fix your configuration by assigning those DNs to a group, and >> using a group ACL instead. > > Thanks for the suggestion. We're now using group ACLs to workaround the > problem. The issue should now be fixed in HEAD; please test and report, if you can. Thanks, p.

1 0

Re: (ITS#6624) cn=config support for back_null
by masarati＠aero.polimi.it 16 Aug '10

16 Aug '10

Technically, the contribution looks fine. Personally, I favor the "magic" variant. Kurt, unless there is any IPR issue, I'd commit it. Thanks, 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