openldap-bugs

openldap-bugs@openldap.org

1 participants
21542 discussions

(ITS#8494) doc: Rename 'TLSEphemeralDHParamFile' to 'TLSDHParamFile'
by georg＠riseup.net 08 Sep '16

08 Sep '16

Full_Name: Georg Faerber Version: 2.4 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.64.110.191) http://www.openldap.org/doc/admin24/tls.html mentions directive 'TLSEphemeralDHParamFile' whereas slapd.conf(5) mentions 'TLSDHParamFile'. (See [1] as well). [1] http://www.openldap.org/lists/openldap-technical/201309/msg00094.html

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 07 Sep '16

07 Sep '16

Actually, ignore me this is still connecting when it should fail. Don't close. ;)

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 07 Sep '16

07 Sep '16

This seems to have been resolved at some point in the past in one of the updates: now functions as expected. Fine to close from my perspective.

1 0

Re: (ITS#8493) Under heavy modrdn load, masters desync
by quanah＠zimbra.com 03 Sep '16

03 Sep '16

--On Saturday, September 03, 2016 4:51 PM +0000 quanah(a)zimbra.com wrote: > --On Saturday, September 03, 2016 6:15 AM +0000 quanah(a)openldap.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.44+ITS8432 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.52.177) >> >> >> Trying to reproduce another ITS, I discovered a new bug. When doing >> MODRDN ops on one master, the other master keeps going out of sync. >> Specifically: >> >> Sep 3 01:12:17 zre-ldap002 slapd[29206]: syncrepl_message_to_op: rid=100 >> be_modrdn uid=user.924,ou=people,dc=zre-ldap002,dc=eng,dc=zimbra,dc=com >> (32) Sep 3 01:12:17 zre-ldap002 slapd[29206]: do_syncrep2: rid=100 >> delta-sync lost sync on (reqStart=20160903051215.747829Z,cn=accesslog), >> switching to REFRESH > > > Note that this master also has a replica. The replica never rejected a > single one of these MODRDNs coming from this master. Which means that > either: > > a) The data on the master spontaneously corrupted at some point > > or > > b) The master wrote the MODRDNs to the accesslog, which the replica > picked up, but did not itself make the MODRDN changes to its database. > > In the end, of the 50,000 MODRDNs it was processing, it threw an error 32 > for 441 of them. After the master that was not accepting direct writes re-sync'd with the master accepting writes, it still had 403/50000 entries wrong. So did its replica. So the master isn't writing the changes to the accesslog. So it's option c. The master rejects a valid op, never sync's correctly, and in the end 2/3rds of my servers have invalid databases. I see zero indication that using a sessionlog works around <http://www.openldap.org/its/index.cgi/?findid=8125> at all. I still end up with missed entries even with everything *in* the sessionlog. --Quanah -- Quanah Gibson-Mount

1 0

Re: (ITS#8493) Under heavy modrdn load, masters desync
by quanah＠zimbra.com 03 Sep '16

03 Sep '16

--On Saturday, September 03, 2016 6:15 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44+ITS8432 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) > > > Trying to reproduce another ITS, I discovered a new bug. When doing > MODRDN ops on one master, the other master keeps going out of sync. > Specifically: > > Sep 3 01:12:17 zre-ldap002 slapd[29206]: syncrepl_message_to_op: rid=100 > be_modrdn uid=user.924,ou=people,dc=zre-ldap002,dc=eng,dc=zimbra,dc=com > (32) Sep 3 01:12:17 zre-ldap002 slapd[29206]: do_syncrep2: rid=100 > delta-sync lost sync on (reqStart=20160903051215.747829Z,cn=accesslog), > switching to REFRESH Note that this master also has a replica. The replica never rejected a single one of these MODRDNs coming from this master. Which means that either: a) The data on the master spontaneously corrupted at some point or b) The master wrote the MODRDNs to the accesslog, which the replica picked up, but did not itself make the MODRDN changes to its database. In the end, of the 50,000 MODRDNs it was processing, it threw an error 32 for 441 of them. --Quanah -- Quanah Gibson-Mount

