Re: (ITS#8307) startup failed with DDS enabled
by ryan＠openldap.org
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
7 years, 10 months
Re: (ITS#8310) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by quanah＠zimbra.com
--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
7 years, 10 months
Re: (ITS#8310) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by Steven.Lang＠hgst.com
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.
7 years, 10 months
Re: (ITS#8310) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by quanah＠zimbra.com
--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
7 years, 10 months
Re: (ITS#8308) Replication master/master with delta sync freeze after reboot
by quanah＠zimbra.com
--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
7 years, 10 months
(ITS#8309) Replication master/master with delta sync freeze after reboot
by fs＠etiam.com
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
7 years, 10 months
(ITS#8308) Replication master/master with delta sync freeze after reboot
by fs＠etiam.com
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
7 years, 10 months
(ITS#8307) startup failed with DDS enabled
by boesch＠fhv.at
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.
7 years, 10 months
(ITS#8306) SLEEP0 etc should be used in test scripts
by quanah＠openldap.org
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
7 years, 10 months
