December 2015 - openldap-bugs

(ITS#8345) inconsistencies regarding LDIF line length

by ryan＠openldap.org

Full_Name: Ryan Tandy Version: master, 2.4 OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan This is sort of a follow-up to ITS#7871. ldif_sput gained an LDIF_KLUDGE, but ldif_put did not, so the latter now wraps at 76 columns instead of 78. (IMO ldif_sput and ldif_put could both just pass 0 for wrap instead of a specific number, and let ldif_sput_wrap set the default.) LDIF_SIZE_NEEDED still assumes wrapping to LDIF_LINE_WIDTH columns, so code that does LDIF_SIZE_NEEDED and then ldif_sput is now allocating (slightly) more memory than it actually needs. 389-ds does this, for example. (And actually, couldn't LDIF_SIZE_NEEDED just be a thinner wrapper around LDIF_SIZE_NEEDED_WRAP?) Not sure exactly what the policies are around API changes in exposed headers, but for 2.5, maybe LDIF_LINE_WIDTH could change to 78 and LDIF_KLUDGE could go away entirely? Should I take this part to -devel? BTW, is it still necessary for ldif.c to re-implement base64 instead of using the lutil functions?

7 years, 11 months

1
0
0 / 0

Re: (ITS#8344) doc clarification: accesslog database should not be replicated

by jephte.clain＠univ-reunion.fr

This is a multi-part message in MIME format. --------------090104080006050907050407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The patch is attached --------------090104080006050907050407 Content-Type: text/x-diff; name="0001-accesslog-database-should-not-be-replicated.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-accesslog-database-should-not-be-replicated.patch" >From 351f3080b6fcf02dd67d4923e3c4e6fd99491b0a Mon Sep 17 00:00:00 2001 From: Jephte CLAIN <Jephte.Clain(a)univ-reunion.fr> Date: Thu, 31 Dec 2015 12:03:56 +0400 Subject: [PATCH] accesslog database should not be replicated --- doc/guide/admin/overlays.sdf | 4 ++++ doc/guide/admin/replication.sdf | 3 +++ 2 files changed, 7 insertions(+), 0 deletions(-) diff --git a/doc/guide/admin/overlays.sdf b/doc/guide/admin/overlays.sdf index fbf417b..026a35e 100644 --- a/doc/guide/admin/overlays.sdf +++ b/doc/guide/admin/overlays.sdf @@ -79,6 +79,10 @@ or in raw form. It is also used for {{SECT:delta-syncrepl replication}} +Note: an accesslog database is unique to a given master. Even though it may have +a syncprov overlay (e.g. when used for delta-syncrepl replication), it should +NOT be replicated. + H3: Access Logging Configuration The following is a basic example that implements Access Logging: diff --git a/doc/guide/admin/replication.sdf b/doc/guide/admin/replication.sdf index 54dabc0..7a3ebfc 100644 --- a/doc/guide/admin/replication.sdf +++ b/doc/guide/admin/replication.sdf @@ -743,6 +743,9 @@ all of the databases (primary, replica, and the accesslog storage database) should also have properly tuned {{DB_CONFIG}} files that meet your needs. +Note: an accesslog database is unique to a given master. Even though the +syncprov overlay is configured for delta-syncrepl replication, it should NOT be +replicated on the client. H3: N-Way Multi-Master -- 1.7.2.5 --------------090104080006050907050407--

7 years, 11 months

1
0
0 / 0

(ITS#8344) doc clarification: accesslog database should not be replicated

by Jephte.Clain＠univ-reunion.fr

Full_Name: Jephte CLAIN Version: 2.4.43 OS: Linux URL: https://github.com/gdrsi/openldap/commit/351f3080b6fcf02dd67d4923e3c4e6fd... Submission from: (NULL) (194.199.72.141) The admin guide does not stat clearly that the accesslog database should not be replicated. I attach a patch to clarify the documentation

7 years, 11 months

1
0
0 / 0

Re: (ITS#8343) MDB database corrupted after one run

by hyc＠symas.com

gate03(a)landcroft.com wrote: > Full_Name: Michael Mounteney > Version: 2.4.43 > OS: OmniOS > URL: http://pastebin.com/aV1yFt7g > Submission from: (NULL) (122.108.201.32) > This appears to be a dup of ITS#8339. Closing. > > 0. rm /var/openldap-data/* > 1. Install attached slapd.conf in /opt/openldap/etc/openldap > 2. Save attached l1.ldif > 3. Run your LDAP server thus: /opt/openldap/libexec/slapd -f > /opt/openldap/etc/openldap/slapd.conf -h "ldap:/// ldaps:///" -d -1 > 4. Import the LDIF data thus: ldapadd -D "cn=manager,dc=mounteney,dc=me" -a -W > -f l1.ldif > 5. The password is: suomi > 6. The data import/add/load will crash on the last entry. > 7. Stop the server with ctrl-C. > 8. Restart the server with the same command as at step 3. > 9. The server reports: mdb_db_open: database "dc=mounteney,dc=me" cannot be > opened: Device busy (16). Restore from backup! > > The error is that at step 9, the OpenLDAP should have opened the existing > database and run normally, waiting for client requests. > > slapd.conf at http://pastebin.com/aV1yFt7g > l1.ldif at http://pastebin.com/tHc5ye1W > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

7 years, 11 months

1
0
0 / 0

(ITS#8343) MDB database corrupted after one run

by gate03＠landcroft.com

Full_Name: Michael Mounteney Version: 2.4.43 OS: OmniOS URL: http://pastebin.com/aV1yFt7g Submission from: (NULL) (122.108.201.32) 0. rm /var/openldap-data/* 1. Install attached slapd.conf in /opt/openldap/etc/openldap 2. Save attached l1.ldif 3. Run your LDAP server thus: /opt/openldap/libexec/slapd -f /opt/openldap/etc/openldap/slapd.conf -h "ldap:/// ldaps:///" -d -1 4. Import the LDIF data thus: ldapadd -D "cn=manager,dc=mounteney,dc=me" -a -W -f l1.ldif 5. The password is: suomi 6. The data import/add/load will crash on the last entry. 7. Stop the server with ctrl-C. 8. Restart the server with the same command as at step 3. 9. The server reports: mdb_db_open: database "dc=mounteney,dc=me" cannot be opened: Device busy (16). Restore from backup! The error is that at step 9, the OpenLDAP should have opened the existing database and run normally, waiting for client requests. slapd.conf at http://pastebin.com/aV1yFt7g l1.ldif at http://pastebin.com/tHc5ye1W

7 years, 11 months

1
0
0 / 0

(ITS#8342) lmdb Handle Leak with VL32 on Windows

by jeremiah.morrill＠econnect.tv

Full_Name: Jeremiah Morrill Version: lmdb 0.9.70 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.120.130.199) I noticed what I believe may be a handle leak against the latest (commit 7b9928c) on github, with the MDB_VL32 on Windows. After some poking around, it seems to be the file mapping handle, env->me_fmh. I threw it to a CloseHandle in the env_close0() and it seemed to resolve it. Heres a quick diff: diff --git a/src/lmdb.c b/src/mdb.c index a564d40..190c860 100644 --- a/src/mdb.c +++ b/src/mdb.c @@ -5350,6 +5350,7 @@ mdb_env_close0(MDB_env *env, int excl) } #ifdef MDB_VL32 #ifdef _WIN32 + if (env->me_fmh) CloseHandle(env->me_fmh); if (env->me_rpmutex) CloseHandle(env->me_rpmutex); #else pthread_mutex_destroy(&env->me_rpmutex);

7 years, 11 months

1
0
0 / 0

Re: (ITS#8341) Matching rules for 'namingContexts'

by michael＠stroeder.com

This is a multi-part message in MIME format. --------------090808030207050404060004 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Find attached the very trivial patch applied to git master for adding the EQUALITY matching rule to attribute type description for 'namingContexts'. Successfully tested. --------------090808030207050404060004 Content-Type: text/x-patch; name="openldap-patch-its8341.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="openldap-patch-its8341.diff" diff --git a/servers/slapd/schema_prep.c b/servers/slapd/schema_prep.c index 5630a95..b583e3d 100644 --- a/servers/slapd/schema_prep.c +++ b/servers/slapd/schema_prep.c @@ -633,6 +633,7 @@ static struct slap_schema_ad_map { { "namingContexts", "( 1.3.6.1.4.1.1466.101.120.5 " "NAME 'namingContexts' " "DESC 'RFC4512: naming contexts' " + "EQUALITY distinguishedNameMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation )", rootDseAttribute, 0, NULL, NULL, --------------090808030207050404060004--

7 years, 11 months

1
0
0 / 0

(ITS#8341) Matching rules for 'namingContexts'

by michael＠stroeder.com

Full_Name: Michael Str.der Version: HEAD OS: Linux URL: Submission from: (NULL) (213.240.180.113) For finding the monitoring entry for a given suffix matching rules for attribute 'namingContexts' have to be added.

7 years, 11 months

1
0
0 / 0

(ITS#8340) test022-ppolicy failed

by dieter＠dkluenter.de

Full_Name: Dieter Kl.nter Version: OPENLDAP_REL_ENG_2_5 OS: openSUSE-42.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.220.31.155) this is git 8bbbaea0b4ec58ad51b9fb1b09e7b6e996ee0361 as the subject mentions, test022-ppolicy fails, this are the last 30 lines of slapd.1.log 56786874 <<< dnPrettyNormal: <uid=nd,ou=People,dc=example,dc=com>, <uid=nd,ou=peopleCdCdc=example,dc=com> 56786874 conn=1005 op=0 BIND dn="uid=nd,ou=People,dc=example,dc=com" method=128 56786874 do_bind: version=3 dn="uid=nd,ou=People,dc=example,dc=com" method=128 56786874 => mdb_entry_get: ndn: "uid=nd,ou=people,dc=example,dc=com" 56786874 => mdb_entry_get% o oc: "(null)", at: "(null)" 56786874 mdb_dn2entry("uid=nd,ou=people,dc=example,dc=com") 56786874 => mdb_dn2id("uid=nd,ou=people,dc=example,dc=com") 56786874 <= mdb_dn2id: got id=0x5 56786874 => mdb_entry_decode: 56786874 <= mdb_entry_decode 56786874 mdb_entry_get: rc=0 56786874 => mdb_entry_get: ndn: "cn=standard policy,ou=policies,dc=example,dc=com" 56786874 => mdb_entry_get: oc: "(null)", at: "(null)" 56786874 mdb_dn2entry("cn=standard policy,ou=policies,dc=example,dc=com") 56786874 => mdb_dn2id("cn=standard policy,ou=policies,dc=example,dc=com") 56786874 <= mdb_dn2id: got id=0x4 56786874 => mdb_entry_decode: 56786874 <= mdb_entry_decode 56786874 mdb_entry_get: rc=0 56786874 send_ldap_result: conn=1005 op=0 p=3 56786874 send_ldap_result: err=49 matched="" text="" 56786874 send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 52 bytes to sd 12 56786874 conn=1005 op=0 RESULT tag=97 err=49 etime=0.000460 text= slapd: ppolicy.c:914: ctrls_cleanup: Assertion `rs->sr_ctrls != ((void *)0)' failed. -Dieter

7 years, 11 months

1
0
0 / 0

(ITS#8339) LMDB robust mutex fix

by openldap＠gulag.ch

Full_Name: Rolf Stalder Version: 2.4.43 OS: Solaris 11.2 URL: https://www.gulag.ch/www/download/0001-Solaris-robust-mutex-fix.patch Submission from: (NULL) (217.162.126.5) The provided patch (against 2.4.43) might solve a problem with the new robust POSIX mutex implementation of LMDB 0.9.17 on Solaris 10/11.x. On Solaris 11 slapd fails to open the database: -- mdb_db_open: database "x": dbenv_open(y). mdb_db_open: database "x" cannot be opened: z (N). Restore from backup! backend_startup_one (type=mdb, suffix="x"): bi_db_open failed! (N) slapd shutdown: initiated -- Values of 16 (EBUSY) and 22 (EINVAL) have been observed for N. The following notes can be found in pthread_mutexattr_setrobust(3C) ( https://docs.oracle.com/cd/E36784_01/html/E36874/pthread-mutexattr-setrob.... html ): -- The mutex memory must be zeroed before first initialization of a mutex with the PTHREAD_MUTEX_ROBUST attribute. Any thread in any process interested in the robust lock can call pthread_mutex_init() to potentially initialize it, provided that all such callers of pthread_mutex_init() specify the same set of attributes in their attribute structures. In this situation, if pthread_mutex_init() is called on a pre- viously initialized robust mutex, it will not reinitialize the mutex and will return the error value EBUSY. If pthread_mutex_init() is called on a previously initialized robust mutex, and if the caller specifies a different set of attributes from those already in effect for the mutex, it will not reinitialize the mutex and will return the error value EINVAL. -- Solaris 10 only provides the *_np functions (2.4.43 build/compilation fails altogether) but the above meaning of EBUSY/EINVAL applies as well. This patch has only be tested on Solaris 10/11.2 with Solaris Studio 12.3.

7 years, 11 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2015