openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by ando＠sys-net.it 04 Nov '08

04 Nov '08

toby(a)inf.ed.ac.uk wrote: > 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? It's not a debugging problem, but rather a design issue. The current design makes use of the first AVA of the filter to decide how two filters are compared. In your case, the first component is common to all filters, so only the first occurrence of a search with that template can be cached. This fact, to my knowledge, is undocumented, but there's little to do except redesign this weighing criterium. As I already pointed out, you need to make the most significant filter AVA appear first in your filter template. Unless anyone voluteers for a complete redesign [*] of this portion of slapo-pcache(5), I take your ITS as a request to document this aspect of template design. p. [*] a complete redesign could also get rid of strict ordering of filter AVAs, allow "static" portions of the filter (something like (&(objectClass=person)(uid=)) and so) and other relatively unfriendly aspects of slapo-pcache(5) configuration. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5787) few improvements
by ando＠sys-net.it 04 Nov '08

04 Nov '08

Few improvements here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-cf-2008-11-04.tar.gz> (allow digit substitutions, introduced to avoid collisions). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5789) using IP address in CN with GnuTLS
by leva＠ecentrum.hu 04 Nov '08

04 Nov '08

Full_Name: LÉVAI Dániel Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.131.56.68) I'm using OpenLDAP 2.4.11 on a Debian testing/lenny system. The GnuTLS version is 2.4.2. So I'm having a lot of problems using OpenLDAP with GnuTLS, and I've decided to take another route in troubleshooting; I've recreated my cert/key pair, using my machine's ip address in the CN field. The weirdest thing happened: $ ldapsearch -d 1 -ZZWx '(objectclass=*)' -H ldap://192.168.1.3 ldap_url_parse_ext(ldap://192.168.1.3) ldap_create ldap_url_parse_ext(ldap://192.168.1.3:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 192.168.1.3:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.1.3:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x6120a0 msgid 1 wait4msg ld 0x6120a0 msgid 1 (infinite timeout) wait4msg continue ld 0x6120a0 msgid 1 all 1 ** ld 0x6120a0 Connections: * host: 192.168.1.3 port: 389 (default) refcnt: 2 status: Connected last used: Fri Oct 31 22:36:46 2008 ** ld 0x6120a0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x6120a0 request count 1 (abandoned 0) ** ld 0x6120a0 Response Queue: Empty ld 0x6120a0 response count 0 ldap_chkResponseList ld 0x6120a0 msgid 1 all 1 ldap_chkResponseList returns ld 0x6120a0 NULL ldap_int_select read1msg: ld 0x6120a0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x6120a0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x6120a0 0 new referrals read1msg: mark request completed, ld 0x6120a0 msgid 1 request done: ld 0x6120a0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: hostname (192.168.1.3) does not match common name in certificate (192.168.1.3). ldap_err2string ldap_start_tls: Connect error (-11) So it seems, according to OpenLDAP, 192.168.1.3 != 192.168.1.3. Why is that? And please allow me include some additional information, which was told me by Philip Guenther on openldap-software@: "It appears the routine used with GNUtls refuses to match IP addresses against a CN subjects component, thus explaining that weird message. (In ldap_pvt_tls_check_hostname(), 'len1' is only non-zero if the hostname doesn't look like an IPv6 or IPv4 address, while the subject CN test needs 'len1' to be the same as the length of the CN value.)" Daniel

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs