Re: (ITS#5749) client didn't send its own certificate to the server
by hyc@symas.com
bugs(a)shiva.hostoffice.hu wrote:
> Full_Name: Gabor Mayer
> Version: 2.4.11
> OS: debian
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (91.120.131.147)
>
>
> i discovered it when i turned on the peer verification at server side.
>
> i'm using the following configuration at client side:
>
> ldap.conf:
>
> BASE dc=example,dc=org
> URI ldaps://ldap.example.org
>
> TLS_CACERT /etc/ldap/server.crt
>
> /root/.ldaprc:
>
> TLS_CERT /etc/ldap/client.crt
> TLS_KEY /etc/ldap/client.key
>
> i tried TLS_CERT& TLS_KEY in ldap.conf and in .ldaprc without success.
>
> i tested it with ldapsearch -x and i got the following debug message at server
> if the TLSVerifyClient was turned on:
>
> TLS trace: SSL3 alert write:fatal:handshake failure
> TLS trace: SSL_accept:error in SSLv3 read client certificate B
> TLS: can't accept.
> TLS: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return
> a certificate s3_srvr.c:2455
>
> i captured the tcp flow at client side and i saw the server's certificate only.
> the client didn't send its own certificate to the server!
Works for me on Ubuntu 8.10 using GNUtls 2.4.1. I suggest you contact the
Debian folks about this. This ITS will be closed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 7 months
Re: (ITS#5739) "host:port" does not work
by h.b.furuseth@usit.uio.no
hyc(a)symas.com writes:
> OpenLDAP has been this way since at least 2003, no one else has
> cared since then...
No, it works with 2.3.43.
And "LDAPHOST=ldap:3890 ldapwhoami -x" still works in HEAD.
It's ldap_url_desc2str() in libraries/libldap/url.c which
changed to assume IPv6 if strchr( u->lud_host, ':' ).
--
Hallvard
14 years, 7 months
Re: (ITS#5739) "host:port" does not work
by hyc@symas.com
Hallvard B Furuseth wrote:
> hyc(a)symas.com writes:
>> Why are you reporting this? "-h" has always been documented to only
>> accept a hostname,
>
> No. Look at man ldap_init:
> (...) each host may optionally by of the form host:port. If
> present, the :port overrides the port parameter (...)
>
> So sometimes this option is called hostport.
>
> It's been that way since umich ldap 3.2.
>
Perhaps so, but...
clients/tools/common.c:
1.1 (hallvard 12-Dec-02): if( ( ldaphost != NULL ||
ldapport ) && ( ldapuri == NULL ) ) {
1.26 (kurt 14-Dec-03): /* construct URL */
1.26 (kurt 14-Dec-03): LDAPURLDesc url;
1.26 (kurt 14-Dec-03): memset( &url, 0,
sizeof(url));
1.26 (kurt 14-Dec-03):
1.26 (kurt 14-Dec-03): url.lud_scheme = "ldap";
1.26 (kurt 14-Dec-03): url.lud_host = ldaphost;
1.26 (kurt 14-Dec-03): url.lud_port = ldapport;
1.26 (kurt 14-Dec-03): url.lud_scope =
LDAP_SCOPE_DEFAULT;
1.26 (kurt 14-Dec-03):
1.26 (kurt 14-Dec-03): ldapuri =
ldap_url_desc2str( &url );
OpenLDAP has been this way since at least 2003, no one else has cared since
then...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 7 months
Re: (ITS#5788) Search does not work with nested naming contexts
by ando@sys-net.it
emmanuel.duru(a)atosorigin.com wrote:
> Full_Name: Emmanuel Duru
> Version: 2.4.11
> OS: Windows
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (80.78.0.137)
>
>
> I want to run a directory server with a "c=fr" suffix, and a replicated subtree:
> "ou=test,o=myorg,c=fr".
> To do this, I define two bdb databases, the first one with a
> "ou=test,o=myorg,c=fr" suffix, the second one with a "c=fr" suffix.
> But when I perform a search, the entries from the first base are not returned.
> For example, search with base "o=myorg,c=fr" and scope one level returns
> "ou=test2,o=myorg,c=fr" but not "ou=test,o=myorg,c=fr" whereas search with base
> "ou=test,o=myorg,c=fr" returns the entry.
> If this is a configuration problem, please tell me what is wrong.
>
> Here follows my slapd.conf file:
>
> include schema/core.schema
> include schema/cosine.schema
> include schema/inetorgperson.schema
> pidfile slapd.pid
> argsfile slapd.args
> access to * attrs=userPassword
> by self write
> by anonymous auth
> by * none
> access to *
> by self write
> by users read
> by anonymous read
> by * none
> database bdb
> suffix "ou=test,o=myorg,c=fr"
# need to inform slapd that this DB is subordinate
subordinate
> rootdn "cn=manager,c=fr"
> updatedn "cn=replicator,ou=test,o=myorg,c=fr"
> cachesize 20000
> checkpoint 10000 10
> directory db1
> index objectClass,entryCSN,entryUUID eq
> index cn,sn eq,sub
> database bdb
> suffix "c=fr"
> rootdn "cn=manager,c=fr"
> rootpw {SSHA}IcRbIFvDVZ9j6g8hWK9bbgo7xhSrMMTf
> cachesize 20000
> checkpoint 10000 10
> directory db2
> index objectClass,entryCSN,entryUUID eq
> index cn,sn eq,sub
>
>
p.
14 years, 7 months
(ITS#5788) Search does not work with nested naming contexts
by emmanuel.duru@atosorigin.com
Full_Name: Emmanuel Duru
Version: 2.4.11
OS: Windows
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (80.78.0.137)
I want to run a directory server with a "c=fr" suffix, and a replicated subtree:
"ou=test,o=myorg,c=fr".
To do this, I define two bdb databases, the first one with a
"ou=test,o=myorg,c=fr" suffix, the second one with a "c=fr" suffix.
But when I perform a search, the entries from the first base are not returned.
For example, search with base "o=myorg,c=fr" and scope one level returns
"ou=test2,o=myorg,c=fr" but not "ou=test,o=myorg,c=fr" whereas search with base
"ou=test,o=myorg,c=fr" returns the entry.
If this is a configuration problem, please tell me what is wrong.
Here follows my slapd.conf file:
include schema/core.schema
include schema/cosine.schema
include schema/inetorgperson.schema
pidfile slapd.pid
argsfile slapd.args
access to * attrs=userPassword
by self write
by anonymous auth
by * none
access to *
by self write
by users read
by anonymous read
by * none
database bdb
suffix "ou=test,o=myorg,c=fr"
rootdn "cn=manager,c=fr"
updatedn "cn=replicator,ou=test,o=myorg,c=fr"
cachesize 20000
checkpoint 10000 10
directory db1
index objectClass,entryCSN,entryUUID eq
index cn,sn eq,sub
database bdb
suffix "c=fr"
rootdn "cn=manager,c=fr"
rootpw {SSHA}IcRbIFvDVZ9j6g8hWK9bbgo7xhSrMMTf
cachesize 20000
checkpoint 10000 10
directory db2
index objectClass,entryCSN,entryUUID eq
index cn,sn eq,sub
14 years, 7 months
Re: (ITS#5745) slapcat doesn't return correct error status for bdb fatal error
by Guillaume.Rousse@inria.fr
Howard Chu a écrit :
> Guillaume.Rousse(a)inria.fr wrote:
>> Full_Name: Guillaume Rousse
>> Version: 2.4.12
>> OS:
>> URL:
>> Submission from: (NULL) (193.55.250.67)
>>
>>
>> [root@etoile ~]# slapcat -b dc=msr-inria,dc=inria,dc=fr
>> ...
>> bdb(dc=msr-inria,dc=inria,dc=fr): pthread lock failed: Invalid argument
>> bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: Invalid argument
>> bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: DB_RUNRECOVERY: Fatal error, run
>> database recovery
>> bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: fatal region error detected; run
>> recovery
>> bdb_db_close: database "dc=msr-inria,dc=inria,dc=fr": close failed:
>> DB_RUNRECOVERY: Fatal error, run database recovery (-30975)
>> [root@etoile ~]# echo $?
>> 0
>>
>> It makes a bit difficult to know if slapcat-based backup were successful.
>
> How did you create this situation? I can't test a fix without some way
> to break the DB in the first place, and generally the DB doesn't fail...
I just upgraded to 2.4.12, as described at
http://www.openldap.org/lists/openldap-software/200810/msg00087.html.
--
Guillaume Rousse
Service des Moyens Informatiques
INRIA Saclay - Ile de France
Tel: 01 69 35 69 62
14 years, 7 months
Re: (ITS#5640) slapd scans too many objects at startup
by hyc@symas.com
Ali Pouya wrote:
> Howard Chu a écrit :
>> The startup scan is only performed inside the syncprov overlay. If
>> server C is only a consumer, then it does not need the syncprov overlay.
>>
> Yes, you are right for the point 1). Thank you.
>
> But I'm also bothered with the point 2) reproduced below :
>
> ....
> 2) If I do only one write operation on B, then I get two contextCSN values,
> which is normal.
>
> But il this case slapd on B scans, at each startup, all objecs written on A
> after the write operation on B.
> The log and the effect are similar to those explained above.
I see.
This has been fixed for back-bdb/hdb in HEAD. If the database was shut down
cleanly before, there will be no scan on the next startup.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 7 months