openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#3630) [JLDAP] GetBindID extended operation gives ClassCastException
by rarpit＠novell.com 27 Nov '07

27 Nov '07

This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part5C7A5B2F.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Generally, the extensions (extended operations) are not common to all the = LDAP servers. Most of the extensions available here as part of jldap(includ= ing the GetBindDN) are exensions supported by eDirectory. However one = should not get such exceptions, which you've reported even on the other = LDAP servers (as Active Directory).=20 =20 However, I tried the same code as stated on AD server and I didn't get the = exception you got. Instead I am getting the following exceptions=20 =20 Login succeeded=20 Error: LDAPException: Protocol Error (2) Protocol ErrorLDAPException: = Server Message: 0000203D: LdapErr: DSID-0C090C7D, comment: Unknown = extended request OID, data 0, vece=20 =20 which is the expected behavior. =20 Please check the issues once again with the latest JLDAP code and please = do let me know if I need to do something more for replicating the problem, = if it still persists. --=__Part5C7A5B2F.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>Generally, the extensions (extended operations) are not common to all = the LDAP servers. Most of the extensions available here as part of = jldap(including the GetBindDN) are exensions supported by eDirectory. = However one should not get such exceptions, which you've reported even on = the other LDAP servers (as Active Directory). </DIV> <DIV> </DIV> <DIV>However, I tried the same code as stated on AD server and I didn't = get the exception you got. Instead I am getting the following exceptions = </DIV> <DIV> </DIV> <DIV>Login succeeded <BR>Error: LDAPException: Protocol Error (2) Protocol = ErrorLDAPException: Server Message: 0000203D: LdapErr: DSID-0C090C7D, = comment: Unknown extended request OID, data 0, vece </DIV> <DIV> </DIV> <DIV>which is the expected behavior.</DIV> <DIV> </DIV> <DIV>Please check the issues once again with the latest JLDAP code and = please do let me know if I need to do something more for replicating the = problem, if it still persists.</DIV></BODY></HTML> --=__Part5C7A5B2F.0__=--

1 0

Re: (ITS#3630) [JLDAP] GetBindID extended operation gives ClassCastException
by rarpit＠novell.com 27 Nov '07

27 Nov '07

This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part6A4C6D19.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Generally, the extensions (extended operations) are not common to all the = LDAP servers. Most of the extensions available here as part of jldap(includ= ing the GetBindDN) are exensions supported by eDirectory. However one = should not get such exceptions, which you've reported even on the other = LDAP servers (as Active Directory).=20 =20 However, I tried the same code as stated on AD server and I didn't get the = exception you got. Instead I am getting the following exceptions=20 =20 Login succeeded=20 Error: LDAPException: Protocol Error (2) Protocol ErrorLDAPException: = Server Message: 0000203D: LdapErr: DSID-0C090C7D, comment: Unknown = extended request OID, data 0, vece=20 =20 which is the expected behavior. =20 Please check the issues once again with the latest JLDAP code and please = do let me know if I need to do something more for replicating the problem, = it it still persists. --=__Part6A4C6D19.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>Generally, the extensions (extended operations) are not common to all = the LDAP servers. Most of the extensions available here as part of = jldap(including the GetBindDN) are exensions supported by eDirectory. = However one should not get such exceptions, which you've reported even on = the other LDAP servers (as Active Directory). </DIV> <DIV> </DIV> <DIV>However, I tried the same code as stated on AD server and I didn't = get the exception you got. Instead I am getting the following exceptions = </DIV> <DIV> </DIV> <DIV>Login succeeded <BR>Error: LDAPException: Protocol Error (2) Protocol = ErrorLDAPException: Server Message: 0000203D: LdapErr: DSID-0C090C7D, = comment: Unknown extended request OID, data 0, vece </DIV> <DIV> </DIV> <DIV>which is the expected behavior.</DIV> <DIV> </DIV> <DIV>Please check the issues once again with the latest JLDAP code and = please do let me know if I need to do something more for replicating the = problem, it it still persists.</DIV></BODY></HTML> --=__Part6A4C6D19.0__=--

1 0

(ITS#5248) non-atomic signal variables
by h.b.furuseth＠usit.uio.no 27 Nov '07

27 Nov '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Some non-atomic variables are used both outside and inside signal handlers: clients/tools/common.c: static int gotintr; static int abcan; servers/slapd/daemon.c: static volatile int waking; (used via WAKE_LISTENER in signal handler) slapd/slapcat.c: static int gotsig; They need to be volatile sig_atomic_t. That can be signed or unsigned char, so abcan must be set to some #define in range 0..127 instead of -1. Two more problems: WAKE_LISTENER will not be correct anyway since it does '++waking' (not atomic) and is called both inside and outside a signal handler. The !NO_THREADS version is OK. For that matter, behavior is only defined when the signal handler _writes_ a volatile sig_atomic_t, not when it _reads_ it: http://groups.google.no/group/comp.std.c/msg/d01196111ce93615 Dunno what the problem is, or if it is worse than variables accessed by threads. I don't see anything to do about it either.

1 0

(ITS#5247) ldapmodify results misleading
by quanah＠OpenLDAP.org 27 Nov '07

27 Nov '07

Full_Name: Quanah Gibson-Mount Version: HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.21.80.71) When ldapmodify prints "modify complete" all it has done so far is send the request to the server. It hasn't actually read the server's reply yet. This should be fixed so that better information is given to the end client about the state of the modify request.

1 0

Re: (ITS#5241) slapd crashes with "loglevel 0"
by rhafer＠suse.de 26 Nov '07

26 Nov '07

On Freitag, 23. November 2007, Ulrich.Windl(a)rz.uni-regensburg.de wrote: > Full_Name: Ulrich Windl > Version: 2.3.32 > OS: SLES10 SP1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.199.156.178) > > > The version of OpenLDAP shipped with SUSE Linux Enterprise Server 10 > (SLES10) SP1, openldap2-2.3.32-0.23 crashes with a segmentation fault if > "loglevel 0" is used. For other log levels things seem to work. The problem > has been seen on x86_64 (segfaults are logged in syslog). If you want to report bugs in OpenLDAP through the OpenLDAP ITS you should always test if the bug is present in most recently release version of the software (2.3.39 in this case). If you want to report bugs against older Versions, that were shipped with a product of some vendor you should report the bug to the vendor of that product. So in your case please either test with OpenLDAP 2.3.39 (you can find SLES packages here: http://download.opensuse.org/repositories/OpenLDAP/SLE_10/ Or report the bug to SUSE/Novell here: http://support.novell.com/additional/bugreport.html or, if you have a valid support contract to you contact in support. Btw, I have some x86_64 SLES10-SP1 systems with openldap-2.3.32 running here with 'loglevel 0' without any problem, so I suspect there are some additional things that trigger your problem. But to go further please choose one of the options I gave you above -- Ralf -------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

1 0

Re: (ITS#5245) auditlog man page and feature request
by ghenry＠suretecsystems.com 26 Nov '07

26 Nov '07

<quote who="hyc(a)symas.com"> > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: 2.4.6 >> OS: F8 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> Note to self about man page missing any cn=config examples, for example: >> >> dn: cn=module{0},cn=config >> changetype: modify >> add: olcModuleLoad >> olcModuleLoad: {2}auditlog.la >> >> dn: olcOverlay=auditlog,olcDatabase={1}hdb,cn=config >> changetype: add >> objectClass: olcOverlayConfig >> objectClass: olcAuditLogConfig >> olcOverlay: auditlog >> >> dn: olcOverlay={0}auditlog,olcDatabase={1}hdb,cn=config >> changetype: modify >> add: olcAuditlogFile >> olcAuditlogFile: /tmp/auditlog.ldif >> > > The above is a poor example, you should set all the relevant attributes > when > the object is created. Doing a subsequent modify is a waste. This was just a quick c&p I did from test050, but yes, a waste. > >> Nothing noting the format of olcAuditlogFile, i.e. /tmp or file:///tmp > > The doc says it's a fully qualified path. That means it is not a URL. This > point is superfluous. Aye, it will be obvious in the example. Thanks. > >> Feature request: >> >> New config setting to define mode. At the moment it's 0644 >> >> Thanks. > > -- > -- 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#5240
by quanah＠zimbra.com 25 Nov '07

25 Nov '07

--On November 26, 2007 3:53:34 AM +0000 hyc(a)symas.com wrote: > I don't know what timestamp you're looking at, but according to CVS > init.c still has not been sync'd. (11/18/2007) > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-bdb/init.c?hi > deattic=1&sortbydate=0 > > You should not be making blind commits into the Release Engineering > branches. It's your job to verify that the commits are correct. back-bdb > is broken in RE24 right now. I wasn't making blind commits, I've been making commits in the same sequence as they come into the commit list, after confirming with you. In any case, I think I must have been looking at your commit to fix back-bdb/init.c, because I was seeing 0 difference between HEAD/2.4 when looking prior to writing my mail, and missed that it had been your commit. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#5240
by hyc＠symas.com 25 Nov '07

25 Nov '07

quanah(a)zimbra.com wrote: > --On November 22, 2007 5:11:30 PM +0000 ando(a)sys-net.it wrote: > >> A fix for ITS#5183 has been partially imported into re24 (back-bdb.h; >> init.c not yet). I don't know if it was intended, or if the merging is >> just in progress. > > init.c was sync'd prior to this ITS even being filed, unless its a > timestamp issue somewhere (11/21/2007). back-bdb.h was sync'd except for > the ifdef LDAP_DEVEL, which shouldn't have had an effect since > BDB_MONITOR_IDX was already defined. If things still aren't working with > 2.4, then something else is the matter. I don't know what timestamp you're looking at, but according to CVS init.c still has not been sync'd. (11/18/2007) http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-bdb/init.c?hide… You should not be making blind commits into the Release Engineering branches. It's your job to verify that the commits are correct. back-bdb is broken in RE24 right now. -- -- 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#5240
by quanah＠zimbra.com 25 Nov '07

25 Nov '07

--On November 22, 2007 5:11:30 PM +0000 ando(a)sys-net.it wrote: > A fix for ITS#5183 has been partially imported into re24 (back-bdb.h; > init.c not yet). I don't know if it was intended, or if the merging is > just in progress. init.c was sync'd prior to this ITS even being filed, unless its a timestamp issue somewhere (11/21/2007). back-bdb.h was sync'd except for the ifdef LDAP_DEVEL, which shouldn't have had an effect since BDB_MONITOR_IDX was already defined. If things still aren't working with 2.4, then something else is the matter. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5245) auditlog man page and feature request
by hyc＠symas.com 25 Nov '07

25 Nov '07

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: 2.4.6 > OS: F8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Note to self about man page missing any cn=config examples, for example: > > dn: cn=module{0},cn=config > changetype: modify > add: olcModuleLoad > olcModuleLoad: {2}auditlog.la > > dn: olcOverlay=auditlog,olcDatabase={1}hdb,cn=config > changetype: add > objectClass: olcOverlayConfig > objectClass: olcAuditLogConfig > olcOverlay: auditlog > > dn: olcOverlay={0}auditlog,olcDatabase={1}hdb,cn=config > changetype: modify > add: olcAuditlogFile > olcAuditlogFile: /tmp/auditlog.ldif > The above is a poor example, you should set all the relevant attributes when the object is created. Doing a subsequent modify is a waste. > Nothing noting the format of olcAuditlogFile, i.e. /tmp or file:///tmp The doc says it's a fully qualified path. That means it is not a URL. This point is superfluous. > Feature request: > > New config setting to define mode. At the moment it's 0644 > > Thanks. -- -- 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

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