1 0

Re: (ITS#8486) Syncprov sessionlog is inefficient, kills perf
by quanah＠zimbra.com 02 Sep '16

02 Sep '16

--On Monday, August 29, 2016 9:16 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) In doing testing for ITS#8491, I encountered this problem in my lab. Any time a single replica is parsing the session log, all other operations on the server come to a complete halt. I.e., slapd does *nothing* other than handle the sessionlog query. This seems like a fatal problem. --Quanah -- Quanah Gibson-Mount

1 0

(ITS#8493) Under heavy modrdn load, masters desync
by quanah＠openldap.org 02 Sep '16

02 Sep '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44+ITS8432 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) Trying to reproduce another ITS, I discovered a new bug. When doing MODRDN ops on one master, the other master keeps going out of sync. Specifically: Sep 3 01:12:17 zre-ldap002 slapd[29206]: syncrepl_message_to_op: rid=100 be_modrdn uid=user.924,ou=people,dc=zre-ldap002,dc=eng,dc=zimbra,dc=com (32) Sep 3 01:12:17 zre-ldap002 slapd[29206]: do_syncrep2: rid=100 delta-sync lost sync on (reqStart=20160903051215.747829Z,cn=accesslog), switching to REFRESH

1 0

RE: (ITS#8492) signal 11 in ldap_new_connection
by quanah＠zimbra.com 02 Sep '16

02 Sep '16

--On Friday, September 02, 2016 7:35 AM +0000 htjain(a)sandvine.com wrote: > After some more debugging looks like ld->ldc->ldc_options.ldo_defludp > varia= ble is causing this issue, its null when its passed to > ldap_new_connection. How does it populated? Please confirm your encounter the issue with a current release. 2.4.40 and 2.4.41 both had significant issues. --Quanah -- Quanah Gibson-Mount

1 0

RE: (ITS#8492) signal 11 in ldap_new_connection
by htjain＠sandvine.com 01 Sep '16

01 Sep '16

After some more debugging looks like ld->ldc->ldc_options.ldo_defludp varia= ble is causing this issue, its null when its passed to ldap_new_connection. How does it populated? (gdb) p ld->ldc->ldc_options $13 =3D {ldo_valid =3D 255, ldo_debug =3D 0, ldo_version =3D 3, ldo_deref = =3D 0, ldo_timelimit =3D 0, ldo_sizelimit =3D 0, ldo_tm_api =3D {tv_sec =3D= -1, tv_usec =3D 0}, ldo_tm_net =3D {tv_sec =3D 5, tv_usec =3D 0}, ldo_defl= udp =3D 0x0, ldo_defport =3D 389, ldo_defbase =3D 0x0, ldo_defbinddn =3D 0x0, ldo_keepalive_idle =3D 0, ldo= _keepalive_probes =3D 0, ldo_keepalive_interval =3D 0, ldo_refhoplimit =3D = 5, ldo_sctrls =3D 0x0, ldo_cctrls =3D 0x0, ldo_rebind_proc =3D 0x0, ldo_reb= ind_params =3D 0x0, ldo_nextref_proc =3D 0x0, ldo_nextref_params =3D 0x0, ldo_urllist_proc = =3D 0x0, ldo_urllist_params =3D 0x0, ldo_conn_cbs =3D 0x0, ldo_booleans =3D= 34, ldo_peer =3D 0x0, ldo_cldapdn =3D 0x0, ldo_is_udp =3D 0, ldo_tls_ctx = =3D 0x0, ldo_tls_connect_cb =3D 0x0, ldo_tls_connect_arg =3D 0x0, ldo_tls_info =3D= {lt_certfile =3D 0x0, lt_keyfile =3D 0x0, lt_dhfile =3D 0x0, lt_cacertfile= =3D 0x0, lt_cacertdir =3D 0x0, lt_ciphersuite =3D 0x0, lt_crlfile =3D 0x0,= lt_randfile =3D 0x0, lt_protocol_min =3D 0}, ldo_tls_mode =3D 0, ldo_tls_require_cert =3D 2,= ldo_tls_impl =3D 0, ldo_tls_crlcheck =3D 0, ldo_def_sasl_mech =3D 0x0, ldo= _def_sasl_realm =3D 0x0, ldo_def_sasl_authcid =3D 0x0, ldo_def_sasl_authzid= =3D 0x0, ldo_sasl_secprops =3D {min_ssf =3D 0, max_ssf =3D 2147483647, maxbufsize = =3D 16777215, security_flags =3D 17, property_names =3D 0x0, property_value= s =3D 0x0}} (gdb) p ld->ldc->ldc_options.ldo_defludp $14 =3D (LDAPURLDesc *) 0x0 -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org]=20 Sent: Friday, September 2, 2016 11:50 AM To: Hemant Jain Subject: Re: (ITS#8492) signal 11 in ldap_new_connection *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report = has been assigned the tracking number ITS#8492. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunte= ers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue repo= rt, you may do so by replying to this message. Note that any mail sent to = openldap-its(a)openldap.org with (ITS#8492) in the subject will automatically= be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#8492) You may follow the progress of this report by loading the following URL in = a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D8492 Please remember to retain your issue tracking number (ITS#8492) on any furt= her messages you send to us regarding this report. If you don't then you'l= l just waste our time and yours because we won't be able to properly track = the report. Please note that the Issue Tracking System is not intended to be used to se= ek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#8492) signal 11 in ldap_new_connection
by htjain＠sandvine.com 01 Sep '16

01 Sep '16

Full_Name: hemant jain Version: openldap-2.4.40-8 OS: RHEL 7.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.63.202.166) Hi, We are facing a strange core dump in ldap_new_connection function while trying to bind a stopped Openldap server. following is the stack trace: #0 0x00007f9336898f53 in ldap_new_connection (ld=ld@entry=0x7f931f43cd60, srvlist=srvlist@entry=0x7f931f48b298, use_ldsb=use_ldsb@entry=1, connect=connect@entry=1, bind=bind@entry=0x0, m_req=m_req@entry=0, m_res=m_res@entry=0) at request.c:481 #1 0x00007f933688530f in ldap_open_defconn (ld=ld@entry=0x7f931f43cd60) at open.c:41 #2 0x00007f933689a248 in ldap_send_initial_request (ld=ld@entry=0x7f931f43cd60, msgtype=msgtype@entry=96, dn=dn@entry=0x7f931f827718 "cn=Manager,dc=test,dc=com", ber=ber@entry=0x7f931f457150, msgid=msgid@entry=1) at request.c:130 #3 0x00007f933688f178 in ldap_sasl_bind (ld=0x7f931f43cd60, dn=0x7f931f827718 "cn=Manager,dc=test,dc=com", mechanism=<optimized out>, cred=0x7f931f4296b0, sctrls=0x0, cctrls=<optimized out>, msgidp=0x7f92243ed8dc) at sasl.c:148 #4 0x00007f9340f571da in ldap::Connection::Bind (this=this@entry=0x7f931c043478, msg_id=@0x7f92243ed98c: -1) at support/ldapconnection.cpp I have installed corresponding debug rpm for Openldap library. Following the source info. core dump is coming at line 481 of request.c file.A%A for ( srvp = srvlist; *srvp != NULL; srvp = &(*srvp)->lud_next ) // Here srvp is NULL so *srvp dumping core. if ( connect ) { LDAPURLDesc **srvp, *srv = NULL; async = LDAP_BOOL_GET( &ld->ld_options, LDAP_BOOL_CONNECT_ASYNC ); for ( srvp = srvlist; *srvp != NULL; srvp = &(*srvp)->lud_next ) { int rc; rc = ldap_int_open_connection( ld, lc, *srvp, async ); if ( rc != -1 ) { srv = *srvp; if ( ld->ld_urllist_proc && ( !async || rc != -2 ) ) { ld->ld_urllist_proc( ld, srvlist, srvp, ld->ld_urllist_params ); } break; } } Any idea how to fix it ?

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs