Default threads value in OpenLDAP
by Quanah Gibson-Mount
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
16 years, 1 month
access ... by certificate=...
by Hallvard B Furuseth
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
16 years, 1 month
IRC meeting to discuss Google Funding Proposal?
by Gavin Henry
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/
16 years, 1 month
Funding proposal for OpenLDAP Build Farm
by Gavin Henry
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/
16 years, 1 month
Re: commit: ldap/servers/slapd/overlays unique.c
by Hallvard B Furuseth
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,
16 years, 1 month
Re: (ITS#4879) URL parse/unparse troubles
by Howard Chu
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/
16 years, 1 month