On Apr 20, 2011, at 11:04 AM, Simone Piccardi piccardi@truelite.it wrote:

On 20/04/2011 17:30, Jose Ildefonso Camargo Tolosa wrote:

...

Hi!

it no longer uses slapd.conf by default, it uses cn=config . It is on /etc/ldap/slapd.d/

Debian will leave you with a working directory (even thought not optimal, but you will be able to use it).

If you can be more specific on what you want to do, just let us know! If you are used to configure with slapd.conf, you can actually use that configuration too, or you can convert your slapd.conf configuration into cn=config with slaptest (check the docs!).

Ildefonso Camargo

That's the way I'm using it. And I suggest to anyone not needing to modify configurations on the fly to use it that way.

Because apart the missing documentation, I found difficult having to deal with the obscure attribute names and the complex directory structure (and the not so explicative file names used under it) that I found in /etc/ldap/slapd.d/.

I understand the needs for cn=config, but for the moment I don't need it. Having a file with a simple syntax that I can read and modify instead of a tree of LDIF files is far more convenient for me. So I hope that slapd.conf will remain supported.

It will not remain supported. I highly advise getting used to the new configuration. It may take a little time but it is far superior and quite frankly not that difficult.

Remember too that you are free to help contribute documentation.

--Quanah

On Wed, Apr 20, 2011 at 2:53 PM, Howard Chu hyc@symas.com wrote:

Simone Piccardi wrote:

...

On 20/04/2011 17:30, Jose Ildefonso Camargo Tolosa wrote:

...

Hi!

it no longer uses slapd.conf by default, it uses cn=config .  It is on /etc/ldap/slapd.d/

Debian will leave you with a working directory (even thought not optimal, but you will be able to use it).

If you can be more specific on what you want to do, just let us know! If you are used to configure with slapd.conf, you can actually use that configuration too, or you can convert your slapd.conf configuration into cn=config with slaptest (check the docs!).

Ildefonso Camargo

That's the way I'm using it. And I suggest to anyone not needing to modify configurations on the fly to use it that way.

Because apart the missing documentation, I found difficult having to deal with the obscure attribute names and the complex directory structure (and the not so explicative file names used under it) that I found in /etc/ldap/slapd.d/.

I understand the needs for cn=config, but for the moment I don't need it. Having a file with a simple syntax that I can read and modify instead of a tree of LDIF files is far more convenient for me. So I hope that slapd.conf will remain supported.

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

If you think the tree structure is confusing, then you obviously have not read the Admin Guide, which clearly outlines the structure.

It is not confusing, I actually find it very logic, but it is more complex than a single file. But that was discussed long ago on the list: lets face it, a single plain text file is always simpler than any more formated file, and you will always have someone complaining about it.

Now, if there was a graphical LDAP administration tool that handled the configuration: there would be a lot of happy people, and writing that tool (even by creating a template for existing tools) is now possible thanks to cn=config, it was not that easy with old slapd.conf file.

http://www.openldap.org/doc/admin24/slapdconf2.html#Configuration%20Layout

If you don't read the documentation you have only yourself to blame for being confused.

Yeah, that page is incomplete when compared to:

http://www.openldap.org/doc/admin24/slapdconfig.html

The cn=config directives is missing the access control part, that you can get:

http://www.openldap.org/doc/admin24/access-control.html#Access%20Control%20v...

Not a big deal, but it took me a while to realize that the documentation was no longer on the same place as for slapd.conf

Ildefonso Camargo

On Wed, Apr 20, 2011 at 4:18 PM, Howard Chu hyc@symas.com wrote:

Jose Ildefonso Camargo Tolosa wrote:

...

On Wed, Apr 20, 2011 at 2:53 PM, Howard Chuhyc@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).

Btw, how does OpenLDAP currently handles when you do a really bad change to openldap parameter via ldapmodify? if I edit the ldif files (on slapd.d), I can actually use slaptest to validate it, before I restart the daemon.

Jose Ildefonso Camargo Tolosa wrote:

On Wed, Apr 20, 2011 at 4:18 PM, Howard Chuhyc@symas.com wrote:

...

Jose Ildefonso Camargo Tolosa wrote:

...

On Wed, Apr 20, 2011 at 2:53 PM, Howard Chuhyc@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.

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 wrote:

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.

I'd say I understand LDAP and LDIF etc. but still I'm in favour using slapd.conf and only use cn=config in the *rare* cases where dynamic configuration is really needed.

When you know what these things are, cn=config is just another DIT, that you manage just like every other DIT.

Especially the schema design of OpenLDAP's cn=config is more complicated than it should be. Look at other LDAP server implementations and you'll see how easy it is to tweak cn=config with a generic, schema-aware LDAP client. That's not so easy with OpenLDAP's cn=config.

Ciao, Michael.

Howard Chu wrote:

Michael Ströder wrote:

...

Howard Chu wrote:

...

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.

I'd say I understand LDAP and LDIF etc. but still I'm in favour using slapd.conf and only use cn=config in the *rare* cases where dynamic configuration is really needed.

...

When you know what these things are, cn=config is just another DIT, that you manage just like every other DIT.

Especially the schema design of OpenLDAP's cn=config is more complicated than it should be. Look at other LDAP server implementations and you'll see how easy it is to tweak cn=config with a generic, schema-aware LDAP client. That's not so easy with OpenLDAP's cn=config.

Since you're being so vague it's difficult to address your point.

E.g. the proprietary X-ORDERED stuff prevents clients from doing things easily. It feels like using the text editor while not being as flexible like a text editor.

However, one thing is clear - you can manage everything using just the ldapmodify command line tool, that's a simple fact.

Yes. But I prefer to use a comfortable text editor.

So from what I can see, either your clients are inferior to a command line tool or you're just using them wrong.

Being the author of web2ldap I claim having thought about how LDAP clients should be designed quite a lot. So indeed I take this as personal offense.

Ciao, Michael.

2011/4/22 Simone Piccardi piccardi@truelite.it

Il 21/04/2011 11:05, Howard Chu ha scritto:

...

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.

Sorry but I cannot agree to this. Using cn=config, at least for now, is far more complex. Saying that's just another DIT is misleading.

To understand configuration you need to understand what that DIT contents means, and the syntax you have to use for it. So you have to learn LDAP + LDIF + cn=config syntax.

And as far I can see the cn=config syntax is far more complex than the one of slapd.conf.

Probably I'm stupid but still I see as very hard to read all that {N} placed all around that you need to use as special values for DN's, and the same is for all those olcSomeThing attributes and those olcSomeClass objectclass that you have to use.

So something like:

slapadd -n0 dn: cn=config objectClass: olcGlobal cn: config

dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: MySecretPassword

<EOF>

for me is not easier to understand than saying change the rootpw line on the database stanza of your slapd.conf.

And sorry, probably its a bad habit, but I'm used to put comments in my configurations files, and I cannot see how I can do this here.

Regards Simone

I completely agree. As I said, a little statistic to understand what people use could be interesting. For me comments and a text file config is mandatory. I am not configuring mysql.cnf using a mysql database. As it has been said before, once your setup is done, you barely change it. And a little restart is not a problem using replicas. If some colleagues come after me (not specialized on ldap), they would be probably more comfortable with a traditional text file than using an ldap browser which just show DNs and attributes. That's may be great to replicate cn=config, but from some mails I red, it seems not so easy. The harder it is to configure, the less people use.

Dom

Hi!

my +1 to not dismiss slapd.conf.

I splitted my conf files in nested subdirectories, too. slapd.conf is very important for me!

thanks, Fabio

2011/4/22 Marco Pizzoli marco.pizzoli@gmail.com

...

I completely agree. As I said, a little statistic to understand what

people

...

use could be interesting. For me comments and a text file config is mandatory. I am not configuring mysql.cnf using a mysql database. As it

has

...

been said before, once your setup is done, you barely change it. And a little restart is not a problem using replicas. If some colleagues come after me (not specialized on ldap), they would be probably more comfortable with a traditional text file than using an ldap browser which just show DNs and attributes. That's may be great to replicate cn=config, but from some mails I red, it seems not so easy. The harder it is to configure, the less people use.

Hi all,

+1 to not dismiss slapd.conf.

Comments are my leading motivation in saying this. In my biggest deployment I used a complex configuration by splitting my conf files in nested subdirectories, mirroring conceptual separation of OpenLDAP components: database(s), overlays related to each database, security, modules, etc... I commented heavily each file and, in this way, I'm able to driver my colleagues on ordinarily activities, without the burden to have each of them become a full time specialist on OpenLDAP, letting me go on holiday more relaxed :-) I commented the rationale of my choices, not only the meaning of the configuration directives. In an office of about 10 unix systems administrators with large heterogeneity of skills and sw products this way has revealed to be an added value.

Not to be misunderstood, I like very much the cn=config way. But in my opinion it has to be a must in particular enterprise configurations, in example for bastion slaves used for H24 operational systems, or in situations where a network load balancer (to obtain failover, I mean) in between cannot be used.

My 2 cents.

Marco

On Thu, Apr 21, 2011 at 12:05 AM, Howard Chu hyc@symas.com wrote:

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, I *know* who you are, I am not new to OpenLDAP. So, please, take no offense, we are having just a discussion. Still, I'm yet to see any of my servers being corrupted by me editing the cn=config files directly! (well, it is also me... I *know* several admins that totally screwed config files, but I have been on the UNIX world for ~16 years, so, maybe I'm used to really tight files formatting) also, because these are LDIFs, these actually "yell" to be edited by hand! (you should add an ominous warning to the docs, stating that you should not edit those files directly, for x, y, or z reason).

Now, someone actually had a point here: is there a way to add *comments* to cn=config configuration? The fact that I never asked that question points something out: I'm actually not a big fan of comments, but there are people who like them a lot.

Howard: really, we are here arguing with you, because we actually like this work, and believe it can become even better than it is!

Ildefonso.

Hi!

On Thu, Apr 21, 2011 at 3:42 PM, Howard Chu hyc@symas.com wrote:

Jose Ildefonso Camargo Tolosa wrote:

...

On Thu, Apr 21, 2011 at 12:05 AM, Howard Chuhyc@symas.com  wrote:

...

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, I *know* who you are, I am not new to OpenLDAP.  So, please, take no offense, we are having just a discussion.

We are having a *STUPID* discussion. The man who knows this field has just told you it is full of landmines, and if you tread on it you will blow your foot off. You are arguing that it hasn't happened yet so therefore it must be perfectly safe. If you were sitting in front of me right now I would ask you to give me some money, because you are clearly a fool.

I *never* said it is safe, I just said that it has never failed for me (in my own, personal, experience), on the other side: it is very uncommon for me to be tweaking the configs after the server is up, I could say that I update the configs once a year or less!

...

Still, I'm yet to see any of my servers being corrupted by me editing the cn=config files directly! (well, it is also me... I *know* several admins that totally screwed config files, but I have been on the UNIX world for ~16 years, so, maybe I'm used to really tight files formatting)  also, because these are LDIFs, these actually "yell" to be edited by hand! (you should add an ominous warning to the docs, stating that you should not edit those files directly, for x, y, or z reason).

It is not my responsibility to tell you exactly where each landmine is. I have told you they exist; for a wise man that is enough. If you wish to seek out exactly where they lie, fine, spend your own time on that. It's certainly not a good use of my time.

Yet, the ominous warning on the docs would be good, maybe here?

http://www.openldap.org/doc/admin24/slapdconf2.html

As I said: the slapd.d directory structure is actually a bunch of ldif files, that you may think can directly edit! and, according to what you say: it can actually be a very bad idea! so, a warning on the docs would be wise (I don't think I can edit the docs, so, I can't add the warning myself).

Ildefonso.

On Wed, Apr 20, 2011 at 4:34 PM, Dan White dwhite@olp.net wrote:

On 20/04/11 16:01 -0430, Jose Ildefonso Camargo Tolosa wrote:

...

Now, if there was a graphical LDAP administration tool that handled the configuration: there would be a lot of happy people, and writing that tool (even by creating a template for existing tools) is now possible thanks to cn=config, it was not that easy with old slapd.conf file.

I've found ldapedit/ldiff, from:

http://www.aput.net/~jheiss/krbldap/tools/

to be indispensable in my own efforts to learn the new config backend.

E.g.:

LDAPBASE='cn=config' ./ldapedit objectClass=*

opens up the entire config data within an editor (based on your EDITOR environment variable), and then performs the necessary ldap modifications for you after you save and exit.

It does not properly handle changes to some of the more complex multi-line entries, such as the schema definitions.

All of this actually gives me an idea, if I use slapcat, create a copy, edit the copy, and then use ldapdiff to get modification script.... that could be simpler than writing the modification ldifs every time I need to do a change.