openldap-bugs November 2008

openldap-bugs@openldap.org

44 participants
242 discussions

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 04 Nov '08

04 Nov '08

Howard Chu wrote : >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. Hi Howard, Thanks for the corrections. We tested the HEAD extracted on monday november 3. Unfortunately the problem explained in point 2 persists (even after a clean shutdown). Our directory contains 10 million entries. It can evolve to 40 million entries next year. The local sacanning speed is around 250 000 entries per minute. So the scan of the recent objects on the standby mirror after startup can take several minutes (unless if we distribute the write operations on both mirrors). Best Regards Ali

1 0

Re: (ITS#5709) slapd sync provider skips some objects
by sylvain.thomas＠gmail.com 04 Nov '08

04 Nov '08

We tested the HEAD version extracted november 4th : the problem is fixed. The ITS can be closed. thank you for your help ! Best regards Sylvain Thomas

1 0

Re: (ITS#5789) using IP address in CN with GnuTLS
by hyc＠symas.com 04 Nov '08

04 Nov '08

leva(a)ecentrum.hu wrote: > 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 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.)" Thanks for the report, now fixed in HEAD. Note that using an IP address in the CN is not the way you're supposed to generate certs; IP addresses belong in the subjectAltName extension. The CN is only supposed to contain a fully qualified domain name. -- -- 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

(ITS#5791) searches with entryDN in the filter scan the whole db
by ando＠sys-net.it 04 Nov '08

04 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando Filtering for entryDN equality requires scanning the whole DB, although dn's are indexed in dn2id. See also ITS#5790

1 0

(ITS#5790) Indexing for entryDN results in no entry found
by ando＠sys-net.it 04 Nov '08

04 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando If an explicit equality index is set for entryDN, searches with entryDN in the filter find no entries.

1 0

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

04 Nov '08

On 4 Nov 2008, at 09:26, Pierangelo Masarati wrote: > 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. The problem with changing the ordering in the template is that it then doesn't match the real lookups that occur and so the entries aren't cached - this is something over which I have no control - e.g. queries generated by 'ls -l', or by somebody logging into the machine, etc, etc. This is why we have the filters this way. e.g. sshing into one of our scientific linux 5.2 hosts generates the following lookups: [sybies]toby: grep 'query template' ~/tmp/pcache-login |cut -d' ' -f13| sort|uniq -c 1 (&(objectClass=)(cn=)) 2 (&(objectClass=)(|(memberUid=)(uniqueMember=))) 28 (&(objectClass=)(uid=)) 5 (&(objectClass=)(uidNumber=)) 26 (&(objectClass=)(uniqueMember=)) [sybies]toby: Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

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

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 November 2008