openldap-bugs

openldap-bugs@openldap.org

1 participants
21000 discussions

(ITS#6781) Add support for suffixmassage in syncrepl consumer
by hyc＠OpenLDAP.org 06 Jan '11

06 Jan '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc (Already in HEAD/RE24) The consumer should be able to pull from a remote suffix that differs from the local suffix.

1 0

(ITS#6780) Add support for multiple listener threads
by hyc＠OpenLDAP.org 06 Jan '11

06 Jan '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc (Already in HEAD/RE24, just needs a manpage update)

1 0

(ITS#6779) Allow clients to specify USERNAME in session tracking control
by masarati＠aero.polimi.it 05 Jan '11

05 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.18.39) Submitted by: ando A patch is coming. p.

1 0

(ITS#6778) One-time leak in generic client tools controls
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.18.39) Submitted by: ando A fix is coming. p.

1 0

Re: (ITS#6777) test014 fails
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

Sorry for the noise. The problem was real (the leak), but the solution (that free) was wrong. It's not a big deal: we usually tolerate leaks in client tools (they're mainly annoying because they cause a lot of noise in valgrind output). I'll provide a better fix some time. p.

1 0

Re: (ITS#6777) test014 fails
by quanah＠zimbra.com 04 Jan '11

04 Jan '11

--On Tuesday, January 04, 2011 9:30 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, January 04, 2011 9:16 PM +0000 quanah(a)OpenLDAP.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: RE24 1/4/2011 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.45.108) >> >> >> The ldapwhoami utility was recently modified to use ldap_parse_whoami. >> This change appears to have broken test014: > > This isn't ldapwhoami of course, but a library issue. :/ Modified Files: common.c 1.143 -> 1.144 Fixes it, thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6777) test014 fails
by quanah＠zimbra.com 04 Jan '11

04 Jan '11

--On Tuesday, January 04, 2011 9:16 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 1/4/2011 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > The ldapwhoami utility was recently modified to use ldap_parse_whoami. > This change appears to have broken test014: This isn't ldapwhoami of course, but a library issue. :/ --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6777) test014 fails
by quanah＠OpenLDAP.org 04 Jan '11

04 Jan '11

Full_Name: Quanah Gibson-Mount Version: RE24 1/4/2011 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) The ldapwhoami utility was recently modified to use ldap_parse_whoami. This change appears to have broken test014: Testing ldapwhoami as cn=Manager,dc=example,dc=com for dn:cn=Barbara Jensen,ou=Information Technology DivisioN,ou=People,dc=example,dc=com... ldap_parse_result: Proxied Authorization Denied (123) additional info: authzId mapping failed Result: Proxied Authorization Denied (123) Additional info: authzId mapping failed ldapwhoami failed (1)! Something seems seriously wrong with how it is parsing/passed the controls: <<< dnPrettyNormal: <cn=Manager,dc=example,dc=com>, <cn=manager,dc=example,dc=com> conn=1004 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 do_bind: version=3 dn="cn=Manager,dc=example,dc=com" method=128 ==> hdb_bind: dn: cn=Manager,dc=example,dc=com conn=1004 op=0 BIND dn="cn=Manager,dc=example,dc=com" mech=SIMPLE ssf=0 do_bind: v3 bind: "cn=Manager,dc=example,dc=com" to "cn=Manager,dc=example,dc=com" send_ldap_result: conn=1004 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 12 conn=1004 op=0 RESULT tag=97 err=0 text= connection_get(12) connection_get(12): got connid=1004 connection_read(12): checking for input on id=1004 ber_get_next ber_get_next: tag 0x30 len 76 contents: op tag 0x77, time 1294175708 ber_get_next conn=1004 op=1 do_extended ber_scanf fmt ({m) ber: => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (b) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="2.16.840.1.113730.3.4.18" (critical) parseProxyAuthz: conn 1004 authzid="dn:cn=Ba<80><90>x" slap_sasl_getdn: conn 1004 id=dn:cn=Ba<80><90>x [len=11] >>> dnNormalize: <cn=Ba<80><90>x> => ldap_bv2dn(cn=Ba<80><90>x,0) <= ldap_bv2dn(cn=Ba<80><90>x)=0 <= get_ctrls: n=1 rc=123 err="authzId mapping failed" send_ldap_result: conn=1004 op=1 p=3 send_ldap_result: err=123 matched="" text="authzId mapping failed" send_ldap_response: msgid=2 tag=120 err=123 ber_flush2: 36 bytes to sd 12 conn=1004 op=1 RESULT tag=120 err=123 text=authzId mapping failed conn=1004 op=1 do_extended: get_ctrls failed connection_get(12) connection_get(12): got connid=1004 connection_read(12): checking for input on id=1004 ber_get_next

1 0

Re: (ITS#6773) Per-connection extra stuff
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

> I think we can live without this feature. E.g., ppolicy, sssvlv etc. all > just > create their own private arrays of per-conn structures. Sharing here will > require introducing another mutex. Right, I've fixed things differently. I note that other code (e.g. paged results) is write-accessing its state without mutex protection; although it is unlikely that more than one search operation use paged response concurrently, this is incorrect in principle. I'm closing this ITS. p.

1 0

Re: (ITS#6746) broken slapo-translucent failure handling
by hyc＠symas.com 04 Jan '11

04 Jan '11

h.b.furuseth(a)usit.uio.no wrote: > I've fixed it in HEAD, unless early errors in translucent_search() > should be ignored Patch looks OK, the remote server is authoritative so the first search must not fail. > or filter errors should NOT be ignored. Looks OK; as with any search if the filter doesn't match there should not be any entry returned. -- -- 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

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