- openldap-bugs - openldap.org

Re: (ITS#6629) send_search_entry() does not clear controls
by masarati＠aero.polimi.it 25 Aug '10

25 Aug '10

> > > --On August 26, 2010 3:44:02 AM +0000 masarati(a)aero.polimi.it wrote: > >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (129.72.175.5) >> Submitted by: ando >> >> >> REP_CTRLS_MUSTBEFREED is only honored by send_ldap_response(); when >> response controls are attached to slap_send_search_entry() it is not >> honored. This does not surface because controls must be malloc'ed on >> the >> slab; however, it clearly appears when built with SLAP_NO_SL_MALLOC. > > Interesting -- I'm seeing an issue where I can get slapd to consume all > available memory on the system by using paged results. It takes a while > to > do so (depending on how much memory is available), but it's 100% > repeatable. The more mixes of paged and non paged results there are with > large result sets, the more quickly it happens. pagedResults only sends a control response with the searchResultDone response, which uses send_ldap_response() and thus clears the controls; moreover, we are talking about few bytes, so I don't think this is the issue. There might be something else related to slab allocation that runs out of slab memory and starts using the heap without freeing it. The present issue might affect syncrepl, since in that case a control is attached to each entry/intermediate response (afaik). It might even be intentional; in fact, often when a control is attached to an entry in a searchResultEntry the same control needs to be applied to many entries returned by the same operation. However, in this case we should probably define a specific API for slap_add_ctrls() that does not set the REP_CTRLS_MUSTBEFREED, or something like that. > However, I do not build > with SLAP_NO_SL_MALLOC (or at least, not intentionally ;) ). I occasionally do (you only need to recompile slapd/sl_malloc.c) to trace possible leaks when developing something. Since we make an intensive use of slab mallocs, usual minimal tests with valgrind do not show leaks otherwise. p.

1 0

Re: (ITS#6629) send_search_entry() does not clear controls
by quanah＠zimbra.com 25 Aug '10

25 Aug '10

--On August 26, 2010 3:44:02 AM +0000 masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.72.175.5) > Submitted by: ando > > > REP_CTRLS_MUSTBEFREED is only honored by send_ldap_response(); when > response controls are attached to slap_send_search_entry() it is not > honored. This does not surface because controls must be malloc'ed on the > slab; however, it clearly appears when built with SLAP_NO_SL_MALLOC. Interesting -- I'm seeing an issue where I can get slapd to consume all available memory on the system by using paged results. It takes a while to do so (depending on how much memory is available), but it's 100% repeatable. The more mixes of paged and non paged results there are with large result sets, the more quickly it happens. However, I do not build with SLAP_NO_SL_MALLOC (or at least, not intentionally ;) ). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6630) Support for draft-ietf-ldapext-ldapv3-dupent-08.txt
by masarati＠aero.polimi.it 25 Aug '10

25 Aug '10

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.68) Submitted by: ando I've just committed (to contrib/slapd-modules/dupent/) a nearly complete support for draft-ietf-ldapext-ldapv3-dupent-08.txt (expired) in form of an overlay. I'm not 100% sure about the format of the control request/response values, and I couldn't check interoperability with other software; I only tested it with ldapsearch passing it -E '2.16.840.1.113719.1.27.101.1=:<control request value>', so please use with care (and report). p.

1 0

(ITS#6629) send_search_entry() does not clear controls
by masarati＠aero.polimi.it 25 Aug '10

25 Aug '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.175.5) Submitted by: ando REP_CTRLS_MUSTBEFREED is only honored by send_ldap_response(); when response controls are attached to slap_send_search_entry() it is not honored. This does not surface because controls must be malloc'ed on the slab; however, it clearly appears when built with SLAP_NO_SL_MALLOC. p.

1 0

Re: (ITS#6628) Connection numbering starts at 1000
by quanah＠zimbra.com 24 Aug '10

24 Aug '10

--On Wednesday, August 25, 2010 3:12 AM +0200 masarati(a)aero.polimi.it wrote: >> --On Tuesday, August 24, 2010 5:47 PM -0700 Howard Chu <hyc(a)symas.com> >> wrote: >> >>> quanah(a)zimbra.com wrote: >>>> Full_Name: Quanah Gibson-Mount >>>> Version: 2.4.23 >>>> OS: Linux 2.6 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (75.111.45.108) >>>> >>>> >>>> With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of >>>> at 1 >>> >>> No. cvs log shows that this was patched about a year ago and first >>> released in 2.4.20. Not a bug, closing this ITS. >> >> Connections starting at 1000 is clearly a bug, regardless of when it was >> introduced. > > That was intended, to store connections as unsigned and reserve lower > numbers for special connections (e.g. internal operations and so). I > don't see how using an arbitrary offset in logs can be considered a bug. > 1000 is much like 10, 1024, 666 or 0xbad. Eh, I just need to re-write some scripts to start some things at 1000 then. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6628) Connection numbering starts at 1000
by masarati＠aero.polimi.it 24 Aug '10

24 Aug '10

> --On Tuesday, August 24, 2010 5:47 PM -0700 Howard Chu <hyc(a)symas.com> > wrote: > >> quanah(a)zimbra.com wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.4.23 >>> OS: Linux 2.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.45.108) >>> >>> >>> With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of >>> at 1 >> >> No. cvs log shows that this was patched about a year ago and first >> released in 2.4.20. Not a bug, closing this ITS. > > Connections starting at 1000 is clearly a bug, regardless of when it was > introduced. That was intended, to store connections as unsigned and reserve lower numbers for special connections (e.g. internal operations and so). I don't see how using an arbitrary offset in logs can be considered a bug. 1000 is much like 10, 1024, 666 or 0xbad. p.

1 0

Re: (ITS#6628) Connection numbering starts at 1000
by quanah＠zimbra.com 24 Aug '10

24 Aug '10

--On Tuesday, August 24, 2010 5:47 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.23 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.45.108) >> >> >> With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of >> at 1 > > No. cvs log shows that this was patched about a year ago and first > released in 2.4.20. Not a bug, closing this ITS. Connections starting at 1000 is clearly a bug, regardless of when it was introduced. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6628) Connection numbering starts at 1000
by hyc＠symas.com 24 Aug '10

24 Aug '10

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.23 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of at 1 No. cvs log shows that this was patched about a year ago and first released in 2.4.20. Not a bug, closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6628) Connection numbering starts at 1000
by quanah＠zimbra.com 24 Aug '10

24 Aug '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of at 1 Aug 24 16:10:03 zre-ldap001 slapd[10200]: @(#) $OpenLDAP: slapd 2.4.23 (Aug 6 2010 12:44:14) $#012#011root@zre-ubuntu10-64:/home/build/p4/GNR/ThirdParty/openldap/openldap-2.4.23.2z/servers /slapd Aug 24 16:10:03 zre-ldap001 slapd[10201]: slapd starting Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 fd=12 ACCEPT from IP=10.137.242.51:40585 (IP=10.137.242.51:389) Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=0 BIND dn="" method=128 Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=0 RESULT tag=97 err=0 text= Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=2 UNBIND Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 fd=12 closed Aug 24 16:13:43 zre-ldap001 slapd[10201]: daemon: shutdown requested and initiated. Aug 24 16:13:43 zre-ldap001 slapd[10201]: slapd shutdown: waiting for 0 operations/tasks to finish Aug 24 16:13:43 zre-ldap001 slapd[10201]: slapd stopped. Aug 24 16:14:14 zre-ldap001 slapd[10305]: @(#) $OpenLDAP: slapd 2.4.23 (Aug 6 2010 12:44:14) $#012#011root@zre-ubuntu10-64:/home/build/p4/GNR/ThirdParty/openldap/openldap-2.4.23.2z/servers /slapd Aug 24 16:14:14 zre-ldap001 slapd[10306]: slapd starting Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 fd=12 ACCEPT from IP=10.137.242.51:55960 (IP=10.137.242.51:389) Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=0 BIND dn="" method=128 Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=0 RESULT tag=97 err=0 text= Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=2 UNBIND Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 fd=12 closed Aug 24 16:15:57 zre-ldap001 slapd[10306]: daemon: shutdown requested and initiated. Aug 24 16:15:57 zre-ldap001 slapd[10306]: slapd shutdown: waiting for 0 operations/tasks to finish Aug 24 16:15:57 zre-ldap001 slapd[10306]: slapd stopped. Aug 24 16:17:02 zre-ldap001 slapd[10554]: @(#) $OpenLDAP: slapd 2.4.23 (Aug 6 2010 12:44:14) $#012#011root@zre-ubuntu10-64:/home/build/p4/GNR/ThirdParty/openldap/openldap-2.4.23.2z/servers /slapd Aug 24 16:17:02 zre-ldap001 slapd[10555]: slapd starting Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 fd=12 ACCEPT from IP=10.137.242.51:55961 (IP=10.137.242.51:389) Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=0 BIND dn="" method=128 Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=0 RESULT tag=97 err=0 text= Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=2 UNBIND Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 fd=12 closed

1 0

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 23 Aug '10

23 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 18 Aug '10

18 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 16 Aug '10

16 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

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

16 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.

1 0

(ITS#6624) cn=config support for back_null
by ondrej.kuznik＠acision.com 16 Aug '10

16 Aug '10

Full_Name: Ondrej Kuznik Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.168.56.1) Back-null database currently does not support cn=config. Although there is only one directive (bind allowed), it could be useful to support it once openldap no longer uses slapd.conf. The following patches represent two alternatives that attempt to add this capability, adding a new attribute type (OLcfgDbAt:8.1 'olcDbBindAllowed') and one objectclass (OLcfgDbOc:8.1 'olcNullConfig') to the schemas. They are two as I am new to slapd internals and do not know which approach is more preferable. ftp://ftp.openldap.org/incoming/ondrej-kuznik-20100624-back_null_simple.pat… The first patch adds the functionality using only bconfig.c config_{check,set}_vals (through flags ARG_ON_OFF|ARG_OFFSET) but a modify that deletes the attribute leaves the value of ni_bind_allowed intact. ftp://ftp.openldap.org/incoming/ondrej-kuznik-20100624-back_null_magic.patch The second one uses a callback function like any other backend so it does not suffer from this issue. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondřej Kuzník am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#6623) segmentation fault
by michael＠stroeder.com 16 Aug '10

16 Aug '10

nareshyathapu(a)gmail.com wrote: > Full_Name: Naresh Reddy > Version: 2.4.11 Current release is 2.4.23. There have been a lot of changes since then including fixes for crashes. So if you suspect OpenLDAP server software to crash could you please try to reproduce this with the current release? > Trying to connect to ldapserver and ldap server is down. Core dump is happening > below is the code and gdb.. Is slapd crashing? > warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at > ffffe0b4 > Core was generated by `/usr/UMR/current/bin/ldapMgr --start=cold'. Could you please elaborate on what kind of software /usr/UMR/current/bin/ldapMgr is? I'm not a OpenLDAP core developer but that does not look like an OpenLDAP component to me. Ciao, Michael.

1 0

(ITS#6623) segmentation fault
by nareshyathapu＠gmail.com 16 Aug '10

16 Aug '10

Full_Name: Naresh Reddy Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.166.63.98) Trying to connect to ldapserver and ldap server is down. Core dump is happening below is the code and gdb.. Code ------- u32_t rc=ldap_sasl_bind(ld, loginDN, LDAP_SASL_SIMPLE, &cred, NULL, NULL, &msgid); //asynchronous bind if (rc != LDAP_SUCCESS ) { ldapErrorLog(":connect: LDAP Bind send Failed:%s \n ", ldap_err2string(rc)); ldap_unbind_ext_s(ld, NULL,NULL); m_connInitialized = false; return(LDAPRC_FAIL); } GDB ----- warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4 Core was generated by `/usr/UMR/current/bin/ldapMgr --start=cold'. Program terminated with signal 11, Segmentation fault. #0 0x43b91cc9 in free () from /lib/libc.so.6 (gdb) bt #0 0x43b91cc9 in free () from /lib/libc.so.6 #1 0x080a6854 in ldap_free_select_info (sip=0x118) at os-ip.c:936 #2 0x080a29ab in ldap_ld_free (ld=0xf3ebec20, close=1, sctrls=0x0, cctrls=0x0) at unbind.c:131 #3 0x080a2aab in ldap_unbind_ext (ld=0xf3ebec20, sctrls=0x0, cctrls=0x0) at unbind.c:52 #4 0x0808368f in LdapConnection::connect (this=0xd252888, loginDN=0xd258ddc "bwLoginname=sms_ldap_bind", pwd=0xd258edd "metropcs_sms") at LdapConnection.cpp:159 #5 0x08051731 in LdapPeer::LdapWorkerProcess (this=0xd2586b0) at LdapPeer.cpp:322 #6 0x080827b2 in run (handle=0xd2586b0) at LdapCommonDefs.cpp:47 #7 0x43c5be49 in ?? () from /lib/libpthread.so.0

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 12 Aug '10

