openldap-bugs

openldap-bugs@openldap.org

20960 discussions

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

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

13 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

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

13 Aug '10

masarati(a)aero.polimi.it 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? > > I haven't had access to Solaris in years... p. Me neither. Too bad, a Niagara might actually show more than a 1% gain from the multi-listener patch. -- -- 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 masarati＠aero.polimi.it 13 Aug '10

13 Aug '10

> 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? I haven't had access to Solaris in years... p.

1 0

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

13 Aug '10

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 masarati＠aero.polimi.it 13 Aug '10

13 Aug '10

Blind-fixed in HEAD. 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