openldap-bugs November 2015

openldap-bugs@openldap.org

25 participants
61 discussions

Re: (ITS#8307) startup failed with DDS enabled
by ryan＠openldap.org 12 Nov '15

12 Nov '15

Hello Christian, On Thu, Nov 12, 2015 at 12:54:09PM +0000, boesch(a)fhv.at wrote: >I installed OpenLDAP 2.4.42, enabled these overlays on the mdb database: >olcOverlay={0}syncprov.ldif >olcOverlay={1}dds.ldif >olcOverlay={2}accesslog.ldif >olcOverlay={3}unique.ldif >olcOverlay={4}ppolicy.ldif >olcOverlay={5}refint.ldif >olcOverlay={6}memberof.ldif >olcOverlay={7}dynlist.ldif >started, everything is fine. > >Then I added an empty base tree: >dn: dc=example,dc=net >objectClass: dcObject >objectClass: organization >o: ORG >dc: example > >dn: cn=admin,dc=example,dc=net >objectClass: organizationalRole >cn: LDAP Admin >cn: admin > >dn: o=org,dc=example,dc=net >o: ORG >objectClass: organization >objectClass: top I tried to reproduce your problem under openldap 2.4.42 on Linux (Debian), using the attached config and the data LDIF you provided, but didn't observe any problems. Would you please provide more details about the configuration that causes the problem, including the options specified when you built OpenLDAP, and any applicable log messages? It would also be good to know if you can reproduce the problem using current sources from git branch OPENLDAP_REL_ENG_2_4, which is the 2.4.43 release candidate. thanks, Ryan dn: cn=config objectClass: olcGlobal dn: cn=schema,cn=config objectClass: olcSchemaConfig include: file:servers/slapd/schema/core.ldif include: file:servers/slapd/schema/cosine.ldif include: file:servers/slapd/schema/inetorgperson.ldif include: file:servers/slapd/schema/nis.ldif include: file:servers/slapd/schema/dyngroup.ldif include: file:servers/slapd/schema/ppolicy.ldif dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcSuffix: dc=example,dc=net olcDbDirectory: data.d olcRootDN: cn=root,dc=example,dc=net olcRootPW: secret dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig olcSuffix: cn=accesslog olcDbDirectory: accesslog.d dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig dn: olcOverlay={1}dds,olcDatabase={1}mdb,cn=config objectClass: olcDDSConfig dn: olcOverlay={2}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcAccessLogConfig olcAccessLogDB: cn=accesslog dn: olcOverlay={3}unique,olcDatabase={1}mdb,cn=config objectClass: olcUniqueConfig dn: olcOverlay={4}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcPPolicyConfig dn: olcOverlay={5}refint,olcDatabase={1}mdb,cn=config objectClass: olcRefintConfig dn: olcOverlay={6}memberof,olcDatabase={1}mdb,cn=config objectClass: olcMemberOf dn: olcOverlay={7}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcDynamicList

1 0

Re: (ITS#8310) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by quanah＠zimbra.com 12 Nov '15

12 Nov '15

--On Friday, November 13, 2015 4:02 AM +0000 Steven Lang <Steven.Lang(a)hgst.com> wrote: > I tested with the latest mdb.master, commit > c6d908075ee5bdd1270fce6ec8d5d8df9b168021. Great, thanks for the confirmation. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8310) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by Steven.Lang＠hgst.com 12 Nov '15

12 Nov '15

I tested with the latest mdb.master, commit c6d908075ee5bdd1270fce6ec8d5d8d= f9b168021. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or l= egally privileged information of HGST and are intended solely for the use o= f the individual or entity to which they are addressed. If you are not the = intended recipient, any disclosure, copying, distribution or any action tak= en or omitted to be taken in reliance on it, is prohibited. If you have re= ceived this e-mail in error, please notify the sender immediately and delet= e the e-mail in its entirety from your system.

1 0

Re: (ITS#8310) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by quanah＠zimbra.com 12 Nov '15

12 Nov '15

--On Friday, November 13, 2015 3:54 AM +0000 steven.lang(a)hgst.com wrote: > Full_Name: Steven Lang > Version: LMDB 0.9.16 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/steven-lang-151112.tar.gz > Submission from: (NULL) (50.76.49.9) > > > This seems to be a variation on ITS#8258 - the base cause is the same; an > mdb_cursor_del causes the tree to grow in depth, the cursor is not > updated with the new depth, and the next cursor op on the cursor asserts. > > I have a DB and short C file which triggers the assert in a simple manner. Hi Steve, Just wanted to confirm you've verified this occurs with the 0.9.17 release candidate? Thanks, Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8310) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by steven.lang＠hgst.com 12 Nov '15

12 Nov '15

Full_Name: Steven Lang Version: LMDB 0.9.16 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/steven-lang-151112.tar.gz Submission from: (NULL) (50.76.49.9) This seems to be a variation on ITS#8258 - the base cause is the same; an mdb_cursor_del causes the tree to grow in depth, the cursor is not updated with the new depth, and the next cursor op on the cursor asserts. I have a DB and short C file which triggers the assert in a simple manner.

1 0

Re: (ITS#8308) Replication master/master with delta sync freeze after reboot
by quanah＠zimbra.com 12 Nov '15

12 Nov '15

--On Thursday, November 12, 2015 1:23 PM +0000 fs(a)etiam.com wrote: > Full_Name: Florian Suhard > Version: 2.4.40 > OS: Redhat 6.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (37.157.230.211) > I tried using gdb to detect the error. I see this trace : > Loaded symbols for /usr/bib64/libnsspem.so > 0x00007faa47d2022d in pthread_join (threadid=140368938260224, > thread_return=0x0) at pthread_join.c:89 > 89 lll_wait_tid (pd->tid); > > I'm at your disposal for any further informations. Hello, The RedHat builds of OpenLDAP are linked to the MozNSS crypto libraries. This is neither supported nor encouraged by the OpenLDAP project. You will need to take this report to RedHat, as they are responsible for dealing with any issues caused by their unsupported usage of MozNSS. I *strongly* advise you completely avoid the RHEL based OpenLDAP builds entirely. The LTB project provides builds for RHEL that are sanely linked to the supported OpenSSL crypto libraries if you are not able to build OpenLDAP yourself. Companies requires a support matrix for their OpenLDAP deployments will likely wish to contact Symas. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8309) Replication master/master with delta sync freeze after reboot
by fs＠etiam.com 12 Nov '15

12 Nov '15

Full_Name: Florian Suhard Version: 2.4.40 OS: Redhat 6.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.157.230.211) Hello, My name is Florian Suhard, i'm a french engineer. I am currently working on a project using openldap replication. Architecture of the project is as follows. We have several Redhat 6.5 servers (4 on our test environments). Each server has its own openldap directory on version 2.4.40. One of this server is the hub (connected to all other). Other servers are nodes (only connected to the hub). Replication master/master with delta sync has been configured on each servers. Nodes replicates only with the hub, Hub replicate with all nodes. What we observe it's sometimes (i'm sorry it's really random) when we reboot the hub, the slapd service 'freeze' on the hub and on others nodes. Service slapd seems start (service slapd status => OK) but not respo w when we try to connect with JXplorer and whith php function ldap_connect. When we restart slapd on the hub (service slapd restart) everything returns to normal. I have the feeling that it's more easily to reproduce the bug by doing change on ldap directory before reboot the hub. We tried to correct by upgrade on openldap version 2.4.42. Redhat not provide 2.4.42 version so we get source rpm of Redhat 2.4.40 and rebuild with source of openldap 2.4.42. Bug still reproduced after the upgrade. Our replication configuration can be found on your ftp ftp://ftp.openldap.org/incoming/ in archive Florian-Suhard-20151112.tar This archive is composed of 4 folders for the 4 servers configurations slapd_opex-ctm.test.etiam.com.tar => one node slapd_hia1-ctm.test.etiam.com.tar => one node slapd_hia2-ctm.test.etiam.com.tar => one node slapd_central-ctm.test.etiam.com.tar => hub I tried using gdb to detect the error. I see this trace : Loaded symbols for /usr/bib64/libnsspem.so 0x00007faa47d2022d in pthread_join (threadid=140368938260224, thread_return=0x0) at pthread_join.c:89 89 lll_wait_tid (pd->tid); I'm at your disposal for any further informations. Thanks

1 0

(ITS#8308) Replication master/master with delta sync freeze after reboot
by fs＠etiam.com 12 Nov '15

12 Nov '15

1 0

(ITS#8307) startup failed with DDS enabled
by boesch＠fhv.at 12 Nov '15

12 Nov '15

Full_Name: Christian B.sch Version: 2.4.42 OS: FreeBSD 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:628:2130:4458::93) I installed OpenLDAP 2.4.42, enabled these overlays on the mdb database: olcOverlay={0}syncprov.ldif olcOverlay={1}dds.ldif olcOverlay={2}accesslog.ldif olcOverlay={3}unique.ldif olcOverlay={4}ppolicy.ldif olcOverlay={5}refint.ldif olcOvery%y={6}memberof.ldif olcOverlay={7}dynlist.ldif started, everything is fine. Then I added an empty base tree: dn: dc=example,dc=net objectClass: dcObject objectClass: organization o: ORG dc: example dn: cn=admin,dc=example,dc=net objectClass: organizationalRole cn: LDAP Admin cn: admin dn: o=org,dc=example,dc=net o: ORG objectClass: organization objectClass: top After that, if slapd is restarted: /usr/local/etc/rc.d/slapd: WARNING: failed to start slapd If the db files are removed again, the startup works again, and if the dds overlay is removed the startup is always working even if the database isn't empty.

1 0

(ITS#8306) SLEEP0 etc should be used in test scripts
by quanah＠openldap.org 10 Nov '15

10 Nov '15

Full_Name: Quanah Gibson-Mount Version: master OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) We define SLEEP0, SLEEP1, etc to allow the ability to set via the environment how long to sleep during test executions. However, the variables are not used consistently. For example, "sleep 1" occurs 142 times in the test scripts, instead of using SLEEP0

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2015