November 2008 - openldap-bugs

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

1
0
0 / 0

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

1
0
0 / 0

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

1
0
0 / 0

RE: (ITS#5788) Search does not work with nested naming contexts

by emmanuel.duru＠atosorigin.com

OK, thank you. I didn't see this configuration directive in the admin guide... > # need to inform slapd that this DB is subordinate > subordinate

14 years, 7 months

1
0
0 / 0

Re: (ITS#5745) slapcat doesn't return correct error status for bdb fatal error

by hyc＠symas.com

Guillaume Rousse wrote: > Howard Chu a écrit : >> 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. OK, fixed now in HEAD. -- -- 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

1
0
0 / 0

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

1
0
0 / 0

(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

1
0
0 / 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates

by toby＠inf.ed.ac.uk

Hi there, is there any further debugging I could usefully carry out for this issue, or does it need someone who understands the code a bit better? Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

14 years, 7 months

1
0
0 / 0

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

1
0
0 / 0

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

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2008