openldap-bugs January 2009

openldap-bugs@openldap.org

50 participants
201 discussions

(ITS#5913) supportedSASLMechanisms EXTERNAL not Work
by jarbas.peixoto＠gmail.com 29 Jan '09

29 Jan '09

Full_Name: Jarbas Peixoto Junior Version: 2.4.11 OS: Debian Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.152.43.195) I have two servers: * Server A: Debian Etch - Works Fine * Server B: Debian Lenny - Do not Works supportedSASLMechanisms EXTERNAL In Server A I have: # ldapsearch -v -H ldap://server-Etch -b "" -LLL -s base supportedSASLMechanisms -ZZ ldap_initialize( ldap://server-Etch ) SASL/EXTERNAL authentication started SASL username: emailAddress=jarbas.peixoto(a)previdencia.gov.br,CN=jarbas.peixoto,OU=DATAPREV,O=Previdencia Social,L=Campo Grande,ST=Mato Grosso do Sul,C=BR SASL SSF: 0 filter: (objectclass=*) requesting: supportedSASLMechanisms dn: supportedSASLMechanisms: PLAIN supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: NTLM supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: EXTERNAL In Server B I have: # ldapsearch -v -H ldap://server-Lenny -b "" -LLL -s base supportedSASLMechanisms -ZZ ldap_initialize( ldap://server-Lenny:389/??base ) ldap_start_tls: Connect error (-11 # ldapsearch -v -H ldap://server-Lenny -b "" -LLL -s base supportedSASLMechanisms -ZZ -d 1 ldap_url_parse_ext(ldap://server-Lenny) ldap_create ldap_url_parse_ext(ldap://server-Lenny:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP server-Lenny:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.82.0.234:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x9d73280 msgid 1 wait4msg ld 0x9d73280 msgid 1 (infinite timeout) wait4msg continue ld 0x9d73280 msgid 1 all 1 ** ld 0x9d73280 Connections: * host: www-mmldap port: 389 (default) refcnt: 2 status: Connected last used: Thu Jan 29 18:17:22 2009 ** ld 0x9d73280 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x9d73280 request count 1 (abandoned 0) ** ld 0x9d73280 Response Queue: Empty ld 0x9d73280 response count 0 ldap_chkResponseList ld 0x9d73280 msgid 1 all 1 ldap_chkResponseList returns ld 0x9d73280 NULL ldap_int_select read1msg: ld 0x9d73280 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x9d73280 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x9d73280 0 new referrals read1msg: mark request completed, ld 0x9d73280 msgid 1 request done: ld 0x9d73280 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_start_tls: Connect error (-11) In the /var/log/syslog I have: Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 fd=21 ACCEPT from IP=10.82.0.234:50441 (IP=0.0.0.0:389) Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 STARTTLS Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 RESULT oid= err=0 text= Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 fd=21 closed (TLS negotiation failure) This is very important for use openldap with user certificates. Anybody have a help for me? Tanks!

1 0

Re: (ITS#5912) Meta modify increment feature
by ando＠sys-net.it 29 Jan '09

29 Jan '09

Fixed in HEAD; please test. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5912) Meta modify increment feature
by ando＠sys-net.it 29 Jan '09

29 Jan '09

jorge.nevado(a)ericsson.com wrote: > Full_Name: Jorge Nevado > Version: 2.4.12 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.7) > > > We are trying to send an increment modify operation on an entry. This request > has to be proxied using the meta to a backend we have developed. When we send > the operation directly to the backend it works without any problem. But when we > have to pass through the meta backend we receive the following error: > > ldapmodify -x -H ldap://localhost:9090 -D "cn=manager,dc=operator,dc=com" -w > manager -f ldif/nam.ldif modifying entry > "appName=CsPs,subsId=10000000000000000000000000000000,ou=subscribers,dc=operator,dc=com" > ldap_modify: Server is unwilling to perform (53) > additional info: modify/increment not supported in context > > However we see that the operation has been performed and the attribute > incremented. The same problem occurs in back-ldap. The frontend is sending the error message, but it allows the operation to continue, and eventually it succeeds. I'm fixing it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: slapo-unique man page misleading (ITS#5908)
by ghenry＠suretecsystems.com 29 Jan '09

