openldap-devel April 2007

openldap-devel@openldap.org

10 participants
8 discussions

Default threads value in OpenLDAP
by Quanah Gibson-Mount 23 Apr '07

23 Apr '07

After extensive benchmarking by both Howard & I, it seems the default value for the threads setting in OpenLDAP (16) is excessive for most hardware. Unless someone has plenty of CPUs (at least 4+, not counting fake HT CPUs), slapd performance is significantly improved by running at 8 threads. Recent tests done by Howard indicated that dropping the number of threads to 4 on my 2 CPU boxes further improved read performance, but I haven't had the time to do the corresponding write performance tests to see how they were impacted. In any case, the "8" value is definitely better for both read & write performance for 1 & 2 CPU servers (and possibly 4, I just haven't had one to experiment on). The only time I've found a need to increase the number of threads was when I was benchmarking the Sun T2000, which had 32 cores. Given all of this, I'd like to propose that we change SLAP_MAX_WORKER_THREADS in slap.h from 16 to 8 for OpenLDAP 2.4. Thoughts? --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

5 12

access ... by certificate=...
by Hallvard B Furuseth 22 Apr '07

22 Apr '07

Sorry if I asked about this before and forgot it... Could we add an 'access ... by' variant for the client's TLS certificate, _without_ Bind:SASL/EXTERNAL? (To the cert's DN, I expect, but I don't know much about certificates. Maybe there are other things to look at as well.) That could be used to authenticate a service (an LDAP client) rather than the user it Binds as, when the service asks the user for password and Binds with his DN and password. The simple way to do that is to grant access to the service's IP address, but that's not always feasible, and gets hard to maintain. -- Regards, Hallvard

2 3

IRC meeting to discuss Google Funding Proposal?
by Gavin Henry 11 Apr '07

11 Apr '07

Hi All, To speed things along as e-mail can take a wee while, why don't we try and get ourselves together for an irc session? We can go over the details of the proposal etc. then. Time/Date? Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Funding proposal for OpenLDAP Build Farm
by Gavin Henry 11 Apr '07

11 Apr '07

Dear All, I've mentioned this in passing to Howard and he was going to have a wee chat with the Samba guys at SambaXP about theirs: http://build.samba.org So I popped into #samba-technical and asked about setting the above up. Few guys asked what for, and Jeremy Allison (http://samba.org/~jra/ and Google, in case you didn't know ;-) ) asked me to ping him a serious funding proposal: <snip irc> <wanon> did someone ask for money.... ? <ghenry> wanon: got some? ;-) <wanon> This is OpenLDAP right ? <ghenry> yup <wanon> put a proposal togther. A *serious* one, and mail it to me. <ghenry> wanon: Will do <ghenry> wanon: Tips? <ghenry> wanon: Should I google for your address? ;-) <ghenry> heh <wanon> Ask for a concrete amount, and give explicit reasons why you want it. <ghenry> Business plan? Or one pager? <wanon> One pager to start. <ghenry> Ok. Google funding, correct? <ghenry> excuse me if I should know, sorry <wanon> yep <ghenry> would you be kind enough to msg me your e-mail? <wanon> just google for it. <ghenry> heh, ok <wanon> or use my samba.org address * abartlet remembers the days when we didn't know who wanon was :-) <ghenry> So, funding proposal for OpenLDAP Build Farm. Thanks wanon <ghenry> going to post to openldap-devel then go from there with rest of team. thanks again all (abartlet wanon) <wanon> ok, works for me ! So, can we put a serious one together and get a build farm! Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

4 5

slurpd in RE24
by Howard Chu 09 Apr '07

09 Apr '07

Since we haven't been fixing any slurpd bugs lately, it doesn't seem like a good idea to continue releasing it. I'd like to cvs rm it from HEAD and RE24. Comments? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

6 13

Re: commit: ldap/servers/slapd/overlays unique.c
by Hallvard B Furuseth 09 Apr '07

09 Apr '07

hyc(a)OpenLDAP.org wrote: > unique.c 1.24 -> 1.25 > Enhanced unique configuration The unique_modify() change is wrong. Originally noticed it because gcc -Wformat complained, but there is more. Two sprintfs without the destination buffer argument, presumably it should be 'kp'. You initialize kp after a sprintf statement which I assume uses it. And the statements seem in wrong order. A suggested patch is appended - though note that I haven't actually looked at the logic of the function, just a brief glance on what seems to make the filter creation code look sensible. -- Regards, Hallvard --- servers/slapd/overlays/unique.c~ +++ servers/slapd/overlays/unique.c @@ -1143,7 +1143,7 @@ key = op->o_tmpalloc(ks, op->o_tmpmemctx); - if ( uri->filter && uri->filter->bv_len ) - kp += sprintf ("(&(%s)", uri->filter->bv_val); kp = key + sprintf(key, "(|"); + if ( uri->filter && uri->filter->bv_len ) + kp += sprintf(kp, "(&(%s)", uri->filter->bv_val); for(m = op->orm_modlist; m; m = m->sml_next) @@ -1157,7 +1157,7 @@ op->o_tmpmemctx ); - kp += sprintf (kp, ")"); if ( uri->filter && uri->filter->bv_len ) kp += sprintf (kp, ")"); + kp += sprintf (kp, ")"); rc = unique_search ( op, @@ -1260,7 +1260,7 @@ key = op->o_tmpalloc(ks, op->o_tmpmemctx); - if ( uri->filter && uri->filter->bv_len ) - kp += sprintf ("(&(%s)", uri->filter->bv_val); kp = key + sprintf(key, "(|"); + if ( uri->filter && uri->filter->bv_len ) + kp += sprintf(kp, "(&(%s)", uri->filter->bv_val); for ( i=0; newrdn[i]; i++) { @@ -1274,7 +1274,7 @@ } - kp += sprintf(kp, ")"); if ( uri->filter && uri->filter->bv_len ) kp += sprintf (kp, ")"); + kp += sprintf(kp, ")"); rc = unique_search ( op,

1 0

Please test RE23
by Howard Chu 06 Apr '07

06 Apr '07

I'd like us to get 2.3.35 out soon. And send an email if you know of any outstanding bugs in ITS that aren't yet in RE23 that you think should be. Thanks. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 2

Re: (ITS#4879) URL parse/unparse troubles
by Howard Chu 03 Apr '07

03 Apr '07

Howard Chu wrote: >> The RFCs 4516/2255 hostport part has grammar [host [":" port]], >> but ldap_url_desc2str() produces [host][":" port]. >> >> ldap:// -> host NULL, port 389 -> >> ldap://:389/??base >> >> That's OK as an ldap_url_parse() OpenLDAP extension, but not as >> ldap_url_desc2str() output given to non-OpenLDAP applications. > > This is a mess. The ldap: scheme definition has always been broken, and > it certainly does not conform to the basic URI syntax in RFC3986 section > 3. In particular, RFC3986 forbids a URI from containing "//" when the > authority component is absent. Looks like RFC4516 should not have been > approved in its current state. Stupid little things like this make me wonder WTF were they smoking when they created LDAP. I no longer ask myself wtf they were thinking, because clearly they weren't... DNs should have been left in canonical filesystem order, like X.500 tools used. Then we could just treat LDAP URLs like every other hierarchical URL namespace, with relative paths and all the other associated conveniences, and use a single generic parser to handle it all. It's all so damned moronic. It's almost aggravating enough to make me switch to pure DAP and leave all of this cruft behind. Mebbe it's time to add a config switch somewhere to set all of slapd and the libraries to default to DCE/X.500 format DNs, and define a new "xdap" URL scheme to go with it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel April 2007