12 Aug '10

Doug Leavitt wrote: > I have been testing pretty consistently on Solaris this year, > most recent on HEAD versus RELEASE. thats how I noticed > the ITS 6621 issue. > > I may be able to do some specific testing on specific hardware > platforms, depending on what is desired, and what I can get > access to. I do regulary test on both x86 and sparc platforms. > > Also, I now have Oracle legal permission to pass OpenLDAP > enhancements and fixes upstream. > > I am almost ready to submit a proposed patch to libldap to deliver > a revised version of draft-zeilenga-ldap-c-api-concurrency-00.txt > functionality for OpenLDAP libldap. > > My proposed patch so far implements the ldap_dup and > ldap_destroy portions of the specification, but I have not > yet implemented the LDAP_OPT_SESSION_REFCNT or > added any LDAP_API_FEATURE* style macros. > > I would like some guidance if/what macros in ldap.h are desired. > > I am working on the assumption that some public discussion > and peer review will be expected before any patch submission > would be accepted. > > Should I start with a discussion on openldap-technical first? Other? Sounds very interesting; discussions of this nature (modifications to OpenLDAP code) are most appropriate for the -devel list. Looking forward to continuing this conversation there. > > Doug. > > > > On 08/12/10 06:21 PM, hyc(a)symas.com wrote: >> masarati(a)aero.polimi.it wrote: >>> Blind-fixed in HEAD. Thanks, p. >> By the way Ando, any more ideas about the devpoll implementation? Have you >> tested it against select on Solaris recently? >> > -- -- Howard Chu CTO, 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#6621) Compile time error in daemon.c 1.446
by doug.leavitt＠oracle.com 12 Aug '10

12 Aug '10

I have been testing pretty consistently on Solaris this year, most recent on HEAD versus RELEASE. thats how I noticed the ITS 6621 issue. I may be able to do some specific testing on specific hardware platforms, depending on what is desired, and what I can get access to. I do regulary test on both x86 and sparc platforms. Also, I now have Oracle legal permission to pass OpenLDAP enhancements and fixes upstream. I am almost ready to submit a proposed patch to libldap to deliver a revised version of draft-zeilenga-ldap-c-api-concurrency-00.txt functionality for OpenLDAP libldap. My proposed patch so far implements the ldap_dup and ldap_destroy portions of the specification, but I have not yet implemented the LDAP_OPT_SESSION_REFCNT or added any LDAP_API_FEATURE* style macros. I would like some guidance if/what macros in ldap.h are desired. I am working on the assumption that some public discussion and peer review will be expected before any patch submission would be accepted. Should I start with a discussion on openldap-technical first? Other? Doug. On 08/12/10 06:21 PM, hyc(a)symas.com wrote: > masarati(a)aero.polimi.it wrote: >> Blind-fixed in HEAD. Thanks, p. > By the way Ando, any more ideas about the devpoll implementation? Have you > tested it against select on Solaris recently? >

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs