OpenLDAP 2.5
by Howard Chu
With 2.4.21 out, and hopefully stable enough to promote to the next Stable
release, it's time to feature-freeze 2.4 and prepare for the 2.5 branch. As I
already announced to the OpenLDAP-Committers, we're also planning to switch
from CVS to GIT in mid-January. Commits for 2.5 will begin after we've settled
into GIT.
We haven't really laid out a formal roadmap for 2.5 yet, but I think most of
it has been discussed here or in Development ITSs already.
I would like to be able to resolve all outstanding Development ITSs - we will
either implement them or reject/close them. There are 42 outstanding at the
moment.
Likewise for all outstanding ITSs in Software Bugs - many of them have been
deferred because a proper fix would require invasive changes to large parts of
the code base. There are 26 outstanding. With 2.5 beginning we are free to
make these large scale changes.
We should also walk thru the Software Enhancement requests and decide which to
accept and which to reject. Currently there are 37 outstanding.
I also have a number of specific areas I want to see worked on; some of these
are included in the above ITSs but I'll outline them here:
syncrepl
config - this is pretty unwieldy already; syncrepl needs to be moved
outside of the slapd core and into an overlay. That will allow us a lot more
flexibility in configuring while also eliminating a lot of redundant parsing code.
suffixmassage - we at the very least need to be able to point a consumer
at some non-homogeneous suffix in the provider. We may go for complete
librewrite support as well, although at this point I don't see as strong a need.
config
TLS certs and keys should be stored as LDAP attributes, not pointers to
filesystem locations. This is a prereq to using some of the dynamic cert
generation features of the CA overlay. (This can be troublesome as there may
not be clean APIs for reading certs from memory in all of the TLS APIs we
support.)
Disabling individual config attribute values and entries. At the moment
I'm thinking of adding an ";x-disabled" tag to those values.
back-mdb
Using a single-level store for Entries will impact all of the schema
engine as well. I think the simplest solution here is going to be using an
mmap'd file for all of the schema elements.
The actual design of back-mdb still needs to be defined in several areas.
The single-level store approach exposes us to some new failure modes that the
current multi-level backends don't have. (E.g., corruptions due to bad RAM /
wild pointer writes are very likely to get persisted on disk, implicitly.)
The solution I'm considering is based on a mirroring strategy. Every
database will be stored twice on disk: once in the file that is actively
mmap'd into the process, and once in a write-only file. On every intentional
update of a memory page, we will also store a checksum of the page, and
manually write the page to the mirror. If we detect a checksum failure on any
in-memory page we can still retrieve a valid copy from the mirror file. This
of course doubles our potential I/O load, but I don't believe it's any worse
than the load from performing write-ahead logging on a traditional database.
(And yes, mirroring will take the place of writing transaction log files.)
Some of these same considerations apply to the schema storage, but not
entirely. At runtime, the schema is effectively read-only. When we do dynamic
schema changes thru cn=config, all other threads are suspended. For the mmap
purposes, we can mark all of the schema pages as read-only during runtime, and
only make them read-write when cn=config is actually trying to perform an
update. As such, the only sticky issue is dealing with changes made to the
back-config internal files by plain text editors and such.
These are the things I'm interested in. But as always, this Project is driven
forward by the particular interests of each individual contributor. If you
have other ideas you want to pursue, speak up.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 1 month
ACL check parameters
by Howard Chu
oprofile shows quite a bit more overhead in 2.4's ACL processing vs 2.3's. I'm
thinking of streamlining things a bit, along these lines. Any thoughts?
This acl.c compiles, but a fair amount of slapd code needs to be altered to
use it. I guess if we commit and move forward on it it will have to be for 2.5.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 5 months
Fwd: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by Howard Chu
So, what do folks think about reviving libldif as an exported piece of the
distribution?
-------- Original Message --------
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
Date: Thu, 17 Dec 2009 03:46:08 GMT
From: hyc(a)symas.com
To: openldap-its(a)openldap.org
rmeggins(a)redhat.com wrote:
> I think this could be accomplished in one of two ways:
> 1) Just have libldif return lists of struct berval* for the various data
> parsed. The caller would be responsible for turning these into LDAPMod
> or LDAPControl structures - the advantage is that libldif doesn't have
> to know about any of these higher level structures
> 2) Have libldif create LDAPMod and LDAPControl - I think this could be
> accomplished by having ldif.c #include<ldap.h> to pull in the
> definitions of LDAPMod and LDAPControl - would this be ok?
Let's move this discussion to the openldap-devel mailing list. I'm thinking
(2) is OK but I'd like to hear from other developers / potential users of this
library.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 5 months
static assertions
by Hallvard B Furuseth
I think we should insert a number of static assertions in the
OpenLDAP code: Asserts that fail or succeed at compile time.
E.g. for the comment in config.c:bindkey[] (ITS#6419).
Like this - in include/ac/assert.h?
Or ldap_cdefs.h in case we want to use it in installed headers?
/* Declaration which tries to force a compile error if !cond */
#define ber_static_assert(cond) \
LBER_V(LDAP_CONST char) ber_assertion[ber_assertz(cond) + 1]
/* Return 0, or if !cond try to force a compile error */
#define ber_assertz(cond) (sizeof(struct { \
int ber_assert1[(cond) ? 9 : -9], ber_assert2:(cond) ? 9 : -9; }) && 0)
/* Usage: */
ber_static_assert(~0U >= 0xFFFFFFFFUL); /* int = 32 bits or wider */
int foo(int i) { return i + ber_assertz(LDAP_SUCCESS == 0); }
liblber will need a dummy variable 'const char ber_assertion[1];'.
We can drop that if anyone dislikes it: ber_static_assert() can take
an assertion_name parameter and declare a typedef based on that name.
Or it can generate a name from __LINE__. Then we can have only one
static assert per line, which matters for macros but little else.
--
Hallvard
13 years, 5 months
RE24 testing call #1 (2.4.21)
by Quanah Gibson-Mount
All commits for the upcoming 2.4.21 release have been integrated. Please
test.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
13 years, 5 months
Re: commit: ldap/servers/slapd bconfig.c
by Ralf Haferkamp
Am Donnerstag 10 Dezember 2009 14:22:26 schrieb ralf(a)openldap.org:
> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd
>
> Modified Files:
> bconfig.c 1.404 -> 1.405
>
> Log Message:
> global limits can also be set in "cn=config" (more forITS#6428)
While working on this, I learned that the global limits can either be set
in the "cn=config" entry or in "olcDatabase=frontend,cn=config". Is there
a special reason for this?
This seems also to be the case for some other attributes: olcSecurity,
olcRestricted, olcRequires. Just to name a few.
--
Ralf
13 years, 6 months
Re: commit: ldap/servers/slapd config.c syncrepl.c
by Hallvard B Furuseth
hyc(a)OpenLDAP.org writes:
> ITS#6419 also init for ldaps:// URIs
Does it work for ldapi:// as well? (And should it?) I seem to
remember StartTLS does work for ldapi, though I don't know what
a sensible host name in the server cert would be in that case.
--
Hallvard
13 years, 6 months
Re: LDAPI support in JLDAP
by Endi Sukma Dewata
Hi Marc,
Thanks for your suggestions. I tried to create a subclass of
LDAPConnection but I was getting a lot of problems accessing
non-public methos/classes belonging to com.novell.java package.
But it gave me a different idea, I finally got it to work
using a custom socket factory.
First I create an LDAPIUrl to parse LDAPI URL:
LDAPIUrl url = new LDAPIUrl("ldapi://%2ftmp%2ftest");
Then I create a LDAPISocketFactory and pass it to LDAPConnection:
LDAPISocketFactory factory = new LDAPISocketFactory();
LDAPConnection connection = new LDAPConnection(factory);
To establish the connection I use the hostname parameter of the
connect() function to pass the LDAPI path:
connection.connect(url.getPath(), 0);
The socket factory will use the path to create the Unix domain
socket and ignore the port:
public Socket createSocket(String path, int port) {
AFUNIXSocket socket = AFUNIXSocket.newInstance();
socket.connect(new AFUNIXSocketAddress(new File(path)));
return socket;
}
So thanks a lot and never mind about the proposal. :)
--
Endi S. Dewata
----- "Marc Boorshtein" <mboorshtein(a)gmail.com> wrote:
> Endi,
>
> A few years ago I was able to add DSMLv2 and SPMLv1 support to JLDAP
> by creating subclasses of the LDAPConnection class. This worked well
> without requiring changes to the rest of the JLDAP source code. I
> used JLDAP as the core for the SQL Directory Browser, which supports
> both SPML and DSMLv2. I think the same strategy would work with
> LDAPI?
>
> Marc
>
>
> On Thu, Dec 3, 2009 at 6:26 PM, Endi Sukma Dewata <edewata(a)redhat.com>
> wrote:
> > Hello,
> >
> > Let me introduce myself, I'm working on the IPA & Samba integration
> > effort and I'm building a Java-based synchronization tool that
> > communicates with LDAP servers using the JLDAP library. Here is
> some
> > background about the project:
> > http://www.freeipa.org/page/IPAv3_development_status
> >
> > The LDAP servers used here is the 389 DS (formerly known as Fedora
> > DS). When it's used as Samba private backend, the DS is configured
> > only to listen to LDAPI protocol. I'm trying to use the JLDAP
> library,
> > but currently it doesn't seem to support LDAPI. I think it's
> natural
> > to add LDAPI support into JLDAP because OpenLDAP also supports
> LDAPI.
> > Is there already a plan to add this feature?
> >
> > I've been doing some investigation and it seems that it can be
> added
> > without too much effort because there's an existing library called
> > junixsocket which can provide access to Unix Domain Sockets from
> Java:
> > http://code.google.com/p/junixsocket/
> >
> > Here is a proposal of the changes need to be made to JLDAP in order
> > to support LDAPI:
> > http://www.freeipa.org/page/OpenLDAP_LDAPI_Support_in_JLDAP
> >
> > My questions are:
> > 1. Who is currently maintaining the JLDAP module?
> > 2. Is it ok to modify the IETF API slightly as described in the
> > proposal?
> > 3. Is it ok to include junixsocket in JLDAP? Alternatively we could
> > design a pluggable interface so other people can add new protocol
> > schemes into JLDAP.
> >
> > Please let me know if you have any comments, questions, or
> > suggestions. Thank you very much.
> >
> > --
> > Endi S. Dewata
> >
13 years, 6 months
LDAPI support in JLDAP
by Endi Sukma Dewata
Hello,
Let me introduce myself, I'm working on the IPA & Samba integration
effort and I'm building a Java-based synchronization tool that
communicates with LDAP servers using the JLDAP library. Here is some
background about the project:
http://www.freeipa.org/page/IPAv3_development_status
The LDAP servers used here is the 389 DS (formerly known as Fedora
DS). When it's used as Samba private backend, the DS is configured
only to listen to LDAPI protocol. I'm trying to use the JLDAP library,
but currently it doesn't seem to support LDAPI. I think it's natural
to add LDAPI support into JLDAP because OpenLDAP also supports LDAPI.
Is there already a plan to add this feature?
I've been doing some investigation and it seems that it can be added
without too much effort because there's an existing library called
junixsocket which can provide access to Unix Domain Sockets from Java:
http://code.google.com/p/junixsocket/
Here is a proposal of the changes need to be made to JLDAP in order
to support LDAPI:
http://www.freeipa.org/page/OpenLDAP_LDAPI_Support_in_JLDAP
My questions are:
1. Who is currently maintaining the JLDAP module?
2. Is it ok to modify the IETF API slightly as described in the
proposal?
3. Is it ok to include junixsocket in JLDAP? Alternatively we could
design a pluggable interface so other people can add new protocol
schemes into JLDAP.
Please let me know if you have any comments, questions, or
suggestions. Thank you very much.
--
Endi S. Dewata
13 years, 6 months
Re: commit: ldap/libraries/libldap util-int.c
by Quanah Gibson-Mount
--On Monday, November 30, 2009 8:47 PM +0000 hyc(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap
>
> Modified Files:
> util-int.c 1.65 -> 1.66
>
> Log Message:
> ITS#6405 in ldap_pvt_gettime, also check for microsecs going backward
Neither this function nor this code exist in RE24, which is what the bug
was reported against. I assume a different fix is needed there?
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
13 years, 6 months