29 Jan '09

----- hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: > > quanah(a)zimbra.com wrote: > >> --On January 28, 2009 10:39:41 PM +0000 Magne.Land(a)citrix.com > wrote: > >> > >>> Hi, > >>> Please see this thread for background info: > >>> > http://www.openldap.org/lists/openldap-software/200901/msg00112.html > >>> > >>> To me, something is either guaranteed or not. And I think > "enforce" means > >>> something that is guaranteed. In this case, the uniqueness is not > >>> guaranteed, therefore it is not enforced. > >> Set up slapo-accesslog on your master. Then uniqueness is > guaranteed. > > > > Are you sure about this? I didn't look in detail to the code, so I > > can't tell whether serializing writes that way will cause the > desired > > behavior, since slapo-unique is using internal writes. > > Huh? slapo-unique only does internal searches. The writes are all user > ops, > and accesslog will serialize all of them. So, where does this leave us? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: (ITS#5909) stack overflow in tavl_delete (libraries/liblutil/tavl.c)?
by h.b.furuseth＠usit.uio.no 29 Jan '09

29 Jan '09

ulrich.windl(a)rz.uni-regensburg.de writes: > To make a long discussion short, you cold add a comment regarding the > use of "8". The 8 should be CHAR_BIT. /* Maximum tree depth this host's address space could support */ #define MAX_TREE_DEPTH (sizeof(void *) * CHAR_BIT) -- Hallvard

1 0

(ITS#5912) Meta modify increment feature
by jorge.nevado＠ericsson.com 29 Jan '09

29 Jan '09

Full_Name: Jorge Nevado Version: 2.4.12 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.7) We are trying to send an increment modify operation on an entry. This request has to be proxied using the meta to a backend we have developed. When we send the operation directly to the backend it works without any problem. But when we have to pass through the meta backend we receive the following error: ldapmodify -x -H ldap://localhost:9090 -D "cn=manager,dc=operator,dc=com" -w manager -f ldif/nam.ldif modifying entry "appName=CsPs,subsId=10000000000000000000000000000000,ou=subscribers,dc=operator,dc=com" ldap_modify: Server is unwilling to perform (53) additional info: modify/increment not supported in context However we see that the operation has been performed and the attribute incremented. The request we are sending is the following: dn: msisdn=910000000000000,dc=msisdn,ou=identities,dc=operator,dc=com changetype:modify increment: usageCnt usageCnt:4

1 0

