Re: (ITS#8649) Issue when fetching the backend that will receive the contextCSN when we have glued databases
by hyc@symas.com
elecharny(a)gmail.com wrote:
> Using a function to compute the working backend, it could be something
> like :
Discussions really belong on the -devel list, not in the ITS.
>
> void setWorkingBackend( syncinfo_t *syncInfo, Backend *backend )
> {
> if ( !syncInfo->si_wbe )
> {
> if ( SLAP_GLUE_SUBORDINATE( backend ) && !overlay_is_inst(
> backend, "syncprov" ) )
> {
> // The backend has a parent backend, fetch it. Note that we
> want to get the
> // top parent, not one of the intermediary subordinate,
> unless one of them
> // has a syncprov overlay declared. If the top level backend
> // does not have a syncprov overlay declared, then we use
> the local DB
> // as a working backend.
> BackendDB *currentBackend = backend;
> struct berval bv;
> ber_str2bv( currentBackend->be_nsuffix[0].bv_val, 0, 0, &bv );
> dnParent( &bv, &bv );
>
> while ( ( currentBackend = select_backend( &bv, 0 ) ) != NULL )
> {
> if ( overlay_is_inst( currentBackend, "syncprov" ) )
> {
> syncInfo->si_wbe = currentBackend;
> break;
> }
>
> dnParent( &bv, &bv );
> }
>
> if ( syncInfo->si_wbe == NULL )
> {
> syncInfo->si_wbe = backend;
> }
> }
> else
> {
> syncInfo->si_wbe = backend;
> }
>
> if ( SLAP_SYNC_SUBENTRY( syncInfo->si_wbe ) )
> {
> build_new_dn( &syncInfo->si_contextdn,
> &syncInfo->si_wbe->be_nsuffix[0], (struct berval *)
> &slap_ldapsync_cn_bv, NULL );
> }
> else
> {
> syncInfo->si_contextdn = syncInfo->si_wbe->be_nsuffix[0];
> }
> }
> }
>
>
> We call it with
>
> setWorkingBackend( si, be );
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6 years, 1 month
Re: (ITS#8649) Issue when fetching the backend that will receive the contextCSN when we have glued databases
by elecharny@gmail.com
Using a function to compute the working backend, it could be something
like :
void setWorkingBackend( syncinfo_t *syncInfo, Backend *backend )
{
if ( !syncInfo->si_wbe )
{
if ( SLAP_GLUE_SUBORDINATE( backend ) && !overlay_is_inst(
backend, "syncprov" ) )
{
// The backend has a parent backend, fetch it. Note that we
want to get the
// top parent, not one of the intermediary subordinate,
unless one of them
// has a syncprov overlay declared. If the top level backend
// does not have a syncprov overlay declared, then we use
the local DB
// as a working backend.
BackendDB *currentBackend = backend;
struct berval bv;
ber_str2bv( currentBackend->be_nsuffix[0].bv_val, 0, 0, &bv );
dnParent( &bv, &bv );
while ( ( currentBackend = select_backend( &bv, 0 ) ) != NULL )
{
if ( overlay_is_inst( currentBackend, "syncprov" ) )
{
syncInfo->si_wbe = currentBackend;
break;
}
dnParent( &bv, &bv );
}
if ( syncInfo->si_wbe == NULL )
{
syncInfo->si_wbe = backend;
}
}
else
{
syncInfo->si_wbe = backend;
}
if ( SLAP_SYNC_SUBENTRY( syncInfo->si_wbe ) )
{
build_new_dn( &syncInfo->si_contextdn,
&syncInfo->si_wbe->be_nsuffix[0], (struct berval *)
&slap_ldapsync_cn_bv, NULL );
}
else
{
syncInfo->si_contextdn = syncInfo->si_wbe->be_nsuffix[0];
}
}
}
We call it with
setWorkingBackend( si, be );
--
Emmanuel Lecharny
Symas.com
directory.apache.org
6 years, 1 month
(ITS#8649) Issue when fetching the backend that will receive the contextCSN when we have glued databases
by elecharny@apache.org
Full_Name: Emmanuel L.charny
Version: 2.4.45
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (176.154.3.51)
When syncrepl is started, it first searches which backend will host the
contextCSN. There are two factors in play :
- do we have a syncprov overlay
- do we have parent backends.
If the local DB is a subordinate, then we have to look in its parents to see if
one of them has a syncprov overlay. If so, then this backend will be the one
receiving the contextCSN. Otherwise, the local DB will.
Now, if we have a hierarchy of backends (ie, 3 or more subordinates in a chain),
with the syncprov overlay present in an intermediate backend, then the
contextCSN will not be attached to it, but to the local DB.
This is because the select_backend( &backend->be_nsuffix[0], 1 ) function tries
to fetch the top level backend, regardless the presence of the syncprov overlay
in intermediary subordinates.
IMO, instead of calling select_backend with the parameter 1 (is, subs), we
should call it recursively up to the point we reach the top level or we find a
backend with the syncprov overlay.
6 years, 1 month
Re: (ITS#8648) sasl_client_init called concurrently causes issues
by ryan@nardis.ca
On Fri, Apr 28, 2017 at 04:43:33AM +0000, ryan(a)openldap.org wrote:
>If I'm right about this bug, I suppose the right fix is to wrap sasl_client_init
>in a new mutex.
... of course that idea's half-baked, because libldap doesn't *have*
mutexes. hmm.
I tried cyrus-sasl-2.1.25 and the issue doesn't seem to happen. I'll see
if I can isolate the related change.
6 years, 1 month
(ITS#8648) sasl_client_init called concurrently causes issues
by ryan@openldap.org
Full_Name: Ryan Tandy
Version: RE24 (66d107e)
OS: Debian
URL:
Submission from: (NULL) (24.68.41.160)
Submitted by: ryan
Test program uploaded to the FTP site:
ftp://ftp.openldap.org/incoming/20170427_rtandy_sasltest.c
I have built cyrus-sasl and openldap myself from clean sources in order to rule
out issues introduced by Debian patches. My environment is Debian unstable with
OpenSSL 1.0.2k.
cyrus-sasl master at 04dd838
./autogen.sh CFLAGS="-g -O0" --with-devrandom=/dev/urandom
make
sudo make install
sudo ldconfig
export SASL_PATH=/usr/local/lib/sasl2
openldap RE24 at 66d107e
./configure CFLAGS="-g -O0" --disable-backends --enable-mdb --disable-overlays
--with-cyrus-sasl --with-tls=openssl
make
sudo make STRIP= install
sudo ldconfig
cat > slapd.conf << 'eof'
include servers/slapd/schema/core.schema
include servers/slapd/schema/cosine.schema
sasl-secprops none
authz-regexp uid=(.*),cn=.*,cn=auth ldap:///dc=example,dc=com??sub?(uid=$1)
database mdb
directory .
suffix dc=example,dc=com
rootdn cn=root,dc=example,dc=com
index objectClass eq
eof
/usr/local/sbin/slapadd -f slapd.conf << eof
dn: dc=example,dc=com
objectClass: domain
dc: example
dn: uid=admin,dc=example,dc=com
objectClass: account
objectClass: simpleSecurityObject
uid: admin
userPassword: admin
eof
/usr/local/libexec/slapd -h ldap://:9000 -f slapd.conf -s0 -dstats
# allow PLAIN
export LDAPSASL_SECPROPS=none
# verify authz-regexp. should return uid=admin,dc=example,dc=com
ldapwhoami -H ldap://:9000 -Y PLAIN -U admin -w admin
# edit sasltest.c and change defines as needed. remove -DSASL to use simple
bind
cc -g -DSASL sasltest.c -pthread -llber -lldap -lsasl2 -o sasltest
./sasltest
On my system, most runs of ./sasltest result in errors like:
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
Aborted
With no concurrency (THREADS defined to 1), I see no errors.
I believe this is due to sasl_client_init being called from multiple threads
concurrently. I suspect the global mech list is getting mucked with.
As a proof of concept, I patched libldap to call sasl_client_init during its
global init:
ftp://ftp.openldap.org/incoming/20170427_rtandy_call-sasl_client_init-in-...
With this change, I see no errors.
If I'm right about this bug, I suppose the right fix is to wrap sasl_client_init
in a new mutex. I'll post a patch for review soon.
6 years, 1 month
Re: (ITS#8646) openldap aborts with ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36
by quanah@symas.com
--On Thursday, April 27, 2017 1:01 PM +0000 kavyauk(a)gmail.com wrote:
> Full_Name: Kavya U K
> Version: 2.4.33
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (72.163.220.19)
>
>
> Our application uses openladp library to LDAP authentication .
>
> Intermittently application crashes with below back trace .
>
> backtrace
> ===================================
># 0 0x008b1266 in raise () from /lib/libc.so.6
># 1 0x008b2c31 in abort () from /lib/libc.so.6
># 2 0x008aa49d in __assert_fail () from /lib/libc.so.6
># 3 0x00a3e056 in ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36
>
> Please let us know how to resolve it
As noted by Michael, you're using an ancient, unsupported release. There
also is not enough detail here to do anything actionable. If you can
reproduce this issue with the current release of OpenLDAP, then please
ensure that you are able to provide a backtrace that contains full
debugging symbols, as discussed in
<http://www.openldap.org/faq/data/cache/59.html>.
For now, this ITS will be closed. Please reply to the ITS with the full
backtrace information if you can reproduce with the current OpenLDAP
release and we will reopen for investigation.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 1 month
Re: (ITS#8647) support of weak ciphers according to rfc4513
by quanah@symas.com
Hello,
Thanks for your report. The IETF is the correct organization to report RFC
issues to, rather than the OpenLDAP Foundation. I would suggest you
redirect this to them. This ITS will be closed.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 1 month