(ITS#8389) ldapsearch
by baulin_ss＠mail.ru
Full_Name: Baulin Sergey
Version: unknown
OS: Debian8.3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.26.169.27)
Hello.
ldapsearch: @(#) $OpenLDAP: ldapsearch (Jan 17 2016 16:01:42) $
buildd@x86-csail-01:/build/openldap-EAKxYy/openldap-2.4.40+dfsg/debian/build/clients/tools
(LDAP library: OpenLDAP 20440)
I am running in bash:
ldapsearch -H ldap://server -w password -b "DC=domain,DC=local" -s sub -D
'CN=user,DC=domain,DC=local' -x "(objectClass=user)" sn cn mail
and it is working
but if i am running in bash script:
#!/bin/bash
BINDDN='CN=user,DC=domain,%3=local'
ldapsearch -H ldap://server -w password -b "DC=domain,DC=local" -s sub -D
$BINDDN -x "(objectClass=user)" sn cn mail
then:
ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903AA, comment:
AcceptSecurityContext error, data 525, v1772
Bash variable do not work only for key -D, for other keys bash variable is
working
7 years, 6 months
(ITS#8388) broken schema after replacing objectClass
by lessmian2＠o2.pl
Full_Name: Tomasz Leśniewski
Version: 2.4.44
OS: ubuntu
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (85.128.131.1)
accidentally i broke my openldap schema when i've changed one of objectClass
definitions. For example i have two objectClasses and one is a parent for
second:
olcObjectClasses: {0}( 1.2.3.4 NAME 'foo' DESC '' SUP top AUXILIARY X-ORIGIN
'user defined' )
olcObjectClasses: {1}( 1.2.3.5 NAME 'bar' DESC '' SUP foo AUXILIARY X-ORIGIN
'user defined' )
I've changed definition of foo - i've delete this object and (my mistake) put it
without any number at bottom of all classes:
dn: cn=config
changetype: modify
delete: olcObjectClasses
olcObjectClasses: {0}
-
add: olcObjectClasses
olcObjectClasses: ( 1.2.3.4 NAME 'foo' DESC '' SUP top AUXILIARY X-ORIGIN 'user
defined' )
So i have now class bar at top of schema and foo at bottom. After restart slapd
won't start. Slapcat says:
56d4678f olcObjectClasses: value #5 olcObjectClasses: ObjectClass not found:
"foo"
56d4678f config error processing cn=config: olcObjectClasses: ObjectClass not
found: "foo"
slapcat: bad configuration file!
Should slapd allow to make something that could break schema? I thought that
there are some constraints that not allow to remove objectClass which is parent
for another class.
7 years, 6 months
Re: (ITS#8385) Use After Free of struct ldap_common in slap_client_connect
by mkp37215＠gmail.com
On Mon, Mar 14, 2016 at 8:04 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
>
> The Debian/Ubuntu maintainers are quite aware of the problems with using
> GnuTLS, and maintain they cannot use OpenSSL due to licensing issues,
> despite the fact every other major distribution uses OpenSSL (except RHEL,
> which switched to MozNSS which resulted in much disaster, and is likely
> going to switch back to OpenSSL).
>
> There is no reason you cannot use OpenSSL, regardless of what
> Debian/Ubuntu's broken decisions are.
>
> --Quanah
Quanah, thank you for your reply. However, I do not want to engage in
a political discussion, particularly on the matter that is beyond my
control. It is also out of topic, as the bug discussed here was in
libldap code, and not in GnuTLS. I would like to again thank Howard
for his work on this bug and coming up with a working fix very
quickly. Unless any new issue related to this bug or the fix comes to
light, I think we can consider the matter closed.
Maciej Puzio
7 years, 6 months
(ITS#8387) online olcDbConfig change fails with syncprov
by ryan＠openldap.org
Full_Name: Ryan Tandy
Version: 2.4, master
OS: Debian
URL:
Submission from: (NULL) (24.68.37.4)
Submitted by: ryan
Forwarding from a Debian bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816294
Configure a BDB or HDB database with syncprov:
dn: olcDatabase={1}hdb,cn=config
objectClass: olcHdbConfig
olcDbDirectory: data
olcSuffix: dc=example,dc=comD%D
dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcSyncProvConfig
perform some kind of modification to the database (so that a syncprov checkpoint
is pending), and perform an online olcDbConfig change that reopens the
database.
dn: olcDatabase={1}hdb,cn=config
changetype: modify
replace: olcDbConfig
olcDbConfig: set_cachesize 1 0 1
Reopening the database fails:
56e76e17 bdb(dc=example,dc=com): BDB4511 Error: closing the transaction region
with active transactions
56e76e17 bdb_db_close: database "dc=example,dc=com": close failed: Invalid
argument (22)
and slapd crashes shortly after, when it tries to syncprov_checkpoint while the
database is already gone.
What appears to be happening is that "ctx" is different between bdb_reader_get
and bdb_reader_flush in this case.
During a normal slapd startup and shutdown:
(gdb) thread apply all frame
Thread 1 (Thread 0x7ffff7fed700 (LWP 21570)):
#0 hdb_reader_get (op=0x7fffffffd8d0, env=0xa93fa0, txn=0x7fffffffd610) at
cache.c:1666
1666 if ( !ctx ) {
(gdb) p ctx
$1 = (void *) 0x8b34a0 <ldap_int_main_thrctx>
[ ... killall slapd ... ]
(gdb) thread apply all frame
Thread 1 (Thread 0x7ffff7fed700 (LWP 21570)):
#0 hdb_reader_flush (env=0xa93fa0) at cache.c:1643
1643 if ( !ldap_pvt_thread_pool_getkey( ctx, env, &data, NULL ) ) {
(gdb) p ctx
$2 = (void *) 0x8b34a0 <ldap_int_main_thrctx>
In this case, the readers are cleared correctly.
Another startup, this time the hdb_db_close is triggered by performing an
olcDbConfig change:
(gdb) thread apply all frame
Thread 1 (Thread 0x7ffff7fed700 (LWP 21624)):
#0 hdb_reader_get (op=0x7fffffffd8d0, env=0xa93fa0, txn=0x7fffffffd610) at
cache.c:1666
1666 if ( !ctx ) {
(gd2929 p ctx
$1 = (void *) 0x8b34a0 <ldap_int_main_thrctx>
[ ... ldapmodify ... ]
(gdb) thread apply all frame
Thread 3 (Thread 0x7ffff362e700 (LWP 21633)):
#0 hdb_reader_flush (env=0xa93fa0) at cache.c:1643
1643 if ( !ldap_pvt_thread_pool_getkey( ctx, env, &data, NULL ) ) {
Thread 2 (Thread 0x7ffff3e2f700 (LWP 21631)):
#0 0x00007ffff732d4d3 in epoll_wait () at
../sysdeps/unix/syscall-template.S:84
84 ../sysdeps/unix/syscall-template.S: No such file or directory.
Thread 1 (Thread 0x7ffff7fed700 (LWP 21624)):
#0 0x00007ffff75f06dd in pthread_join (threadid=140737285125888,
thread_return=0x0) at pthread_join.c:90
90 pthread_join.c: No such file or directory.
(gdb) p ctx
$2 = (void *) 0x7ffff362dbf0
This time we have a different ctx, so the readers are not cleared. This when we
get to db->close there is still an active txn.
The comment "free up any keys used by the main thread" seems to assume
bdb_reader_flush will be called on the main thread only.
7 years, 6 months
Re: (ITS#8385) Use After Free of struct ldap_common in slap_client_connect
by quanah＠zimbra.com
--On Tuesday, March 15, 2016 1:34 AM +0000 mkp37215(a)gmail.com wrote:
> --089e0139fc98189d9d052e0b902f
> Content-Type: text/plain; charset=UTF-8
>
> Howard, thank you very much for quickly fixing this issue. My tests show
> that the replication is now working fine.
> Regarding your recommendation of OpenSSL, that should rather go to
> OpenLDAP package maintainers at Ubuntu and Debian. I use what they build
> and the choice of the TLS library is not mine.
The Debian/Ubuntu maintainers are quite aware of the problems with using
GnuTLS, and maintain they cannot use OpenSSL due to licensing issues,
despite the fact every other major distribution uses OpenSSL (except RHEL,
which switched to MozNSS which resulted in much disaster, and is likely
going to switch back to OpenSSL).
There is no reason you cannot use OpenSSL, regardless of what
Debian/Ubuntu's broken decisions are.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
A division of Synacor, Inc
7 years, 6 months
Re: (ITS#8385) Use After Free of struct ldap_common in slap_client_connect
by mkp37215＠gmail.com
--089e0139fc98189d9d052e0b902f
Content-Type: text/plain; charset=UTF-8
Howard, thank you very much for quickly fixing this issue. My tests show
that the replication is now working fine.
Regarding your recommendation of OpenSSL, that should rather go to OpenLDAP
package maintainers at Ubuntu and Debian. I use what they build and the
choice of the TLS library is not mine.
--089e0139fc98189d9d052e0b902f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Howard, thank you very much for quickly fixing this i=
ssue. My tests show that the replication is now working fine.<br></div>Rega=
rding your recommendation of OpenSSL, that should rather go to OpenLDAP pac=
kage maintainers at Ubuntu and Debian. I use what they build and the choice=
of the TLS library is not mine.<br></div>
--089e0139fc98189d9d052e0b902f--
7 years, 6 months
(ITS#8386) Small LMDB Documentation patch
by philipp.storz＠bareos.com
Full_Name: Philipp Storz
Version: LMDB 0.9.18
OS: linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (94.79.184.234)
>From ede152281433d1e0bdc12741923c715360c4664a Mon Sep 17 00:00:00 2001
From: Philipp Storz <philipp.storz(a)bareos.com>
Date: Mon, 14 Mar 2016 10:07:35 +0100
Subject: [PATCH] be a bit more precise that mdb_get retrieves data
---
libraries/liblmdb/intro.doc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libraries/liblmdb/intro.doc b/libraries/liblmdb/intro.doc
index 9fe9c22..2886c20 100644
--- a/libraries/liblmdb/intro.doc
+++ b/libraries/liblmdb/intro.doc
@@ -51,7 +51,7 @@ databases should only be opened once, by the first transaction
in
the process. After the first transaction completes, the database
handles can freely be used by all subsequent transactions.
-Within a transaction, #mdb_get() and #mdb_put(% c can store single
+Within a transaction, #mdb_get() can retrieve and #mdb_put() can store single
key/value pairs if that is all you need to do (but see \ref Cursors
below if you want to do more).
--
2.6.2
7 years, 6 months
