Re: (ITS#8365) test061 failing
by quanah＠zimbra.com
--On Sunday, January 31, 2016 5:24 PM +0000 ryan(a)openldap.org wrote:
> Full_Name: Ryan Tandy
> Version: 2.4.43
> OS: Debian
> URL:
> Submission from: (NULL) (24.68.37.4)
> Submitted by: ryan
>
>
> Testing RE24 discovered that test061 fails sometimes:
>
> ERROR: Entry 10 not removed on ldap://localhost:9012/! (RC=0)
>
> Quanah confirmed this with 2.4.43, and also found that 2.4.42 is not
> affected.
>
> Reverting 683c03fb "ITS#8281 fix delta-mmr with interrupted refresh"
> seems to cure it for me.
I was thinking perhaps a timing issue, but even after giving it up to 55
seconds to replicate, I still hit failures:
Running 53 of 500 iterations
Running defines.sh
Initializing server configurations
Starting provider slapd on ldap://localhost:9011/
Starting forward1 slapd on ldap://localhost:9013/
Starting consumer slapd on ldap://localhost:9012/
Adding schema on ldap://localhost:9011/
Adding backend module on ldap://localhost:9011/...
Adding schema on ldap://localhost:9012/
Adding backend module on ldap://localhost:9012/...
Adding schema on ldap://localhost:9013/
Adding backend module on ldap://localhost:9013/...
Adding database configuration on ldap://localhost:9011/
Populating provider on ldap://localhost:9011/
Adding database configuration on ldap://localhost:9013/
Adding database configuration on ldap://localhost:9012/
Using ldapsearch to check that ldap://localhost:9013/ received database...
Using ldapsearch to check that ldap://localhost:9012/ received database...
Waiting 1 seconds for slapd to receive database...
Running 1 of 1 syncrepl initiation race tests...
Stopping forwarders for add test
Using ldapadd to add 10 entries on provider
Starting forwarders again
Using ldapadd to add 10 more entries on provider
Checking replication to ldap://localhost:9013/
Checking replication to ldap://localhost:9012/
Stopping forwarders for add/delete test
Using ldapadd to add 10 entries on provider
Using ldapdelete to delete 10 entries on provider
Starting forwarders again
Using ldapadd to add 10 more entries on provider
Using ldapdelete to delete 10 more entries on provider
Checking replication to ldap://localhost:9013/
Checking replication to ldap://localhost:9012/
Waiting 1 seconds for ldap://localhost:9012/ to delete entry 10...
Waiting 2 seconds for ldap://localhost:9012/ to delete entry 10...
Waiting 3 seconds for ldap://localhost:9012/ to delete entry 10...
Waiting 4 seconds for ldap://localhost:9012/ to delete entry 10...
Waiting 5 seconds for ldap://localhost:9012/ to delete entry 10...
Waiting 6 seconds for ldap://localhost:9012/ to delete entry 10...
Waiting 7 seconds for ldap://localhost:9012/ to delete entry 10...
Waiting 8 seconds for ldap://localhost:9012/ to delete entry 10...
Waiting 9 seconds for ldap://localhost:9012/ to delete entry 10...
Waiting 10 seconds for ldap://localhost:9012/ to delete entry 10...
ERROR: Entry 10 not removed on ldap://localhost:9012/! (RC=0)
Error found after 1 of 1 iterations
Failed after 53 of 500 iterations
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
A division of Synacor, Inc
7 years, 10 months
(ITS#8366) test061 failing
by ryan＠openldap.org
Full_Name: Ryan Tandy
Version: 2.4.43
OS: Debian
URL:
Submission from: (NULL) (24.68.37.4)
Submitted by: ryan
Testing RE24 discovered that test061 fails sometimes:
ERROR: Entry 10 not removed on ldap://localhost:9012/! (RC=0)
Quanah confirmed this with 2.4.43, and also found that 2.4.42 is not affected.
Reverting 683c03fb "ITS#8281 fix delta-mmr with interrupted refresh" seems to
cure it for me.
7 years, 10 months
(ITS#8365) test061 failing
by ryan＠openldap.org
Full_Name: Ryan Tandy
Version: 2.4.43
OS: Debian
URL:
Submission from: (NULL) (24.68.37.4)
Submitted by: ryan
Testing RE24 discovered that test061 fails sometimes:
ERROR: Entry 10 not removed on ldap://localhost:9012/! (RC=0)
Quanah confirmed this with 2.4.43, and also found that 2.4.42 is not affected.
Reverting 683c03fb "ITS#8281 fix delta-mmr with interrupted refresh" seems to
cure it for me.
7 years, 10 months
Re: (ITS#8364) [PATCH] back-meta idassert-bind tls_reqcert=never bug
by mohammad＠securiteam.io
Oh, thanks for clearing up the confusion, then is there anyway to
prevent openldap from sending its server certificate as a client one
when connecting to the meta target? I mean other than changing the
TLSVerifyClient on the remote host as we don't have access to do this.
Regards,
Quoting Howard Chu <hyc(a)symas.com>:
> mohammad(a)securiteam.io wrote:
>> Full_Name: Mohammad Nweider
>> Version: master
>> OS: Redhat Linux
>> URL:
>> https://www.securiteam.io/contribs/openldap/mohammad-20160131-0001-fix-ba...
>> Submission from: (NULL) (89.100.154.148)
>>
>>
>> Hello,
>>
>> We've found a small bug when trying to run openldap with meta
>> backend, what we
>> were trying to achieve is to have our server listens on ssl/tls port and to
>> communicate with the meta targets over ssl/tls as well, but due to
>> the fact that
>> we're using a self-signed certificate and we don't have access to manage the
>> meta targets, we wanted to skip the client certificate verification when
>> connecting to the meta targets, so we tried adding idassert-bind
>> tls_reqcert=never to our meta config for this purpose, but unfortunately it
>> didn't work as expected.
>
> There is no bug here. The tls_reqcert setting controls whether the
> local node requires the remote target to provide a valid server
> certificate. It has nothing to do with client certificates at all.
>
>> Whenever openldap has a certificate/key either in
>> TLSCertificateFile/TLSCertificateKeyFile or in idassert-bind
>> tls_cert/tls_key
>> settings, it completely ignores tls_reqcert in idassert-bd%d!
>
> Because the reqcert setting has nothing to do with this.
>
> Closing this ITS.
>
> --
> -- 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, 10 months
Re: (ITS#8364) [PATCH] back-meta idassert-bind tls_reqcert=never bug
by hyc＠symas.com
mohammad(a)securiteam.io wrote:
> Full_Name: Mohammad Nweider
> Version: master
> OS: Redhat Linux
> URL: https://www.securiteam.io/contribs/openldap/mohammad-20160131-0001-fix-ba...
> Submission from: (NULL) (89.100.154.148)
>
>
> Hello,
>
> We've found a small bug when trying to run openldap with meta backend, what we
> were trying to achieve is to have our server listens on ssl/tls port and to
> communicate with the meta targets over ssl/tls as well, but due to the fact that
> we're using a self-signed certificate and we don't have access to manage the
> meta targets, we wanted to skip the client certificate verification when
> connecting to the meta targets, so we tried adding idassert-bind
> tls_reqcert=never to our meta config for this purpose, but unfortunately it
> didn't work as expected.
There is no bug here. The tls_reqcert setting controls whether the local node
requires the remote target to provide a valid server certificate. It has
nothing to do with client certificates at all.
> Whenever openldap has a certificate/key either in
> TLSCertificateFile/TLSCertificateKeyFile or in idassert-bind tls_cert/tls_key
> settings, it completely ignores tls_reqcert in idassert-bd%d!
Because the reqcert setting has nothing to do with this.
Closing this ITS.
--
-- 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, 10 months
(ITS#8364) [PATCH] back-meta idassert-bind tls_reqcert=never bug
by mohammad＠securiteam.io
Full_Name: Mohammad Nweider
Version: master
OS: Redhat Linux
URL: https://www.securiteam.io/contribs/openldap/mohammad-20160131-0001-fix-ba...
Submission from: (NULL) (89.100.154.148)
Hello,
We've found a small bug when trying to run openldap with meta backend, what we
were trying to achieve is to have our server listens on ssl/tls port and to
communicate with the meta targets over ssl/tls as well, but due to the fact that
we're using a self-signed certificate and we don't have access to manage the
meta targets, we wanted to skip the client certificate verification when
connecting to the meta targets, so we tried adding idassert-bind
tls_reqcert=never to our meta config for this purpose, but unfortunately it
didn't work as expected.
Whenever openldap has a certificate/key either in
TLSCertificateFile/TLSCertificateKeyFile or in idassert-bind tls_cert/tls_key
settings, it completely ignores tls_reqcert in idassert-bd%d!
to reproduce you can just try to build your server with ssl/tls enabled, add the
tls global/server settings:
TLSCACertificateFile /usr/local/etc/openldap/cacert.pem
TLSCertificateFile /usr/local/etc/openldap/servercrt.pem
TLSCertificateKeyFile /usr/local/etc/openldap/serverkey.pem
add some meta backend targets over ldaps with idassert-bind tls_reqcert=never:
database meta
suffix "dc=foo,dc=com"
uri "ldaps://a.bar.com/dc=foo,dc=com"
suffixmassage "dc=foo,dc=com" "dc=bar,dc=org"
idassert-bind tls_reqcert=never
Enable debugging and try to run some queries against your meta db. You will see
a client certificate is sent to the meta target even with tls_reqcert=never!
The mplelest fix I could come up with is to add the certificate/key to the ssl
context only when is_server or lo->ldo_tls_require_cert is not zero like in the
attached patch.
Please let me know if I'm misunderstanding something or if this use case can be
solved/achieved without this patch.
Thanks,
7 years, 10 months
Re: (ITS#8354) syncprov segv
by quanah＠zimbra.com
--On Wednesday, January 27, 2016 9:33 AM +0000 Thomas Pressnell
<tpretz(a)gmail.com> wrote:
>> Hi Tom,
>>
>> Are you able to confirm if the fix is good? I'm working on 2.4.44, and
>> want to be sure this fix is included.
>
> I'v had an instance running with this patch for a few days, no SEGV,
> looks good to me.
Great, thanks for confirming. :)
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 10 months
