openldap-bugs

openldap-bugs@openldap.org

20960 discussions

(ITS#6340) What should I do it well?
by sunjian.xa＠gmail.com 20 Oct '09

20 Oct '09

Full_Name: sunjian Version: 2.4.16 OS: CentOS 4.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.114.169.6) hello, I am developing a ldap client program with kerberos V5 authentication under CentOS 4.7. Heimdal 0.7.2 is used for KDC, and OpenLDAP 2.4.16 for heimdal's backend. Cyrus SASL 2.1.22, OpenSSL 0.9.8b and BerkeleyDB 4.4.20 are also used. I compile OpenLDAP as follow, $env ol_enable_kbind=yes ./configure --prefix=/usr --localstatedir=/var/openldap --enable-syslog --enable-local --with-cyrus-sasl --with-threads --with-tls --with-kerberos --enable-crypt --enable-lmpasswd --enable-spasswd --enable-modules --enable-hdb --enable-ldap --enable-monitor --enable-dyngroup --enable-proxycache $make depend $make make[3]: Entering directory `/home/xk/download/openldap-2.3.24/servers/slapd/back-bdb' /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -c bind.c cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -c bind.c -o bind.o bind.c: In function `bdb_bind': bind.c:154: error: syntax error before "goto" bind.c:161: error: syntax error before "goto" bind.c:176: error: syntax error before "goto" make[3]: *** [bind.lo] Error 1 make[3]: Leaving directory `/home/xk/download/openldap-2.3.24/servers/slapd/back-bdb' make[2]: *** [.backend] Error 1 make[2]: Leaving directory `/home/xk/download/openldap-2.3.24/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/xk/download/openldap-2.3.24/servers' make: *** [all-common] Error 1 Some one else told me that compiled with kbind, OpenLDAP should be patched and autoconf redone. Is that true? How to do in detail? If no kbind.o support, I have established the whole enviroment successfully. And the system works well. But I have to develop client program myself, so I need function ldap_kerberos_bind_s whose symbol included in kbind.o, then error occurs. Thanks.

1 0

Re: (ITS#6338) dnParent(x, x) can remove \0-termination
by masarati＠aero.polimi.it 20 Oct '09

20 Oct '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > This: > struct berval x = BER_BVC("cn=foo"); > dnParent(x, x); > keeps x.bv_val pointing at "cn=foo" instead of at the \0 > behind it. bv_len is correctly set to 0 though. Could be sort of intentional. As far as I remember, dnParent() is supposed to leave the second argument untouched, as it is often used on read-only data. Probably, the most appropriate fix consists in passing a temporary as the first argument. p.

1 0

Re: (ITS#6327) ldapsearch hangs
by quanah＠zimbra.com 20 Oct '09

20 Oct '09

--On Monday, October 19, 2009 3:46 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > This problem is also seen with Net::LDAPapi perl module, so it is library > rather than tool specific. It seems to be SASL specific as well (Stanford uses GSSAPI binds). I modified one of the problematic servers to have access to * by * read as its only ACL, and then did two searches. One using SASL/GSSAPI and one using anonymous query. The anonymous query succeeded across multiple runs. The SASL/GSSAPI query failed to complete. This was with a 2.4.19 ldapsearch binary against a remote 2.4.19 slapd. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6327) ldapsearch hangs
by quanah＠zimbra.com 20 Oct '09

20 Oct '09

Doing more investigation of this ITS reveals it appears to be related specifically to the version of ldapsearch used, and whether or not the connection actually goes over the network. Specifically, the result I see is: ldap_chkResponseList ld 0x510190 msgid -1 all 0 ldap_chkResponseList returns ld 0x510190 NULL ldap_int_select read1msg: ld 0x510190 msgid -1 all 0 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 52 ...R sasl_read: want=82, got=39 0000: 05 04 07 ff 00 00 00 1c 00 00 00 00 9d cb c2 05 ................ 0010: 43 a1 60 68 a0 f7 33 da d1 37 2f d8 21 4a 75 87 C.`h..3..7/.!Ju. 0020: b1 d8 73 41 ea 20 6b ..sA. k Working search shows: ldap_chkResponseList ld 2f798 msgid -1 all 0 ldap_chkResponseList returns ld 2f798 NULL ldap_int_select read1msg: ld 2f798 msgid -1 all 0 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 52 ...R sasl_read: want=82, got=82 0000: 05 04 07 ff 00 00 00 1c 00 00 00 00 6b be 1b 98 ............k... 0010: 17 5f 4a 09 70 15 23 cc 32 9f 71 6f eb 6e d2 66 ._J.p.#.2.qo.n.f 0020: b1 9a 56 61 4b 0a 64 83 ec a3 95 27 7d 07 87 5c ..VaK.d....'}..\ 0030: aa 37 26 a6 43 23 98 ab 60 e0 35 3b 7a f6 89 c2 .7&.C#..`.5;z... 0040: ca 7a 47 ec c2 0a 28 63 50 a8 16 da ae 55 fd 11 .zG...(cP....U.. 0050: ab 15 .. at which point it hangs. I've tried the following things: ldapsearch version 2.3.13 from a Solaris box. Searching with this version of ldapsearch never hangs, regardless of host location (remote machine room in Livermore, or local stanford machine room). ldapsearch version 2.4.11 from a linux box to ldap1 (2.4.19 server) hangs. These two boxes are in different locations/networks. ldapsearch 2.3.35 from ldap2 to ldap1 (2.4.19 server) hangs. These two boxes are on the same switch on the same vlan in the same building. ldapsearch 2.4.19 from ldap1 to ldap2 (2.3.35 server) does *not* hang. These two boxes are on the same switch on the same vlan in the same building. ldapsearch 2.4.19 from ldap1 to ldap-liv1 (2.4.19 server) hangs. So does the reverse direction. These two boxes are in very different locations. This problem is also seen with Net::LDAPapi perl module, so it is library rather than tool specific. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by quanah＠zimbra.com 20 Oct '09

20 Oct '09

--On Monday, October 19, 2009 10:32 PM +0000 openldap-its(a)OpenLDAP.org wrote: s/exist/exit --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6339) ldapsearch -V doesn't exist after version info
by quanah＠zimbra.com 20 Oct '09

20 Oct '09

Full_Name: Quanah Gibson-Mount Version: 2.4.19 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Executing ldapsearch -V to get the version information correctly prints it, but then proceeds to execute a search.

1 0

(ITS#6332)
by l.mierzwa＠gmail.com 20 Oct '09

20 Oct '09

Using accesslog overlay fixed my issues, without that not every change on=20 master is picked up by slaves. =C5=81ukasz

1 0

(ITS#6338) dnParent(x, x) can remove \0-termination
by h.b.furuseth＠usit.uio.no 19 Oct '09

19 Oct '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard This: struct berval x = BER_BVC("cn=foo"); dnParent(x, x); keeps x.bv_val pointing at "cn=foo" instead of at the \0 behind it. bv_len is correctly set to 0 though. Fixing.

1 0

Re: (ITS#6334) hang during ldapmodify
by rein＠OpenLDAP.org 19 Oct '09

19 Oct '09

mkd(a)cs.brown.edu wrote: > Let me know if there is anything else I can provide. Can you verify that the entire modify operation actually reaches the server? There is no sign of it being active in the stack trace, nor does the debug output show anything related to it, so I'm wondering if there is some network equipment between your client and server that causes too big requests to be dropped. slapd will also drop the connection if it receives too big requests, but given the data you provide you should be way below the default sockbuf_max_incomping_auth value. Please provide a "-d 271" output from slapd, it should be much more than the log you sent earlier. Your logs looks like syslog logs, while the debug output goes to stderr. Note: This log includes the content of the entire packets sent to/from the server, so you may wish to remove the output related to the bind requests. Rein

1 0

ITS#6337
by masarati＠aero.polimi.it 19 Oct '09

19 Oct '09

What seems to happen is that bind's response is sent outside the backend, by the frontend itself. As a consequence, back-relay's callback structure, which is located on the stack, is dangling at the moment it is used. 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