OpenLDAP 2.4
by Howard Chu
The Admin Guide still has not been updated with all of the relevant changes,
so here are some notes on new features in the 2.4 release... I believe all of
the manpages are up to date, so you can get specifics from them.
More complete cn=config functionality:
There is a new slapd-config(5) manpage for the cn=config backend.
the original design called for auto-renaming of config entries when you
insert or delete entries with ordered names, but that was not implemented in
2.3. It is now in 2.4. This means, e.g., if you have
olcDatabase={1}bdb,cn=config
olcSuffix: dc=example,dc=com
and you want to add a new subordinate, now you can:
ldapadd olcDatabase={1}bdb,cn=config
olcSuffix: dc=foo,dc=example,dc=com
this will insert a new BDB database in slot 1 and bump all following
databases down one, so the original BDB database will now be named
olcDatabase={2}bdb,cn=config
olcSuffix: dc=example,dc=com
In 2.3 you were only able to add new schema elements, not delete or
modify existing elements. In 2.4 you can modify schema at will. (Except for
the hardcoded system schema, of course.)
More sophisticated syncrepl configurations:
the original implementation of syncrepl in OpenLDAP 2.2 was intended to
support multiple consumers within the same database, but that feature never
worked and was removed from OpenLDAP 2.3. I.e., you could only configure a
single consumer in any database.
In 2.4 you can configure multiple consumers in a single database. The
configuration possibilities here are quite complex and numerous. You can
configure consumers over arbitrary subtrees of a database (disjoint or
overlapping). Any portion of the database may in turn be provided to other
consumers using the syncprov overlay. The syncprov overlay works with any
number of consumers over a single database or over arbitrarily many glued
databases.
As a consequence of the work to support multiple consumer contexts, the
syncrepl system now supports full N-way multimaster replication with
entry-level conflict resolution. There are some important constraints, of
course: In order to maintain consistent results across all servers, you must
maintain tightly synchronized clocks across all participating servers (e.g.,
you must use NTP on all servers). The entryCSNs used for replication now
record timestamps with microsecond resolution, instead of just seconds. The
delta-syncrepl code has not been updated to support multimaster usage yet,
that will come later in the 2.4 cycle.
On a related note, syncrepl was explicitly disabled on cn=config in 2.3.
It is now fully supported in 2.4; you can use syncrepl to replicate an entire
server configuration from one server to arbitrarily many other servers. It's
possible to clone an entire running slapd using just a small (less than 10
lines) seed configuration, or you can just replicate the schema subtrees,
etc. Tests 049 and 050 in the test suite provide working examples of these
capabilities.
In 2.3 you could configure syncrepl as a full push-mode replicator by
using it in conjunction with a back-ldap pointed at the target server. But
because the back-ldap database needs to have a suffix corresponding to the
target's suffix, you could only configure one instance per slapd.
In 2.4 you can define a database to be "hidden" which means that its
suffix is ignored when checking for name collisions, and the database will
never be used to answer requests received by the frontend. Using this hidden
database feature allows you to configure multiple databases with the same
suffix, allowing you to set up multiple back-ldap instances for pushing
replication of a single database to multiple targets. There may be other uses
for hidden databases as well (e.g., using a syncrepl consumer to maintain a
*local* mirror of a database on a separate filesystem).
More extensive TLS configuration control:
In 2.3, the TLS configuration in slapd was only used by the slapd
listeners. For outbound connections used by e.g. back-ldap or syncrepl their
TLS parameters came from the system's ldap.conf file.
In 2.4 all of these sessions inherit their settings from the main slapd
configuration but settings can be individually overridden on a
per-config-item basis. This is particularly helpful if you use
certificate-based authentication and need to use a different client
certificate for different destinations.
Various performance enhancements:
Too many to list. Some notable changes - ldapadd used to be a couple of
orders of magnitude slower than "slapadd -q". It's now at worst only about
half the speed of slapadd -q. A few weeks ago I did some comparisons of all
the 2.x OpenLDAP releases; the results are in the slides from my SCALE
presentation and you can find a copy here:
http://www.highlandsun.com/hyc/scale2007.pdf
That compared 2.0.27, 2.1.30, 2.2.30, 2.3.33, and HEAD (as of a couple
weeks ago). Toward the latter end of the "Cached Search Performance" chart it
gets hard to see the difference because the runtimes are so small, but the
new code is about 25% faster than 2.3, which was about 20% faster than 2.2,
which was about 100% faster than 2.1, which was about 100% faster than 2.0,
in that particular search scenario. That test basically searched a 1.3GB DB
of 380836 entries (all in the slapd entry cache) in under 1 second. i.e., on
a 2.4GHz CPU with DDR400 ECC/Registered RAM we can search over 500 thousand
entries per second. The search was on an unindexed attribute using a filter
that would not match any entry, forcing slapd to examine every entry in the
DB, testing the filter for a match.
Essentially the slapd entry cache in back-bdb/back-hdb is so efficient
the search processing time is almost invisible; the runtime is limited only
by the memory bandwidth of the machine. (The search data rate corresponds to
about 3.5GB/sec; the memory bandwidth on the machine is only about 4GB/sec
due to ECC and register latency.)
I think it goes without saying that no other Directory Server in the world is
this fast or this efficient. Couple that with the scalability, manageability,
flexibility, and just the sheer know-how behind this software, and nothing
else is even remotely comparable.
--
-- 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, 4 months
using openldap as a translation layer.
by S James S Stapleton
Can I use open-ldap as a translation layer for queries with a ldap client
with minimal configuration potential?
Right now the client (which cannot be trivially modified), can use LDAP
authentication, sort-of. What it does, is it takes your user name, and
assignes it to the 'uid' attribute, and then tacks on whatever string is in
the config to form a distinguished name. For example, if I used 'stapleton'
as my username and the config had 'ou=People,dc=domain,dc=tld', it would
query for 'uid=stapleton,ou=People,dc=dmain,dc=tld'. Unfortunately, people
usernames are everything before the '@' sign in their email, and this is not
their uid. The uid is a number, that is used nowhere else. The standard
process that we use is to take their user name and perform an ldap query to
get the uid from the email, and then use the uid to verify if the user is
correct.
Example:
ldap://server:389/uid=441068,ou=People,dc=mydomain,dc=tld
pulls up my information
Now, if I want to get my uid, I'd do this:
ldap://server:389/ou=People,dc=mydomain,dc=tld?uid?sub?(mail=stapleton@mydomain.tld)
The client, as described cannot do that, if a user attempts to use what they
expect their user name to be, it will send:
uid=stapleton,ou=People,dc=mydomain,dc=tld
or
uid=stapleton(a)mydomain.tld,ou=People,dc=mydomain,dc=tld
Neither of which will authenticate. Is there a way to make OpenLDAP provide
a middle layer to handle this?
Thank you,
-Jim Stapleton
15 years, 8 months
How to search for all entries that have modified themselves
by Zhang Weiwu
Dear all
We have accesslog feature turned on for several months. It's very useful
for us to identify who have modified what (only edit access is logged).
The new requirement is to search for all entries that have modified
themselves;
I don't know how to do (and failed after many experiments). It's very
easy to identify whether or not a given user have modified herself by
doing:
ldapsearch ... '(&(reqDN=uid=zhangweiwu,ou=contacts,dc=eoa,dc=cn)(reqAuthzID=uid=zhangweiwu,ou=contacts,dc=eoa,dc=cn))'
But I need to do this search 4000 times to locate all entries who have
modified themselves. I wish I can work smarter using something like
ldapsearch ... '(&(reqDN=\(.*\))(reqAuthzID=\1))'
Certainly this doesn't work but you get the idea. Is there a solution?
Thanks a lot in advance! Would you please kindly use "reply all" to
reply this message so that my colleague on the 'cc' can be enlightened
too?
--
Zhang Weiwu
Real Softservice
http://www.realss.com
+86 592 2091112
15 years, 8 months
how to delete entire base dn ?
by JOYDEEP
Hi,
I am very much interested to know the deletion procedure of entire base
dn as I am implemeting different types of ldif
to learn
thanks
15 years, 8 months
referential integrity
by manu＠netbsd.org
Hello
I have been reading the docs, looking for a way to acheive referential
integrity as it is done in RDBMS.
For instance, if I want to constraint the value of atribute title to a
set of value, so that any modification to a value not in the list would
be denied. Let's say the set of legal values could be stored in the
directory, ad objects of a dedicated class;
How can it be done? slapo-refint is not about denying changes,
slapo-constraint can only enforce regex matching.. Is there anything
else I missed?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
15 years, 8 months
more about perl backend and external perl modules
by Piotr Wadas
-------------
root@gnp43:/home/pwadas# slapd -4 -d3872 -h ldap://192.168.0.221/
ldapi:///
@(#) $OpenLDAP: slapd 2.3.35 (May 12 2007 16:57:50) $
root@gnp43.internetdsl.tpnet.pl:/home/pwadas/SRC/SLAPD-NEW/openldap-2.3.35/servers/slapd
Error Can't load '/usr/lib/perl/5.8/auto/POSIX/POSIX.so' for module POSIX:
/usr/lib/perl/5.8/auto/POSIX/POSIX.so: undefined symbol: PL_sig_name at
/usr/lib/perl/5.8/XSLoader.pm line 70.
at /usr/lib/perl/5.8/POSIX.pm line 26
Compilation failed in require at /etc/ldap/PerlBackend.pm line 26.
BEGIN failed--compilation aborted at /etc/ldap/PerlBackend.pm line 26.
Compilation failed in require at (eval 2) line 1.
BEGIN failed--compilation aborted at (eval 2) line 1.
WARNING: No dynamic config support for database perl.
Can't call method "init" on an undefined value.
root@gnp43:/home/pwadas#
root@gnp43:~/SRC/SLAPD-NEW# perl --version
This is perl, v5.8.8 built for i486-linux-gnu-thread-multi
------------
Hello,
I got the above error, when I try to start slapd,
with perl backends, and some "use" lines in script.
No matter what perl package I try to use (POSIX, DBI, whatever),
I get similar error regarding perl library.
I tried to rebuild perl and its modules, and
rebuild openldap (tried 2.3.30 and 2.3.35 versions), with
no effect.
Is there some limitation on perl backend, because of
kind of the way it's embedded into slapd, which actually
disallow usage of external modules? It seems slapd runs
fine, when I don't put any "use" lines into backend perl file (*.pm)
Should I try without threading, or what?
I've seen this thing being reported a few times on
various lists, including some linux distribution bugzillas,
anyway there was no answer, see e.g. this
https://bugs.launchpad.net/ubuntu/+source/openldap2.2/+bug/90812
This slapd 2.3.35 was built with the following options:
--prefix=/usr
--libexecdir=/usr/lib
--sysconfdir=/etc
--localstatedir=/var
--mandir=/usr/share/man
--enable-debug
--enable-dynamic
--enable-syslog
--enable-proctitle
--enable-ipv6
--enable-local
--enable-slapd
--enable-aci
--enable-cleartext
--enable-crypt
--enable-spasswd
--enable-modules
--enable-rewrite
--enable-rlookups
--enable-slp
--enable-wrappers
--enable-backends=mod
--enable-overlays=mod
--enable-slurpd
--with-subdir=ldap
--with-cyrus-sasl
--with-threads
--with-tls
--enable-bdb=mod
--enable-dnssrv=mod
--enable-hdb=mod
--enable-ldap=mod
--enable-ldbm=mod
--enable-meta=mod
--enable-monitor=mod
--enable-null=mod
--enable-passwd=mod
--enable-perl=mod
--enable-relay=mod
--enable-shell=mod
--enable-sql=mod
--enable-accesslog=mod
--enable-auditlog=mod
--enable-denyop=mod
--enable-dyngroup=mod
--enable-dynlist=mod
--enable-lastmod=mod
--enable-ppolicy=mod
--enable-proxycache=mod
--enable-refint=mod
--enable-retcode=mod
--enable-rwm=mod
--enable-syncprov=mod
--enable-translucent=mod
--enable-unique=mod
--enable-valsort=mod
and the part from slapd.conf (of course the same happens with only one
directory in perlModulePath, containing PerlBackend.pm)
database perl
suffix "dc=example"
perlModulePath /etc/ldap /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl
perlModule PerlBackend
"PerlBackend.pm" is the file from slapd distribution, SampleLDAP, I just
renamed it.
Regards,
Piotr
15 years, 9 months
ber_scanf and ber_printf strangeness
by Szombathelyi György
Hi!
I'm developing kldap, a Qt wrapper for LDAP-functions. When I tested ber_scanf
and ber_printf functions, I found this strangeness:
Encode a sequence of octet strings via ber_printf
ber_printf(ber,"{v}",list_of_strings);
But decoding only succeeds if I use the following scanf formats:
ber_scanf(ber,"v",...) - yes, without '{}', or
ber_scanf(ber,"{ooo}")
As I read the ber_scanf man page, 'v' format actually decodes a sequence of
octet strings, so my examples are correct according to these. But the code
example on the end shows that '{v}' should be used. So what is the right way?
Regards,
György
15 years, 9 months
Search replies processed twice?
by José Marco
I programmed something like this very simple code inside an overlay.
The idea is quite simple: if a search fulfills a condition, a new search
should be done and the retrieved entries should also be returned to the
client. (It is ensured that the second search does not fulfill the
condition).
static int response( Operation *op, SlapReply *rs ){
if ( op->o_tag == LDAP_REQ_SEARCH ){
switch ( rs->sr_type ){
case REP_SEARCH:
// Show op and rs values in the debug console
Debug(LDAP_DEBUG_TRACE, "#################### I Enter
REP_SEARCH +++++++++++++++++\n",0,0,0);
return SLAP_CB_CONTINUE;
break;
case REP_RESULT:
// Show op and rs values in the debug console
Debug(LDAP_DEBUG_TRACE, "#################### I Enter
REP_RESULT +++++++++++++++++\n",0,0,0);
// Check for subsearch condition
...
if (check){
// Op2 initialize
Operation op2 = *op;
// Some op2 initialization code (just change the
filter so the result of the previous check is false next time for this
over config)
Debug(LDAP_DEBUG_TRACE, "####################
Subsearch: start *****\n",0,0,0);
[Option1:
op2.o_bd = select_backend( &op->o_req_ndn,
get_manageDSAit( op ), 1 );
(op2.o_bd->be_search)( &op2, rs );
]
[ Option2:
fe_op_search( &op2, &rr );
]
Debug(LDAP_DEBUG_TRACE, "####################
Subsearch: finish ************\n",0,0,0);
}
return SLAP_CB_CONTINUE;
break;
}
}
return SLAP_CB_CONTINUE;
}
The code is just that simple but I found that when the subsearch is
done, the ldap server runs the response twice for each retrieved entry.
I suppose that the entries are being sent twice regardless of the search
function I use (fe_op_search or be_search).
Anyone can give me a hint on why?
Are those the correct searching functions? If so, which one is more
appropriate?
15 years, 9 months
Re: chain-overlay question
by Pierangelo Masarati
Please keep replies on the list.
Markus Krause wrote:
> Zitat von Pierangelo Masarati <ando(a)sys-net.it>:
> Sorry for that, i am not a debugging expert ...
> But i can asure you that i am running this on linux system (SuSE Linux
> Enterprise Server), although it seems that SuSE does change some
> packages in a "special" way. the OpenLDAP server i am running here is
> installed from a rpm package from
> http://software.opensuse.org/download/OpenLDAP/SLE_10/i586/.
OK, I (wrongly) guessed you were building OpenLDAP yourself, as distros
usually lag a bit behind with OpenLDAP releases. Good to SuSE :)
> i also
> installed the package "openldap2-debuginfo-2.3.34-5.2" and started gdb
> with:
>
> gdb /usr/lib/openldap/slapd -se
> /usr/lib/debug/usr/lib/openldap/slapd.debug
>
> after the segfault i called "bt" and posted the result above.
> i am really sorry if that output only wastes your time.
Well, it wastes yours more than mine :)
> if you need some more debugging detail on this (or other things) please
> let me now and if i did complete nonsense maybe please tell me what to
> do/type ...
In any case, to me your configuration looks good, so I guess it's about
the URI you're using "ldaps://" which might not work as expected. In
this case, I suggest you rather check if the provider gets contacted at
all, and, in case, why it doesn't accept the connection. As per the
core dump, it should deserve more attention but, for this, we need a
non-stripped binary. In that case, you might need to build the latest
OpenLDAP release yourself (it's not a big deal, though).
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 9 months
