openldap-bugs

openldap-bugs@openldap.org

1 participants
21161 discussions

Re: (ITS#5701) connection.c asserting during test008
by hyc＠symas.com 03 Nov '08

03 Nov '08

ando(a)sys-net.it wrote: > richton(a)nbcs.rutgers.edu wrote: > >> Rare connection.c assertion during test008s of RE24. Here are three different >> examples: > >> [6] monitor_subsys_conn_create(op = 0x103a359b0, rs = 0xffffffff76bff998, ndn >> = (nil), e_parent = 0x1005c03d8, ep = 0xffffffff76bff230), line 500 in "conn.c" > > >> [6] monitor_subsys_rww_update(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e = >> 0x1005c1b98), line 187 in "rww.c" > >> [7] monitor_subsys_rww_update(op = 0x100922640, rs = 0xffffffff78fff998, e = >> 0x1005c1b98), line 185 in "rww.c" > > > Sorry, I overlooked the fact that all those issues are occurring from > within back-monitor. In all cases, it's within code that loops through > the connection array using connection_{first,next,close}(). Apparently, > those calls are used in the right way. Can you print more information > about those connections? E.g. c->c_struct_state, and *index from within > connection_next()? Or even better, the whole *c structure? Looks like it may be related to #5586. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5749) client didn't send its own certificate to the server
by hyc＠symas.com 03 Nov '08

03 Nov '08

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/

1 0

Re: (ITS#5739) "host:port" does not work
by h.b.furuseth＠usit.uio.no 03 Nov '08

03 Nov '08

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

1 0

Re: (ITS#5739) "host:port" does not work
by hyc＠symas.com 03 Nov '08

03 Nov '08

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/

1 0

RE: (ITS#5788) Search does not work with nested naming contexts
by emmanuel.duru＠atosorigin.com 03 Nov '08

03 Nov '08

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

1 0

Re: (ITS#5745) slapcat doesn't return correct error status for bdb fatal error
by hyc＠symas.com 03 Nov '08

03 Nov '08

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/

1 0

Re: (ITS#5788) Search does not work with nested naming contexts
by ando＠sys-net.it 03 Nov '08

03 Nov '08

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.

1 0

(ITS#5788) Search does not work with nested naming contexts
by emmanuel.duru＠atosorigin.com 03 Nov '08

03 Nov '08

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

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk 03 Nov '08

03 Nov '08

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.

1 0

Re: (ITS#5745) slapcat doesn't return correct error status for bdb fatal error
by Guillaume.Rousse＠inria.fr 03 Nov '08

03 Nov '08

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

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs