Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr
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
14 years, 11 months
Re: (ITS#5789) using IP address in CN with GnuTLS
by hyc＠symas.com
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/
14 years, 11 months
Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk
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.
14 years, 11 months
Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by ando＠sys-net.it
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
-----------------------------------
14 years, 11 months
(ITS#5789) using IP address in CN with GnuTLS
by leva＠ecentrum.hu
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
14 years, 11 months
Re: (ITS#5701) connection.c asserting during test008
by hyc＠symas.com
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/
14 years, 11 months
