LALOT Dominique wrote:
Hello Howard,
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 don't do 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 directives. 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 that are 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 restart.
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 automobile.
And 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.
Dom
2011/4/21 Howard Chu <hyc@symas.com mailto:hyc@symas.com>
Jose Ildefonso Camargo Tolosa wrote: On Wed, Apr 20, 2011 at 4:18 PM, Howard Chu<hyc@symas.com <mailto:hyc@symas.com>> wrote: Jose Ildefonso Camargo Tolosa wrote: On Wed, Apr 20, 2011 at 2:53 PM, Howard Chu<hyc@symas.com <mailto:hyc@symas.com>> wrote: The tree of files is not meant for you to ever look at or modify directly. Just use slapcat or ldapsearch. If you know anything about LDAP at all this is MUCH easier than editing flat text files, since you can use any LDAP tool (commandline or GUI) to do all the administration. I don't find complex to directly modify the files, actually, I find it easier than having to write a ldif modification script every time I 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 slapd is running while you're doing this, you will probably corrupt the database. 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 the fly). 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.