openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

Re: (ITS#5859) back-hdb entrycache problem
by rhafer＠suse.de 17 Dec '08

17 Dec '08

This problem seems to be only present when using an empty suffix. I wasn't able to reproduce it with a non-empty suffix at least. It seems to be a problem with the idlcache. After setting "idlcachesize" to 0 the problem went a way for me. And yes, it seems to have been in the RE24 tree for a longer time already (2.4.12 was affected as well). -- Ralf

1 0

Re: (ITS#5856) adauth overlay contribution
by neil.dunbar＠hp.com 17 Dec '08

17 Dec '08

On Tue, 2008-12-16 at 14:52 +0000, Neil Dunbar wrote: > Andrew: > > One suggestion following a very quick scan of the code: I think it > > would be worth bringing the warning about turning off TLS checks > > into the manual page. > > Agreed. Done. The tarball is uploaded as adauth-20081217.tar.gz Neil -- SSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England

1 0

Re: (ITS#5863) assertion failed in ber_bvreplace_x() with translucent overlay
by quanah＠zimbra.com 16 Dec '08

16 Dec '08

--On Tuesday, December 16, 2008 3:20 PM +0000 guillaume.pujol(a)eds.com wrote: > I'm not sure if this crash is due to an incoherent configuration, or to an > interaction problem with the Active Directory backend. > In the former case, I think the server should output an error message when > started. In the later case, it is probably a bug. > > Please let me know if you need more specific information. Can you reproduce with OpenLDAP 2.4.13? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5864) slapadd trickle task slows down slapadd when using libdb-4.5
by rhafer＠suse.de 16 Dec '08

16 Dec '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: openSUSE 11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.233.197) Regardless of the recent slapadd fixes discussed on the -devel list (http://www.openldap.org/lists/openldap-devel/200811/msg00126.html), slapadd performance is still bad when linking against berkely-db 4.5.X, there seem to be problems with libdb-4.5's memp_trickle() function. IMO we should just disable the trickle_task when linking against libdb < 4.6.

1 0

(ITS#5863) assertion failed in ber_bvreplace_x() with translucent overlay
by guillaume.pujol＠eds.com 16 Dec '08

16 Dec '08

Full_Name: Guillaume Pujol Version: 2.4.11 (latest debian package) OS: Debian Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.251.11.120) Hello, I have an OpenLDAP test instance configured as a translucent proxy to an Active Directory server (the later running on W2k3). The relevant database configuration (from slapd.conf) is as follows: database hdb directory /var/lib/ldap-proxy suffix "dc=eds,dc=local" index objectClass eq overlay translucent uri ldap://192.168.65.130:389 lastmod off acl-bind bindmethod=simple binddn="CN=ldapsync,CN=Users,DC=EDS,DC=local" credentials="ldapsync" idassert-bind bindmethod=simple mode=self chase-referrals yes The server loads and runs fine with this configuration, as long as no one binds. The credentials for acl-bind are valid. When I connect to the server and bind with valid credentials, the server crashes with a SIG_ABRT due to an assertion failed (backtrace below). Steps to reproduce: root@debian:~# /etc/init.d/slapd start Starting OpenLDAP: slapd. root@debian:~# ps aux | grep slapd openldap 5978 0.2 2.0 25188 5364 ? Ssl 14:21 0:00 /usr/sbin/slapd -g openldap -u openldap -f /etc/ldap/slapd.conf root 5983 0.0 0.2 3144 760 pts/2 R+ 14:21 0:00 grep slapd root@debian:~# ldapsearch -H ldap://192.168.65.134 -x -b dc=eds,dc=local -D "cn=myuser,cn=Users,dc=eds,dc=local" -W -LL Enter LDAP Password: <input correct password here> ldap_result: Can't contact LDAP server (-1) root@debian:~# ps aux | grep slapd root 5970 0.0 0.2 3144 764 pts/2 S+ 14:20 0:00 grep slapd # TO MAKE SURE THE SERVER WORKS FINE, I TRY TO BIND WITH A WRONG PASSWORD: root@debian:~# /etc/init.d/slapd start Starting OpenLDAP: slapd. root@debian:~# ldapsearch -x -b dc=eds,dc=local -D "cn=myuser,cn=Users,dc=eds,dc=local" -W Enter LDAP Password: <input wrong password here> ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece root@debian:~# ps aux | grep slapd openldap 5982 0.2 2.0 25188 5364 ? Ssl 14:21 0:00 /usr/sbin/slapd -g openldap -u openldap -f /etc/ldap/slapd.conf root 5984 0.0 0.2 3144 760 pts/2 R+ 14:21 0:00 grep slapd The backtrace of the SIG_ABRT is as follows: #0 0xb7faf424 in __kernel_vsyscall () #1 0xb7bbb640 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb7bbd018 in abort () from /lib/i686/cmov/libc.so.6 #3 0xb7bb45be in __assert_fail () from /lib/i686/cmov/libc.so.6 #4 0xb7f62d3b in ber_bvreplace_x (dst=0x8b3d458, src=0xb6981d48, ctx=0x0) at /build/buildd/openldap-2.4.11/libraries/liblber/memory.c:700 #5 0xb7f62d6c in ber_bvreplace (dst=0x8b3d458, src=0xb6981d48) at /build/buildd/openldap-2.4.11/libraries/liblber/memory.c:715 #6 0xb77c78ff in ldap_back_dobind_int (lcp=0xb6981e78, op=0x8b3d018, rs=0xb6983148, sendok=22, retries=0, dolock=1) at /build/buildd/openldap-2.4.11/servers/slapd/back-ldap/bind.c:2211 #7 0xb77c2ecd in ldap_back_search (op=0x8b3d018, rs=0xb6983148) at /build/buildd/openldap-2.4.11/servers/slapd/back-ldap/search.c:166 #8 0xb77b65d2 in translucent_search (op=0x8b3d018, rs=0xb6983148) at /build/buildd/openldap-2.4.11/servers/slapd/overlays/translucent.c:976 #9 0x080db6c6 in overlay_op_walk (op=0x8b3d018, rs=0xb6983148, which=op_search, oi=0x8ae4028, on=0x8ae4128) at /build/buildd/openldap-2.4.11/servers/slapd/backover.c:636 #10 0x080dc205 in over_op_func (op=0x8b3d018, rs=0xb6983148, which=op_search) at /build/buildd/openldap-2.4.11/servers/slapd/backover.c:698 #11 0x08078a23 in fe_op_search (op=0x8b3d018, rs=0xb6983148) at /build/buildd/openldap-2.4.11/servers/slapd/search.c:366 #12 0x08079290 in do_search (op=0x8b3d018, rs=0xb6983148) at /build/buildd/openldap-2.4.11/servers/slapd/search.c:217 #13 0x08076436 in connection_operation (ctx=0xb6983238, arg_v=0x8b3d018) at /build/buildd/openldap-2.4.11/servers/slapd/connection.c:1084 #14 0x08076eb7 in connection_read_thread (ctx=0xb6983238, argv=0x13) at /build/buildd/openldap-2.4.11/servers/slapd/connection.c:1211 #15 0xb7f73fb8 in ldap_int_thread_pool_wrapper (xpool=0x8ab46f8) at /build/buildd/openldap-2.4.11/libraries/libldap_r/tpool.c:663 #16 0xb7cf14c0 in start_thread () from /lib/i686/cmov/libpthread.so.0 #17 0xb7c7061e in clone () from /lib/i686/cmov/libc.so.6 So it looks like this assert fails for some reason: at /build/buildd/openldap-2.4.11/libraries/liblber/memory.c:700 assert( !BER_BVISNULL( src ) ); Reproducible: always with the configuration above. If I remove "mode=self" in the configuration above, the server loads and runs fine (no crash when binding), but I can't search anything in the database: root@debian:~# ldapsearch -LL -x -b dc=eds,dc=local -D "cn=myuser,cn=Users,dc=eds,dc=local" -W Enter LDAP Password: <correct password> result: 1 Operations error text: 00000000: LdapErr: DSID-0C090627, comment: In order to perform this ope ration a successful bind must be completed on the connection., data 0, vece I'm not sure if this crash is due to an incoherent configuration, or to an interaction problem with the Active Directory backend. In the former case, I think the server should output an error message when started. In the later case, it is probably a bug. Please let me know if you need more specific information. Regards,

1 0

Re: (ITS#5856) adauth overlay contribution
by neil.dunbar＠hp.com 16 Dec '08

16 Dec '08

Andrew: > One suggestion following a very quick scan of the code: I think it > would be worth bringing the warning about turning off TLS checks > into the manual page. Agreed. Done. > In particular, there is no reason for this > to be AD-specific and it should be easy to adapt it to authenticate > against any [collection of] remote LDAP servers. Actually, it may not be AD specific as is. If you define default_domain to be some rubbish, and default_realm to be the remote AD server, then everything else (including the remote bind DN) can be fetched from the DIT. But I haven't tried this. But what wouldn't get passed back is any information flowing from password controls - and that's an annoyance, which is why I didn't generalise the code (and because HP had no business need for that approach anyway). Cheers, Neil -- SSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 16 Dec '08

16 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-25943-1229438597-0001-2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I can also NOT reproduce this with OpenLDAP 2.3.43 on Solaris 10. So this seems to be a regression in OpenLDAP 2.4.x For the moment I'm sticking with 2.3, though it still doens't solve my problem of hashing passwords on change (exop's don't seem to be triggered) Mark --=_server11-25943-1229438597-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklHvocACgkQb6urvDV9IXhY5ACgkuKEb8H03RbTZWDAthb/n10Z d5AAoLsPNEL3UONsg0oG90coRtIT0ktq =T44A -----END PGP SIGNATURE----- --=_server11-25943-1229438597-0001-2--

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 16 Dec '08

16 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-25317-1229436747-0001-2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Also tested my config on OpenLDAP 2.3.27 on CentOS 5 (i386) with packages from: http://dev.centos.org/centos/5/testing/i386/RPMS/ This hasn't resulted in a segfault yet.=20 I will try version 2.3.27 on Solaris now. --=_server11-25317-1229436747-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklHt0gACgkQb6urvDV9IXjtlwCeJ8q/q2q+kX48VSoWCyaAfEE5 TIIAoKHn1k0gkXrxqZjiCekBQC3OMR9D =+iFS -----END PGP SIGNATURE----- --=_server11-25317-1229436747-0001-2--

1 0

(ITS#5862) Assert control ignored on non-database entries
by h.b.furuseth＠usit.uio.no 16 Dec '08

16 Dec '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd does not apply the Assert control to non-database entries (at least the root and subschema entries), yet does not reject a critical control either. I have not explored the magnitutde of the problem: Where the control can get ignored, and which other controls are ignored. $ ldapsearch -LLLx -e\!assert='(objectClass=person)' -b "" -s base dn: objectClass: top objectClass: OpenLDAProotDSE $ ldapsearch -LLLx -e\!assert='(objectClass=person)' -b cn=subschema -s base dn: cn=Subschema objectClass: top objectClass: subentry objectClass: subschema objectClass: extensibleObject cn: Subschema -b "" -s sub does apply the control with database bdb + suffix "". Don't know about back-sql. However I imagine it varies how careful backends "" are about generating the root DSE when suffix == "" so controls can be applied to it. Might need a backend flag which says whether the backend does this, and reject the critical controls with unwillingToPerform if this flag is not set.

1 0

(ITS#5861) Assert control on Add request fails
by h.b.furuseth＠usit.uio.no 16 Dec '08

16 Dec '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard RFC 4528 says the Assert control is appropriate for Add. Slapd disagrees: $ ldapadd -xhlocalhost:3890 -e\!assert='(objectClass=organization)' <test.ldif adding new entry "o=test" ldap_add: Critical extension is unavailable (12) additional info: critical extension is unavailable back-bdb and back-sql do not apply the assert control to Add. The message comes from slapd/controls.c. Don't fix that before fixing Add in the backends, otherwise critical controls can be ignored. Another strangeness: overlays/syncprov.c applies the Assert control to Compare but not other operations. I don't know why, there are no comments about it.

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