[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Installation openLDAP in Debian

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.


--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/