LALOT Dominique wrote:
Nothing else to discuss? When I started a long time ago, the learning edge was
a little bit easier, as to start your configuration you don't need to use ldap
tools. You know the problem of chicken and eggs.
If you don't understand LDAP and LDIF then you cannot effectively administer
an LDAP server. Period. There is no chicken and egg here - you must understand
LDAP. You must know what "DIT" means. You must know what a DN is. You must
know what a schema is. You must know what an attribute is. There is no
bypassing this required knowledge.
When you know what these things are, cn=config is just another DIT, that you
manage just like every other DIT. The learning curve for cn=config is shorter
than for slapd.conf, because once you learn the essential elements of LDAP,
you also know all the essentials for configuring slapd. Otherwise, you have to
learn LDAP + LDIF + slapd.conf syntax, which history has shown practically
everybody gets *wrong*. The web is full of bogus slapd.conf examples with
directives scattered all over the place, instead of in their proper order and
location. Our ITS is frequently littered with such junk, configs created by
people who hastily copy/pasted something they read from some howto somewhere,
without understanding what they were really doing.
On other ldap servers, software comes with a GUI to configure. If you
that and you get rid of slapd.conf I imagine that lots of beginners will try
some other solutions than OpenLDAP and that would be a pity.
There will always be misguided beginners, that's life. If they use inferior
solutions, they'll either learn, or not. I'm not interested in gaining the
users who don't learn.
And a configuration tool can help to glue the dependences between
It's harder and harder to understand what to put, where, and the side effects.
I was just playing around with ProxyAuth, using directives, slaptest OK, but I
am not using SASL which should be (after a day to test) something required.
But my slaptest is OK..
Your slaptest is OK because there was no broken dependency. ProxyAuth doesn't
require SASL. Whoever told you so was wrong. (They overlooked the ProxyAuthz
control, which is independent of SASL.)
The fact that directives are clustered into discrete entries makes it *easier*
to understand what dependencies exist. The dependencies always existed, even
with slapd.conf, but in slapd.conf they were mostly invisible. They were
mentioned in the slapd.conf(5) manpage but again, history shows that the
majority of admins ignore this.
Another example: We have several independant for the moment databases
glued together. That's not the same config and we need to have an acl part
with limits and rights. If I do that with cn=config, I have to write an ldap
programm to add, modify, delete attributes.
The LDAP *programs* already exist.
Using an include acl.conf in slapd.conf, just rsync acl.conf and
Production LDAP sites that we deal with cannot afford to have slapd down, no
matter how brief a restart may be. If your site can tolerate that, perhaps you
should use one of those other solutions you alluded to, instead of OpenLDAP.
In my experience they have quite frequent downtime, so that might be more
comfortable and familiar for you.
For us, we ldapmodify an ACL here or there on a central server and it
replicates automatically to other servers. No need for rsync or any other
tools with their separate authentication/security requirements.
You sound like a horse-and-buggy coachman protesting the introduction of the
the comments in slapd.conf are very usefull.
Please do not remove slapd.conf or add a configure tool.
Any LDAP client can be used to operate on cn=config. You're asking for a
screwdriver when you've already been given a Swiss Army knife.
A dedicated configure tool would partly defeat the purpose of cn=config.
1) it would have its own separate learning curve
2) admins would become dependent on it, and would be helpless when it fails
One need only look at SunDSEE/RedHatDS/FedoraDS and see how lost their
sysadmins are when their AdminServer crashes (as it invariably does), despite
the fact that their config engine is also exposed as an LDAP DIT. Their docs
always encourage admins to just use the GUI, and so the admins never learn
what the underlying controlling attributes actually are. They spend more time
trying to figure out what part of their desktop graphics environment needs to
be tweaked *this* time, to get the adminserver running again, than they would
ever actually spend dealing with LDAP itself.
For the sites we deal with, the sysadmins tell us how grateful they are that
they can do all their admin tasks using simple shell scripts. GUIs just get in
their way, and the vendors pushing the GUIs seem to make a point of obscuring
what actually goes on underneath.
If you cannot live without a GUI, I recommend web2ldap or Apache Directory
Studio. Both are quite good, and if you decide to use them, you can use them
for *all* of your LDAP tasks, not just administering OpenLDAP.
2011/4/21 Howard Chu <hyc(a)symas.com <mailto:email@example.com>>
Jose Ildefonso Camargo Tolosa wrote:
On Wed, Apr 20, 2011 at 4:18 PM, Howard Chu<hyc(a)symas.com
Jose Ildefonso Camargo Tolosa wrote:
On Wed, Apr 20, 2011 at 2:53 PM, Howard Chu<hyc(a)symas.com
The tree of files is not meant for you to ever look at or
Just use slapcat or ldapsearch. If you know anything about
LDAP at all
is MUCH easier than editing flat text files, since you can
use any LDAP
(commandline or GUI) to do all the administration.
I don't find complex to directly modify the files, actually, I
easier than having to write a ldif modification script every
need to apply a change! I just go ahead and edit the corresponding
ldif file on slapd.d
You are editing the backing store of a slapd internal database. If
running while you're doing this, you will probably corrupt the
Even if slapd is not running, you'll probably corrupt the database.
Ok, I'll fall for this: how in the world can I corrupt a text (ldif)
file? I have done that for quite some time, and I have never had a
single issue with it. Off course, I need to restart slapd to make it
use my changes, but it is not big deal on my environment (for other
environments, you can use ldapmodify (or similar) and make changes on
There are many possibilities. The most obvious is leaving random
whitespace at the end of a line, which frequently trips up people who
manually edit flat text files. I won't go into the other possibilities
because frankly, it's an internal implementation detail and not worth
mentioning. Suffice to say, if you're not going to take the word of the
programmer who designed and implemented all of this that editing by hand
is prone to corruption, then we have nothing further to discuss.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/