(ITS#7993) proxyauth with saslmech EXTERNAL not working
by dkastens＠uos.de
Full_Name: Dirk Kastens
Version: 2.4.39
OS: RedHat SL 6.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2001:638:508:3d0:12a:32c6:740c:8971)
We installed an ldap cluster with a mirrored master and several replicas on
RedHat SL 6.5 with openldap 2.4.23-34.el6_5.1.x86_64. Write requests to the
replicas are referred to the master server. The chain overlay follows the
referral. It connects with the saslmech EXTERNAL to the master. The master maps
the DN of the certificate to the replica admin. The replica admin has its
authzTo attribute set to the write admin. This way the writing perfectly worked
on our replica servers for all admins that are listed in the authzTo attribute.
Shortly the machines were updated to SL 6.6 with openldap 2.4.39-8.el6.x86_64.
The proxyauth stopped working. Write requests to the replica servers end with
the error
"ldap_modify: Other (e.g., implementationpepecific) error (80)".
I installed another replica under SL 7.0 with openldap-2.4.39-3.el7.x86_64: same
result. When I configure the idassertbind attribute to use simple bind with a
binddn and credentials, the proxyauth works.
This is the chain configuration that doesn't work any longer:
olcDbURI: "ldap://ldap-master"
olcDbStartTLS: none starttls=no
olcDbIDAssertAuthzFrom: {0}*
olcDbIDAssertBind: mode=self
bindmethod=sasl saslmech=EXTERNAL starttls=yes
tls_cert="/etc/openldap/certs/ldap-replica.pem"
tls_key="/etc/openldap/certs/ldap-replica.key"
tls_cacert="/etc/openldap/cacerts/cacerts.pem"
tls_cacertdir="/etc/openldap/cacerts"
tls_reqcert=demand
This is the configuration that works now:
olcDbStartTLS: none starttls=no
olcDbURI: "ldap://ldap-master"
olcDbIDAssertAuthzFrom: {0}*
olcDbIDAssertBind: mode=self
bindmethod=simple
binddn="cn=proxyuser" credentials="secret"
starttls=yes
tls_cert="/etc/openldap/certs/ldap-replica.pem"
tls_key="/etc/openldap/certs/ldap-replica.key"
tls_cacert="/etc/openldap/cacerts/cacerts.pem"
tls_cacertdir="/etc/openldap/cacerts"
tls_reqcert=demand
I looked through the manual pages, but I didn't find a difference between 2.4.23
and 2.4.39. In 2.4.23 we had to load the chain module and now we load the
back_ldap module. But that's all.
Dirk
8 years, 6 months
Re: (ITS#7974) LDBM's "laggard reader" flaw still present, in continue of ITS#7904
by h.b.furuseth＠usit.uio.no
On 12/04/2014 11:31 AM, leo(a)yuriev.ru wrote:
> Could you suggest something other instead of "oomkiller"?
Don't have a particularly good idea. oom_func, maybe.
>> This feature could make it interesting to let readers and writers
>> tell each other things: Reserve some unused space in the reader
>> table slots for stuff the reader's caller could put there, and
>> some space for an impatient writer to leave a note. Could go
>> in an independent commit if there is any demand for it though.
>
> Communications between readers and writers may be interesting, but I
> think it is over-engineering in the LMDB context.
Yes... I guess I was thinking mostly of the prototype, in case we
want to add something like it later. Might be useful to add a void*
argument which would be NULL now but could be used later, if needed.
--
Hallvard
8 years, 6 months
Re: (ITS#7974) LDBM's "laggard reader" flaw still present, in continue of ITS#7904
by leo＠yuriev.ru
Hallvard, thank for your comments.
2014-12-02 14:20 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>:
> On 10/23/2014 07:13 AM, leo(a)yuriev.ru wrote:
>>
>> Subject: [PATCH 1/2] lmdb: ITS#7974 oomkiller feature.
>> (...)
>> +typedef int (MDB_oomkiller_func)(MDB_env *env, int pid, void* thread_id,
>> size_t txn);
>
>
> Some thoughts about this:
>
> Instead of trusting the return value, it seems safer to re-check
> with mdb_reader_pid(). Like mdb_reader_check0() does. Maybe
> except on Windows, where file locks from dead processes may
> linger for a while until the OS reclaims them.
I agree that usign mdb_reader_pid() is a better way.
> Don't call it OOMkiller just because that's how you use it.
> Others might do something else, like sending a reader a signal
> which it interprets as "please wake up and finish your txn".
> Or it might decide this process is the one which should give up.
Could you suggest something other instead of "oomkiller"?
Be noted, the "dreamcatcher" feature has a critical bug, which I has
found and made fix while work on ITS#7968 & ITS#7987.
Currently we hard testing a new code.
So, in a week I plan to update both of the patches.
> This feature could make it interesting to let readers and writers
> tell each other things: Reserve some unused space in the reader
> table slots for stuff the reader's caller could put there, and
> some space for an impatient writer to leave a note. Could go
> in an independent commit if there is any demand for it though.
Communications between readers and writers may be interesting, but I
think it is over-engineering in the LMDB context.
IMHO the LMDB's code has a lot of technical debt, so it is more
usefull to re-implement all of from a scratch, under a rules of
perfectly-clean codestyle.
May be I will do this, but on a basis and after a release of 1Hippeus
- it is a extreme performance engine for zero-copy mesaging in a
shared memory, partially like Intel DPDK.
Leonid.
8 years, 6 months
(ITS#7991) problem trying to call ldap_set_option
by shupilov＠tut.by
Full_Name: Dmitry Shupilov
Version: 2.4.39
OS: RHEL 6.5 x86_64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (86.57.254.70)
Hello all!
It's my first time to post here, so sorry if I will do something wrong :)
I have to write shared library which task is to check if the user is correct
LDAP user. First of all I prepare env and call ldap_initialize - nothing special
here. The ldap_create function sets ld properly (e.g. ld = '0x7fffe40837d0')
and in gdb I can read it by (p *ld) or even deeper (p *ld.ldc). But the next
function cannot do its job - ldap_set_option failed with "-1" status. I tried to
create separate binary which use my shared *.so to do the same job - check a
user in LDAP and it works fine: ldap_create assigns "short" address (e.g.
0x602a30). In this case ldap_set_option do what it needs to do.
My question is: is the problem of ldap_set_option in that "very long value of
address" or is something else? How can I catch the reason of this problem and
solve it?
BR,
Dmitry
8 years, 6 months
(ITS#7990) (docs) Admin guide: bad link in password policy overlay section
by frederic.poisson＠admin.gmessaging.net
Full_Name: Frederic POISSON
Version: 2.4.40
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (194.51.12.20)
Hello,
I'm looking to Password Policy overlay and admin guide 2.4, and i see that
Howard CHU has corrected a link (ITS#6264) about "Password Management Issues".
But on that link on Symas blog i do not see anything on that subject ?
I have also another question about Password policy draft. Does OpenLDAP project
already receive a feature request to support the draft in release 10 ?
Thanks,
Regards,
8 years, 6 months
Re: (ITS#7974) LDBM's "laggard reader" flaw still present, in continue of ITS#7904
by h.b.furuseth＠usit.uio.no
On 10/23/2014 07:13 AM, leo(a)yuriev.ru wrote:
> Subject: [PATCH 1/2] lmdb: ITS#7974 oomkiller feature.
> (...)
> +typedef int (MDB_oomkiller_func)(MDB_env *env, int pid, void* thread_id, size_t txn);
Some thoughts about this:
Instead of trusting the return value, it seems safer to re-check
with mdb_reader_pid(). Like mdb_reader_check0() does. Maybe
except on Windows, where file locks from dead processes may
linger for a while until the OS reclaims them.
Don't call it OOMkiller just because that's how you use it.
Others might do something else, like sending a reader a signal
which it interprets as "please wake up and finish your txn".
Or it might decide this process is the one which should give up.
This feature could make it interesting to let readers and writers
tell each other things: Reserve some unused space in the reader
table slots for stuff the reader's caller could put there, and
some space for an impatient writer to leave a note. Could go
in an independent commit if there is any demand for it though.
--
Hallvard
8 years, 6 months
Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru
This is a multi-part message in MIME format.
--------------090506050608000200000309
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
(1) I can сonfirm once again - the bug is fixed.
(2) Previously noted failure "DN index delete failed" caused by another
(local) bug.
(3) Feature "single write txn" need a minor fix, patch attached.
Leonid.
---
The attached files is derived from OpenLDAP Software. All of the
modifications
to OpenLDAP Software represented in the following patch(es) were
developed by
Peter-Service LLC, Moscow, Russia. Peter-Service LLC has not assigned
rights
and/or interest in this work to any party. I, Leonid Yuriev am
authorized by
Peter-Service LLC, my employer, to release this work under the following
terms.
Peter-Service LLC hereby places the following modifications to OpenLDAP
Software
(and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose
with or
without attribution and/or other notice.
--------------090506050608000200000309
Content-Type: text/x-patch;
name="excessive-space-single-write-txn.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="excessive-space-single-write-txn.patch"
commit 02094a10018e1ebcae32b920f9d93d300a810f29
Author: Leo Yuriev <leo(a)yuriev.ru>
Date: 2014-12-02 14:02:02 +0300
fix excessive space (likely a typo) for single write txn.
diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c
index 6e9119d..7587434 100644
--- a/libraries/liblmdb/mdb.c
+++ b/libraries/liblmdb/mdb.c
@@ -4589,7 +4589,7 @@ mdb_env_open(MDB_env *env, const char *path, unsigned int flags, mdb_mode_t mode
if (!(flags & MDB_RDONLY)) {
MDB_txn *txn;
int tsize = sizeof(MDB_txn), size = tsize + env->me_maxdbs *
- (sizeof(MDB_db)+sizeof(MDB_cursor)+sizeof(unsigned int)+1);
+ (sizeof(MDB_db)+sizeof(MDB_cursor *)+sizeof(unsigned int)+1);
txn = calloc(1, size);
if (txn) {
txn->mt_dbs = (MDB_db *)((char *)txn + tsize);
--------------090506050608000200000309--
8 years, 6 months
Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru
> 2014-12-02 6:09 GMT+03:00 Howard Chu <hyc(a)symas.com>:
>> Leonid Yuriev wrote:
>>> Partially fixed.
>>> Patch is for current OPENLDAP_REL_ENG_2_4, but applicable for master.
>>
>> Thanks, the patch makes sense. But if only partial, what else is still
>> crashing?
> Stable crash in a 5 seconds after the 4x-cluster resumes from
> split-brain condition:
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 __memcpy_sse2_unaligned () at
> ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116
> 116 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: Нет такого
> файла или каталога.
> (gdb) bt
> #0 __memcpy_sse2_unaligned () at
> ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116
> #1 0x00000000004aee11 in memcpy (__len=<optimised out>,
> __src=<optimised out>, __dest=<optimised out>) at
> /usr/include/x86_64-linux-gnu/bits/string3.h:51
> #2 mdb_search (op=0x7f16b4ffa7c0, rs=0x7f16b4e697b0) at search.c:993
Seems to be fixed completely.
The last SIGSEGV is inducted by a "dreamcatcher" feature (ITS#7974).
I already fixed the "dreamcatcher", currently we are re-testing it.
Leonid.
8 years, 6 months
Fwd: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru
2014-12-02 6:09 GMT+03:00 Howard Chu <hyc(a)symas.com>:
> Leonid Yuriev wrote:
>>
>> Partially fixed.
>> Patch is for current OPENLDAP_REL_ENG_2_4, but applicable for master.
>
>
> Thanks, the patch makes sense. But if only partial, what else is still
> crashing?
Stable crash in a 5 seconds after the 4x-cluster resumes from
split-brain condition:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __memcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116
116 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: =D0=9D=D0=B5=D1=82=
=D1=82=D0=B0=D0=BA=D0=BE=D0=B3=D0=BE
=D1=84=D0=B0=D0=B9=D0=BB=D0=B0 =D0=B8=D0=BB=D0=B8 =D0=BA=D0=B0=D1=82=D0=B0=
=D0=BB=D0=BE=D0=B3=D0=B0.
(gdb) bt
#0 __memcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116
#1 0x00000000004aee11 in memcpy (__len=3D<optimised out>,
__src=3D<optimised out>, __dest=3D<optimised out>) at
/usr/include/x86_64-linux-gnu/bits/string3.h:51
#2 mdb_search (op=3D0x7f16b4ffa7c0, rs=3D0x7f16b4e697b0) at search.c:993
#3 0x000000000048a52a in overlay_op_walk (op=3Dop@entry=3D0x7f16b4ffa7c0,
rs=3D0x7f16b4ff9c40, which=3Dop_search, oi=3D0xc31a30, on=3D<optimised out>=
)
at backover.c:676
#4 0x000000000048a681 in over_op_func (op=3D0x7f16b4ffa7c0,
rs=3D<optimised out>, which=3D<optimised out>) at backover.c:729
#5 0x000000000047de37 in syncrepl_del_nonpresent (op=3D0x7f16b4ffa7c0,
si=3D0xc31490, uuids=3D<optimised out>, m=3D3, sc=3D<optimised out>,
sc=3D<optimised out>) at syncrepl.c:3400
#6 0x0000000000481a0e in do_syncrep2 (op=3D0x7f16b4ffa7c0, si=3D0xc31490)
at syncrepl.c:1346
#7 0x00000000004839e3 in do_syncrepl (ctx=3D<optimised out>,
arg=3D0xc319d0) at syncrepl.c:1550
#8 0x00007f170283ecf2 in ldap_int_thread_pool_wrapper
(xpool=3D0xbe4090) at tpool.c:688
8 years, 6 months
