dITStructureRules/nameForms in subschema subentry for informational purpose
by Michael Ströder
HI!
Discussed this very briefly with Howard at LDAPcon 2007 based on an idea
of Steve:
Support for dITStructureRules and nameForms is still in OpenLDAP's TODO.
In the meanwhile slapd could accept definitions for both in slapd.conf
and simply pass them on to a schema-aware LDAP client for informational
purpose without enforcing them. Same function like rootDSE <file> in
slapd.conf.
Opinions?
Ciao, Michael.
--
Michael Ströder
E-Mail: michael(a)stroeder.com
http://www.stroeder.com
14 years, 6 months
managing OpenLDAP / back-config
by Ralf Haferkamp
With the great features that back-config provides to configure OpenLDAP
servers at runtime it seems logical to start thinking about providing tools
that could help to leverage those features.
Currently to manage an OpenLDAP server through back-config you have the option
to use either a generic LDAP Browser (JXplorer, Apache LDAP Studio,
web2ldap), the OpenLDAP command line tools (ldapsearch, ldapmodify, ...) or
homegrown software using one of the available LDAP APIs. I think it would be
helpful to have some more sophisticated management tools (Commandline and/or
GUI).
In order to get there I think it could be helpful to create an API dedicated
to provide an easy way to access the OpenLDAP configuration (databases,
overlays, schema, access control, ...). This API could then be used to create
different flavors of management tools.
I have not yet spend too much time thinking about the design of such an API.
Neither about the programming language that I'd use to implement something
like this (Python, C, C++, ?). I first like to get a feeling how others think
about this and if anybody is interested in collaborating on such an API. So
please feel free to reply with your comments and suggestions :)
--
regards,
Ralf
15 years, 3 months
Re: thread pools, performance
by Howard Chu
Rick Jones wrote:
> There are definitely interrupt coalescing settings available with tg3-driven
> cards, as well as bnx2 driven ones:
>
> ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt
Yep, that helped. Raising rx-usecs from default 20 to 1000, and rx-frames from
default 5 to 100, I'm getting 43k auths/sec with back-null (in 4 separate
thread pools) and the core fielding the interrupts is only about 80% busy now
instead of 100%. I'm afraid my load generators may be maxed out now, because I
can't seem to drive up the load on the server any higher even though there's
more idle CPU.
The current code in HEAD (with only 1 thread pool) is reaching 36k auths/sec
with back-null, so it's actually not far off from my experimental peak rate.
Considering that HEAD was at 25k/sec last week (and now in 2.4.6) that's
pretty decent.
With back-bdb and 1 million users I'm getting 26.1k/sec with plaintext
passwords (up from 19.3k/sec last week). With {SSHA} passwords that drops to
25.7k/sec (~1.5% difference).
I have to put this tinkering on hold for a bit, to run some authrate tests
against ActiveDirectory on this machine (using W2K3sp2 X64). Later on we'll do
a W2K3 OpenLDAP build for comparison as well. Should be entertaining...
--
-- 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/
15 years, 7 months
Overlay question
by luca regini
Is it possible for an overlay to detect the type of the underlying backend?
In the case the answer is affermative and the backend is a bdb is it
possible to programmatically force the bdb to save an entry created at
runtime?
Thanks in advance,
Luca Regini
15 years, 8 months
[Fwd: Re: Likewise has added GSS-SPNEGO support to openldap libraries]
by Howard Chu
This sounds redundant to me, given that OpenLDAP interfaces to GSS thru SASL.
If this code belongs anywhere at all, it's in the SASL library. As for the
mechanism itself - we've only recently excised all the other
non-standard/obsolete Bind mechanisms from our code base. If Microsoft wants
to publish some RFCs/specs for these other mechs, then maybe it'd be OK to
incorporate. But until then, to me it just feels like pollution.
Anyone else have comments?
-------- Original Message --------
Subject: Re: Likewise has added GSS-SPNEGO support to openldap libraries
Date: Sat, 26 Jan 2008 23:17:18 +1100
From: Luke Howard <lukeh(a)padl.com>
Organization: PADL Software Pty Ltd
To: Krishna Ganugapati <krishnag(a)likewisesoftware.com>
CC: Howard Chu <HYC(a)symas.com>
References:
<A4670A1B9F4A714DA683071F29FC5A390C0402B8(a)ms08.mse3.exchange.ms>
Hi Krishna,
Sounds good! The standard procedure is to file an ITS at:
http://www.openldap.org/its
and then the OpenLDAP team will review it. I still might have commit
access. :-)
I think the OpenLDAP team would want to consider how adding
LDAP_AUTH_NEGOTIATE (which isn't a new authentication method at the
protocol layer) would interact with the existing implementation of
ldap_sasl_interactive_bind_s(). I personally have no problem with the
MSDN APIs but the team may prefer to keep the existing API usage.
regards,
-- Luke
Krishna Ganugapati wrote:
>
> Luke,
>
> I wanted to let you know that we’ve added support for the
> LDAP_AUTH_NEGOTIATE option to support GSS-SPNEGO in the open-ldap
> libraries. I’d contracted with Sernet to do this work and the work was
> done by Stefan Metzmacher of Sernet. We have this support in our own
> tree right now and it is super cool.
>
> See here for details
> http://msdn2.microsoft.com/en-us/library/aa366156.aspx
>
> The advantage is that if you want to make authenticated requests to
> Active Directory, it is a piece of cake as opposed to having to
> negotiate gss contexts yourself. If you get a tgt from a AD domain
> controller, you can seamlessly connect to AD directories.
>
> I’d like to get this in to the open-ldap source base. I notice that
> you (your company) partners with Symas and the open-ldap team. Could I
> impose on you to make introductions? I think they will be more
> inclined to accept the code when they realize that this work has been
> done by Sernet (Volker Lendecke’s company) on contract to Likewise and
> we at Likewise are delighted to push this upstream. I completely
> understand if you would not be comfortable doing so.
>
> By the way, our team has ported the dce-rpc libraries to just about
> every platform possible and we plan to release it back to the
> community very soon. We’re also going to release our libnetapi
> libraries which provide a API level compatibility with most of the Net
> APIs
>
> Best regards,
>
> Krishna
>
> *Krishna** Ganugapati*
> Vice President, Engineering
>
> *T* 425.378.7887 x241 *F* 425.484.6316 *M* 425.736.1076 *E*
> _krishnag(a)likewisesoftware.com <mailto:krishnag@likewisesoftware.com>_
>
>
> 15395 SE 30th Place, Suite 140
> Bellevue, WA 98007
> *_www.likewisesoftware.com <http://www.likewisesoftware.com/>_**__*
>
--
www.padl.com |www.fghr.net
--
-- 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/
15 years, 8 months
Patch: Fix ldap_open debug message
by Michael Adam
Hi,
yes, ldap_open() is deprecated, but the final success/failure
message is currently wrong. Attached is a trivial patch against
current CVS that fixes this.
Cheers, Michael
--
Michael Adam <ma(a)sernet.de> <obnox(a)samba.org>
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.SerNet.DE, mailto: Info @ SerNet.DE
15 years, 8 months
root_dse SASL mech duping
by Quanah Gibson-Mount
In looking at a back trace of a core file, I noticed:
(gdb) thread 7
[Switching to thread 7 (core thread 6)]
#0 0x90003ba8 in szone_malloc ()
(gdb) bt
#0 0x90003ba8 in szone_malloc ()
#1 0x28302c31 in ?? ()
#2 0x90003a00 in szone_malloc ()
#3 0x00105d78 in ber_memalloc_x (s=33554488, ctx=0x28302c31) at
memory.c:226
#4 0x001064bc in ber_strdup_x (s=0x23d536e0
"OTP,OTP,OTPOTP,OTP,OTP,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5",
ctx=0x0) at memory.c:642
#5 0x000e3ff0 in ldap_str2charray (str_in=0x2000038
"����", brkstr=0x19d9a8 ",") at charray.c:188
#6 0x0005af4c in slap_sasl_mechs (conn=0x0) at sasl.c:1277
#7 0x00059264 in root_dse_info (conn=0x1aadeca0, entry=0xf18058c8,
text=0x3e8) at root_dse.c:197
#8 0x00018d54 in fe_op_search (op=0x1b28ca0, rs=0xf1805bc4) at search.c:265
#9 0x00018bf8 in do_search (op=0x1b28ca0, rs=0xf1805bc4) at search.c:217
#10 0x00016cac in connection_operation (ctx=0x235778, arg_v=0x1b28ca0) at
connection.c:1133
#11 0x000eaa1c in ldap_int_thread_pool_wrapper (xpool=0x190c420) at
tpool.c:478
#12 0x9002bd08 in _pthread_body ()
Short of the duping of the SASL mechanisms (which seems somewhat silly for
root_dse), I notice how the generated string seems to be incorrect, i.e.,
notice how it has "OTPOTP" with a missing comma. Also in #5, there seems
to be some issue with a corrupted string getting introduced?
There is one other thread in this same function stack:
[Switching to thread 4 (core thread 3)]
#0 0xffff85d8 in ___spin_lock_relinquish () at
/System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:186
186 in
/System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h
(gdb) bt
#0 0xffff85d8 in ___spin_lock_relinquish () at
/System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:186
#1 0x90003a00 in szone_malloc ()
#2 0x90003600 in malloc ()
#3 0x00105d78 in ber_memalloc_x (s=0, ctx=0xffffffc3) at memory.c:226
#4 0x001064bc in ber_strdup_x (s=0x23d536e0
"OTP,OTP,OTPOTP,OTP,OTP,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5,GSSAPI,GSSAPI,GSSAPI,DIGEST-MD5,DIGEST-MD5,DIGEST-MD5,CRAM-MD5,CRAM-MD5,CRAM-MD5",
ctx=0x0) at memory.c:642
#5 0x000e3ff0 in ldap_str2charray (str_in=0x0, brkstr=0x19d9a8 ",") at
charray.c:188
#6 0x0005af4c in slap_sasl_mechs (conn=0xa0001fac) at sasl.c:1277
#7 0x00059264 in root_dse_info (conn=0x1aadeca0, entry=0xf0c028c8,
text=0x1) at root_dse.c:197
#8 0x00018d54 in fe_op_search (op=0x1bdf380, rs=0xf0c02bc4) at search.c:265
#9 0x00018bf8 in do_search (op=0x1bdf380, rs=0xf0c02bc4) at search.c:217
#10 0x00016cac in connection_operation (ctx=0x235778, arg_v=0x1bdf380) at
connection.c:1133
#11 0x000eaa1c in ldap_int_thread_pool_wrapper (xpool=0x190c420) at
tpool.c:478
#12 0x9002bd08 in _pthread_body ()
that exhibits the same issue of the SALS mech being OTPOTP. It seems to
have a relatively normal string however in #5. Any ideas?
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 8 months
Re: commit: ldap/servers/slapd/back-relay op.c
by Hallvard B Furuseth
ando(a)OpenLDAP.org writes:
> Modified Files:
> op.c 1.24 -> 1.25
> rework back-relay internals along Hallvard's suggestions (ITS#5328)
Looking closer...
The code to handle RB_REFERRAL is unused, since RB_REFERRAL is never
passed.
Nitpicks:
RB_UNWILLING (and its code) can be factored as
(LDAP_UNWILLING_TO_PERFORM | RB_ERR | <set sr_text>).
Eliminates the RB_UNWILLING case in relay_back_select_backend().
The code looks clearer with the RB_SEND-handling inside the
blocks handling RB_ERR. (The code supports sending a result without
setting sr_err first, which looks strange. If you used RB_SEND without
RB_ERR/RB_REFERRAL.)
I'll commit something like this for the two latter, unless you have
other plans. (And maybe rename RB_UNWILLING* to RB_UNAVAIL* since it's
the <set sr_text to "unavailable in this context> part which differs
from what other flags do.)
Index: op.c
===================================================================
RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-relay/op.c,v
retrieving revision 1.26
diff -u -2 -r1.26 op.c
--- op.c 16 Jan 2008 21:00:57 -0000 1.26
+++ op.c 18 Jan 2008 14:15:12 -0000
@@ -28,7 +28,8 @@
#define RB_ERR_MASK (0x00FFU)
#define RB_ERR (0x1000U)
-#define RB_UNWILLING (0x2000U)
+#define RB_UNAVAIL_FLAG (0x2000U)
#define RB_REFERRAL (0x4000U)
#define RB_SEND (0x8000U)
+#define RB_UNWILLING (LDAP_UNWILLING_TO_PERFORM|RB_ERR|RB_UNAVAIL_FLAG)
#define RB_UNWILLING_SEND (RB_UNWILLING|RB_SEND)
#define RB_REFERRAL_SEND (RB_REFERRAL|RB_SEND)
@@ -76,13 +77,9 @@
"%s: back-relay for DN=\"%s\" would call self.\n",
op->o_log_prefix, op->o_req_dn.bv_val, 0 );
- if ( fail_mode & RB_UNWILLING ) {
- rs->sr_err = LDAP_UNWILLING_TO_PERFORM;
-
- } else if ( fail_mode & RB_ERR ) {
+ if ( fail_mode & RB_ERR ) {
rs->sr_err = rc;
- }
-
- if ( fail_mode & RB_SEND ) {
- send_ldap_result( op, rs );
+ if ( fail_mode & RB_SEND ) {
+ send_ldap_result( op, rs );
+ }
}
@@ -148,10 +145,7 @@
}
- } else {
- if ( fail_mode & RB_ERR ) {
- rs->sr_err = rc;
-
- } else if ( fail_mode & RB_UNWILLING ) {
- rc = rs->sr_err = LDAP_UNWILLING_TO_PERFORM;
+ } else if ( fail_mode & RB_ERR ) {
+ rs->sr_err = rc;
+ if ( fail_mode & RB_UNAVAIL_FLAG ) {
rs->sr_text = "operation not supported within naming context";
}
--
Regards,
Hallvard
15 years, 8 months
ISO C99 features and compatibility
by Matthew Backes
We've recently stopped pretending to support building slapd with a
K&R C compiler; it makes some sense to apply that to the libraries as
well. They are designed to be build-able in more places but it makes
sense to require at least an ANSI C, considering the amount header
cleanup we could do.
I'm also interested in potentially requiring some ISO C99 features;
in particular variadic macros are very very attractive. In addition
to simplifying internal macro design, it allows for a great deal of
cleanup and more flexibile macro use in the rest of OpenLDAP.
Consider Debug() and Statslog(); currently they are mostly the same,
with the idea that Statslog takes two extra dedicated args (for
connid and opid), and that Statslog() should appear even in a non-
LDAP_DEBUG build. As it sits, they don't share code and are
implemented separately. Worse, we have lots of
Debug( LDAP_DEBUG_FOO, "foo\n", 0, 0, 0 );
Where the 0's should not be necessary. Consider the case of adding a
new compile-optional logging type; one currently needs to extend the
macros for Debug() and Statslog() separately, and maintain large and
separate ifdef trees for each build-option permutation. A more
elegant solution involves using a set of common macros to implement
Debug and Statslog internally, but without variadic macros there must
be separate implementations for each argument count, which defeats
the purpose of unifying them in the first place.
Or we could preprocess all of the .c with m4...
But really, it seems reasonable to borrow a few features from a
standard from 1999. Is anyone actively maintaining OpenLDAP on
platforms with no C99ish compiler available?
Matthew Backes
Symas Corporation
mbackes(a)symas.com
15 years, 8 months
slapo-constraint type uri: Constrained attribute used in LDAP URL
by Michael Ströder
HI!
Consider the following config for slapo-constraint in slapd.conf:
constraint_attribute ou uri
ldap:///o=Test Company?ou?sub?(objectClass=organizationalUnit)
With this example the constrained attribute is the same like the one
used in the LDAP URL. Now how are entries handled which are search
results of the LDAP URL? In this example how to deal with new values of
attribute 'ou' in case of adding a new entry with object class
'organizationalUnit'?
Ciao, Michael.
15 years, 8 months
