openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

ITS#3429 schema download module
by hyc＠symas.com 15 Dec '07

15 Dec '07

I was looking at this code in relation to current HEAD/RE24, and things have changed quite a bit. Given the ability to dynamically load schema into cn=config, is there still a need for this module? (It is in fact the changes made for dynamic schema manipulation in slapd that causes the compatibility issues with this module.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#4398 unique overlay enhancement
by hyc＠symas.com 15 Dec '07

15 Dec '07

Thanks for your patches. A more extensive version of these features was added in OpenLDAP 2.4 (March 2007). This ITS will be closed. -- -- Howard Chu Chief Architect, 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#5263) ldap_parse_sasl_bind_result() returning wrong error code
by hyc＠symas.com 15 Dec '07

15 Dec '07

rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: HEAD, RE23, RE24 > OS: - > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.205.58) > > > According to the man-pages and the C-API draft the ldap_parse_*_result() > functions return LDAP_SUCCESS, when the result was successfully parsed, > otherwise != LDAP_SUCCESS. > The current implementation of ldap_parse_sasl_bind_result() (not sure about > ldap_parse_extended_result()) however will return the LDAP Error Code of the > passwd LDAPMessages as the result (e.g. LDAP_SASL_BIND_IN_PROGRESS). > > If this is the desired behavior we should fix our documentation. But I guess > this is a bug in ldap_parse_sasl_bind_result() and probably > ldap_parse_extended_result(). Fixed in HEAD. ldap_parse_extended_result() was correct. -- -- Howard Chu Chief Architect, 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#5284) cn=config overlay order
by hyc＠symas.com 15 Dec '07

15 Dec '07

dhawes(a)vt.edu wrote: > Full_Name: David Hawes > Version: 2.3.39/2.4.6 > OS: Debian GNU/Linux > URL: > Submission from: (NULL) (96.228.44.90) > > > Overlays are processed in the reverse order of slapd.conf when using slapd.d. Thanks for the report, this is now fixed in CVS HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5284) cn=config overlay order
by dhawes＠vt.edu 14 Dec '07

14 Dec '07

Full_Name: David Hawes Version: 2.3.39/2.4.6 OS: Debian GNU/Linux URL: Submission from: (NULL) (96.228.44.90) Overlays are processed in the reverse order of slapd.conf when using slapd.d. If I have the following in slapd.conf: ... overlay overlay1 overlay overlay2 overlay overlay3 ... and convert it to slapd.d, I will see the following in cn=config: ... # {0}overlay3, {1}bdb, config dn: olcOverlay={0}overlay3,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig olcOverlay: {0}overlay3 # {1}overlay2, {1}bdb, config dn: olcOverlay={1}overlay2,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig olcOverlay: {1}overlay2 # {2}overlay1, {1}bdb, config dn: olcOverlay={2}overlay1,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig olcOverlay: {2}overlay1 ... When slapd is started with slapd.conf, the overlay stack is correct (overlay3 -> overlay2 -> overlay1 for processing order), although cn=config reports the above. When slapd.d is used, the overlay stack is the opposite (overlay1 -> overlay2 -> overlay3). This occurs in both 2.3.39 and 2.4.6. I see this as a problem in situations where order of overlays is important (syncprov comes to mind).

1 0

Re: (ITS#5280) JLDAP waits for response for request which hasn't been sent because of connection shutdown
by M.Waldowski＠sulechow.net 14 Dec '07

14 Dec '07

Hello. I didn't know that pastes from rafb.net are removed after 24 hours. The new location of thread dump is here: http://www.sulechow.net/~mwaldows/ITS-5280/thread-dump.log and new location of JLDAP debug is here: http://www.sulechow.net/~mwaldows/ITS-5280/debug.log Regards Marcin M.Waldowski(a)sulechow.net wrote: > Full_Name: Marcin Waldowski > Version: novell-jldap-devel-2007.10.12-1netware_windows > OS: Windows XP > URL: > Submission from: (NULL) (83.20.102.205) > > > Hello. > > Our application gets lots of information from LDAP server which uses refferals. > Code which use jldap is executed in single thread. After some time of obtaining > informations JLDAP hangs in MessageAgent.getLDAPMessage() as you can see at > following thread dump: > > http://rafb.net/p/kwhTyh67.html > > It is repeatable every time we execute our application. It hangs always in the > same line of JLDAP code. > > We turned on jldap debug (-Dldap.debug=TraceAll) and also sniffed communication > between JLDAP and LDAP server using Wireshark. Interesting part of JLDAP debug > you can see here: > > http://rafb.net/p/diqKzz11.html > > As you can see some refferal connections is lost in lines 14, 35, 53. After that > we have some writes to that connections in lines 240 (message 146), 283 > (message 147) and 333 (message 148). All this writes didn't come to the wire (as > we can see in Wireshark or rather cannot see) because of "java.io.IOException: > Output stream not initialized". This exception is only logged to debug stream > and silently discarded in com.novell.ldap.Connection.writeMessage(LDAPMessage > msg) because variable clientActive is false. So, If I understand it correctly, > caller code doesn't know that anything goes wrong in called (write message) > code. As a result JLDAP still wait for responses of messages 146, 147, 148 which > hasn't been sent. This ends up with forever wait in line 368 of debug stream. > > Regards > Marcin > > >

1 0

(ITS#5280) JLDAP waits for response for request which hasn't been sent because of connection shutdown
by M.Waldowski＠sulechow.net 14 Dec '07

14 Dec '07

Full_Name: Marcin Waldowski Version: novell-jldap-devel-2007.10.12-1netware_windows OS: Windows XP URL: Submission from: (NULL) (83.20.102.205) Hello. Our application gets lots of information from LDAP server which uses refferals. Code which use jldap is executed in single thread. After some time of obtaining informations JLDAP hangs in MessageAgent.getLDAPMessage() as you can see at following thread dump: http://rafb.net/p/kwhTyh67.html It is repeatable every time we execute our application. It hangs always in the same line of JLDAP code. We turned on jldap debug (-Dldap.debug=TraceAll) and also sniffed communication between JLDAP and LDAP server using Wireshark. Interesting part of JLDAP debug you can see here: http://rafb.net/p/diqKzz11.html As you can see some refferal connections is lost in lines 14, 35, 53. After that we have some writes to that connections in lines 240 (message 146), 283 (message 147) and 333 (message 148). All this writes didn't come to the wire (as we can see in Wireshark or rather cannot see) because of "java.io.IOException: Output stream not initialized". This exception is only logged to debug stream and silently discarded in com.novell.ldap.Connection.writeMessage(LDAPMessage msg) because variable clientActive is false. So, If I understand it correctly, caller code doesn't know that anything goes wrong in called (write message) code. As a result JLDAP still wait for responses of messages 146, 147, 148 which hasn't been sent. This ends up with forever wait in line 368 of debug stream. Regards Marcin

2 1

Re: (ITS#5273) ldap.conf and TLS as a default
by hyc＠symas.com 14 Dec '07

14 Dec '07

This appears to be the same as ITS#5039. This ITS will be closed, you can followup to #5039. cardoe(a)gentoo.org wrote: > Full_Name: Douglas Klima > Version: 2.3. > OS: Linux > URL: > Submission from: (NULL) (216.155.111.10) > > > I was looking for a way to make TLS the default in > /etc/openldap/ldap.conf however it currently seems impossible. You can > specify LDAP over clear text and LDAP over SSL but you can't specify > LDAP over TLS (I'm talking about "start_tls"). It seems like ldaps:// is > deprecated in favor of ldap:// + TLS, which is why I'm trying to > configure this. > > Currently my /etc/openldap/ldap.conf looks like: > BASE dc=example,dc=com > URI ldap://srv1.example.com ldap://srv2.example.com > TLS_REQCERT demand > TLS_CACERTDIR /etc/ssl/certs > > If I do the following: > $ ldapsearch > ldap_bind: Confidentiality required (13) > additional info: TLS confidentiality required > > If I change URI to have "ldaps://srv1.example.com:389", then > $ ldapsearch > just hangs until it times out. Clearly it's not using start_tls. > > Now if I change URI back to it's original setting and do: > > $ ldapsearch -Z > .... > # search result > search: 3 > result: 0 Success > > # numResponses: 54 > # numEntries: 53 > > I get a successful lookup. I'm basically looking for a way to pass "-Z" > in /etc/openldap/ldap.conf and in .ldaprc > > Initially I tried to send this to the OpenLDAP ML but was told by MacJobBz to > submit this to ITS. > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5283) translucent search enhancement
by hyc＠OpenLDAP.org 14 Dec '07

14 Dec '07

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Currently the translucent overlay only searches the remote database, then matches local entries to the results. It needs to be able to search the local database as well.

1 0

Re: (ITS#5276) include handler broken
by quanah＠zimbra.com 14 Dec '07

14 Dec '07

--On December 13, 2007 1:17:08 AM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.39 Also broken in OpenLDAP 2.4.7. This config works as expected: include "/usr/local/etc/openldap/schema/core.schema" include "/usr/local/etc/openldap/schema/cosine.schema" include "/usr/local/etc/openldap/schema/inetorgperson.schema" threads 8 pidfile "/var/run/slapd.pid" argsfile "/var/run/slapd.args" loglevel 256 modulepath /usr/local/lib/openldap moduleload back_bdb.la moduleload back_hdb.la moduleload back_monitor.la moduleload syncprov.la moduleload accesslog.la access to * by * write database config rootpw secret database bdb suffix "" rootdn "cn=config" cachesize 10000 idlcachesize 10000 checkpoint 64 5 directory "/usr/local/openldap-data" index objectClass eq index uid pres,eq index mail pres,eq,sub index cn pres,eq,sub index displayName pres,eq,sub index sn pres,eq,sub index gn pres,eq,sub index entryUUID eq index entryCSN eq sizelimit unlimited timelimit unlimited overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 500 Modifying it so that it is now: include "/usr/local/etc/openldap/schema/core.schema" include "/usr/local/etc/openldap/schema/cosine.schema" include "/usr/local/etc/openldap/schema/inetorgperson.schema" threads 8 pidfile "/var/run/slapd.pid" argsfile "/var/run/slapd.args" loglevel 256 modulepath /usr/local/lib/openldap moduleload back_bdb.la moduleload back_hdb.la moduleload back_monitor.la moduleload syncprov.la moduleload accesslog.la access to * by * write database config rootpw secret include /usr/local/etc/openldap/bdb-conf include /usr/local/etc/openldap/overlays-conf Where bdb-conf is: database bdb suffix "" rootdn "cn=config" cachesize 10000 idlcachesize 10000 checkpoint 64 5 directory "/usr/local/openldap-data" index objectClass eq index uid pres,eq index mail pres,eq,sub index cn pres,eq,sub index displayName pres,eq,sub index sn pres,eq,sub index gn pres,eq,sub index entryUUID eq index entryCSN eq sizelimit unlimited timelimit unlimited and overlays-conf is: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 500 The contextCSN is never created in the root database, whereas in the former example it is. I did other experiments with a more complicated config, and managed to completely lock up slapd as well. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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