Re: slapo-unique man page misleading (ITS#5908)
by hyc＠symas.com 29 Jan '09

29 Jan '09

ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: >> --On January 28, 2009 10:39:41 PM +0000 Magne.Land(a)citrix.com wrote: >> >>> Hi, >>> Please see this thread for background info: >>> http://www.openldap.org/lists/openldap-software/200901/msg00112.html >>> >>> To me, something is either guaranteed or not. And I think "enforce" means >>> something that is guaranteed. In this case, the uniqueness is not >>> guaranteed, therefore it is not enforced. >> Set up slapo-accesslog on your master. Then uniqueness is guaranteed. > > Are you sure about this? I didn't look in detail to the code, so I > can't tell whether serializing writes that way will cause the desired > behavior, since slapo-unique is using internal writes. Huh? slapo-unique only does internal searches. The writes are all user ops, and accesslog will serialize all of them. > As Gavin says,. > if this is the case then it should be at least documented, and not only > in slapo-unique, but also for any overlay/module that does internal writes. -- -- 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: slapo-unique man page misleading (ITS#5908)
by ando＠sys-net.it 29 Jan '09

29 Jan '09

quanah(a)zimbra.com wrote: > --On January 28, 2009 10:39:41 PM +0000 Magne.Land(a)citrix.com wrote: > >> Hi, >> Please see this thread for background info: >> http://www.openldap.org/lists/openldap-software/200901/msg00112.html >> >> To me, something is either guaranteed or not. And I think "enforce" means >> something that is guaranteed. In this case, the uniqueness is not >> guaranteed, therefore it is not enforced. > > Set up slapo-accesslog on your master. Then uniqueness is guaranteed. Are you sure about this? I didn't look in detail to the code, so I can't tell whether serializing writes that way will cause the desired behavior, since slapo-unique is using internal writes. As Gavin says,. if this is the case then it should be at least documented, and not only in slapo-unique, but also for any overlay/module that does internal writes. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: slapo-unique man page misleading (ITS#5908)
by ghenry＠suretecsystems.com 29 Jan '09

29 Jan '09

----- quanah(a)zimbra.com wrote: > --On January 28, 2009 10:39:41 PM +0000 Magne.Land(a)citrix.com wrote: > > > Hi, > > Please see this thread for background info: > > > http://www.openldap.org/lists/openldap-software/200901/msg00112.html > > > > To me, something is either guaranteed or not. And I think "enforce" > means > > something that is guaranteed. In this case, the uniqueness is not > > guaranteed, therefore it is not enforced. > > Set up slapo-accesslog on your master. Then uniqueness is > guaranteed. We don't document this requirement in slapo-unique.5 though. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: (ITS#5909) stack overflow in tavl_delete (libraries/liblutil/tavl.c)?
by ulrich.windl＠rz.uni-regensburg.de 29 Jan '09

29 Jan '09

On 29 Jan 2009 at 2:21, Howard Chu wrote: > Hardcoding arbitrary limits in portable code is stupid. ("No one will ever > need more than 640K...") What may seem (im)practical to you today may be > commonplace tomorrow. This code will be maintenance-free no matter what class > of machine it's built on, forever. That's *excellent* programming. Howard, my proposals were related to the virtual address space, and the specific value for 64 bit was assuming that no more than 800GB of tree nodes are allocated. Your settings relate the depth of the tree to the width of a pointer multiplied by a hardcoded value without further explanation. > > There is no bug here, this ITS is closed. To make a long discussion short, you cold add a comment regarding the use of "8". Regards, Ulrich > > Ulrich Windl wrote: > > On 28 Jan 2009 at 13:06, Howard Chu wrote: > > > >> Ulrich.Windl(a)rz.uni-regensburg.de wrote: > >>> Full_Name: Ulrich Windl > >>> Version: 2.4.11 > >>> OS: Linux > >>> URL: ftp://ftp.openldap.org/incoming/ > >>> Submission from: (NULL) (132.199.156.178) > >>> > >>> > >>> Looking for a threaded AVL tree implementation that is supposed to work, I found > >>> libraries/liblutil/tavl.c in openLDAP. I'm no expert on threaded AVL trees, but > >>> there's thing that worries me: > >>> tavl_delete uses two stacks (pptr, pdir) with a size of 8 elements on the > >>> routine' stack. While locating the element to delete, it pushes the parent node > >>> onto the stack. > >> You're misreading the code. The stack is 8*sizeof(void *) which means 32 > >> elements deep on a 32 bit machine, and 64 deep on a 64 bit machine. There is > >> no possibility of overflow now or for several years to come. > > > > OK! I was confused by the terrible programming style at that point: as the array > > elements are of the proper type (and not bytes), there is no need for a sizeof > > here: I see no reason why the depth of the tree to be allowed should depend on the > > length of a pointer, maning: If you want 32, why don't you write 32? So the worst > > case stack depth would be something like "log2(2^32/(sizeof(void *) * 5))" ("5" > > being 2 links + 2 threading marks + 1 data pointer), something near 32-5 == 27 > > (for 32-bit machines) and 64-6 == 58. Practically the latter could be safely > > reduced to a value around 42 IMHO. > > -- > -- 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:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2009