openldap-devel

openldap-devel@openldap.org

1416 discussions

Re: commit: ldap/servers/slapd aci.c at.c schema_init.c schemaparse.c slap.h syntax.c
by Kurt Zeilenga 17 May '07

17 May '07

On May 15, 2007, at 4:40 PM, ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > aci.c 1.19 -> 1.20 > at.c 1.96 -> 1.97 > schema_init.c 1.397 -> 1.398 > schemaparse.c 1.83 -> 1.84 > slap.h 1.815 -> 1.816 > syntax.c 1.45 -> 1.46 > > Log Message: > allow attribute inheritance with syntax restriction (please review) > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/aci.c > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/at.c > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ > schema_init.c > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ > schemaparse.c > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/slap.h > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/syntax.c > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. > Kind of in right vein, but a bit off. An attribute of syntax X can only be a subtype of an attribute of syntax Y if Y is a more generic syntax. In particular, all abstract values representable in X must be representable in Y. While both printable string and directory string syntaxes are more generic than country string, directory string is not more generic than printable string. This is because printable string can represent zero length character strings and directory string cannot. So, what needed, for each syntax, is a list of more generic syntaxes. -- Kurt

2 2

Stale and New Docs
by Gavin Henry 17 May '07

17 May '07

Dear All, My first thing planned is a doc for "Replacing Slurpd" in the Replication section of the new TOC I posted. Anyone got a working config for an example, rather than me chopping bits from the tests. Also, anyone got any part-finished docs lying about, but not had time to finish. Lastly, I'd like to get some translators on board when the guide is more complete (2.4). What languages would we like? 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/

2 2

Restore slapd.replog(5) manpage?
by Hallvard B Furuseth 16 May '07

16 May '07

HEAD/servers/slurpd is gone, but ldapmodify still supports "replica" lines. Which I guess makes sense - someone may use a new client with an older server. So maybe the replog manpage should stay for a while too. (Explaining that it's obsolete, with a reference to syncrepl.) -- Regards, Hallvard

3 3

Re: commit: ldap/servers/slapd/overlays syncprov.c
by Howard Chu 14 May '07

14 May '07

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays > > Modified Files: > syncprov.c 1.186 -> 1.187 > > Log Message: > ITS#4961 disable schema checking on contextCSN update That may have been premature, need to see why the glue entry has no objectclass attribute. -- -- 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/

1 0

Re: commit: ldap/libraries/libldap tls.c gnutls.c
by Ralf Haferkamp 14 May '07

14 May '07

On Sunday 13 May 2007 00:15, hyc(a)openldap.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap > > Modified Files: > tls.c 1.147 -> 1.148 > Removed Files: > gnutls.c 1.3 -> NONE > > Log Message: > Merged GNUtls support into main tls.c This broke building with openssl. Seems to be caused by the explicit #define HAVE_GNUTLS 1 #undef HAVE_OPENSSL in there. I've removed those lines again. -- Ralf

2 1

Bind DN SSF
by Hallvard B Furuseth 13 May '07

13 May '07

A loose thought - haven't really thought it through, and don't know exactly how SSFs are used today either: I'm wondering if we need one or two "Bind DN SSF"s which describe how reliable a Bind DN is - how secure the server-side authentication system is, as well as the Bind method and connection security at the time of the Bind. Then one can set access controls, 'security' directive, and a new 'rootdn-ssf' directive which requires a certain quality of the rootdn/pw. Possibly rootdn-ssf should be nonzero by default, or nonzero by default for cn=config. The ultimate example of an insecure Bind DN is probably database config rootdn cn=foo,cn=nil # config's rootdn is very powerful database null suffix cn=nil bind on # accept any password for any DN which hopefully doesn't happen outside tests. (That's why this occurred to me, I'd like to support cd tests/ && ./run -b null. Not when one could accidentally write a test like this, though.) There are other reasons the quality of the authentication or password store might differ - different authentication methods, a sloppily-written back-perl instance, whatever. So as a source of the Bind DN SSF one would configure SSFs to subsystems used for authentication - databases, SASL, etc. -- Regards, Hallvard

1 0

Re: commit: ldap/servers/slapd schema_init.c
by Howard Chu 12 May '07

12 May '07

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > schema_init.c 1.395 -> 1.396 > > Log Message: > Use liblber for certificate Validation, Normalization These functions are no longer dependent on HAVE_TLS. I've only tested with X509v3 certificates, it probably needs a shakedown with X509v1 and X509v2 certs. Along with the other changes to integrate GNUtls support, I've changed the ldap_X509dn2bv function to expect a DER format berval for input. We no longer use OpenSSL-specific X509_NAME structures anywhere. -- -- 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/

1 0

back-monitor and "" rooted DBs
by Quanah Gibson-Mount 09 May '07

09 May '07

I have a database rooted at "", and would like to use the monitor backend as well. I found that if I put "database monitor" before the 'database ""' definition, it will load just fine. However, if it is defined afterwards, it fails to load, since "" overloads it context. I understand that that is correct from a technical standpoint, but IIRC, there have been issues in the past having "database monitor" come before other database definitions. I thought it would be worthwhile to allow "database monitor" to be instantiated after a 'database ""' definition. Thoughts? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

3 2

tpool.c without a pool
by Hallvard B Furuseth 02 May '07

02 May '07

Has anyone got a variant of tpool.c which has the current interface but creates a new thread per operation instead of using a pool? (I'm trying to track down a memory corruption issue which disappears with --disable-threads, and I'm hoping the load of complaints from 'valgrind-2.2.0 --tool=helgrind' is due to the thread pool rather than genuine bugs or code which Helgrind can't deal with.) -- Regards, Hallvard

1 0

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel