Michael Ströder writes:

Hallvard B Furuseth wrote:

...

Quanah Gibson-Mount wrote in openldap-technical:

...

You need to specify that you want to use the config db (-n 0) with your slapadd command.

If neither -n nor -b is given, maybe slapadd should decide which database to open from the DN of the first input entry?

You'll never know how broken the LDIF file is => I disagree.

What kind of breakage are you afraid of slipping through? You'll know if it's outside any of your suffixes, or if it spans two databases. Though the latter only after the first has been modified.

...

What kind of breakage are you afraid of slipping through? You'll know if it's outside any of your suffixes, or if it spans two databases. Though the latter only after the first has been modified.

I know that one could find a way to make it work most times and spit out some error messages if it's wrong. Indeed I'm in favor of smarter handling of command-line options if there's a single way to get it right.

But when implementing automagic one has to consider whether there could be a significant amount of cases for which the user comes to the mailing list asking silly questions because he don't understand the error message. In this particular case I'd vote for forcing the user to learn how to use -n or -b.

Opening the correct db based on entries present in the file seems fairly reasonable. I'd even consider re-opening different db's as necessary through the file if they include multiple suffixes, though that's more work.

As far as error messages, this removes the number of cases where someone would see a message, so it should help on the bad questions front. While delivering simple messages is good, it's rather silly to present errors when we can clearly identify what the user wants, the semantics are unambiguous, and there is a straightforward path to implementation.

Matthew Backes Symas Corporation mbackes@symas.com

In part, I favor Michael's argument. In fact, the only reason for preferring a picky slapadd is to avoid trouble. An experienced user will not likely get in trouble, like using a wrong ldif file instead of the right one. The inexperienced or incautious user would probably erroneously feel safe when the wrong ldif happens to load in the right, yet unintended database.

There isn't much hazard involved here; typically slapadd will be done to empty databases. If they have multiple suffixes they likely have multiple ldif files. Automatically loading into "the other backend" several times would still produce the desired end result, as they are more or less independent. If they have one single ldif for multiple suffixes, then traditional slapadd can offer them no help at all.

In the case where they have multiple backends and some are populated and some aren't, and they pick the wrong ldif file, likely either it is a backend they needed to load soon anyway or the objects are already present and nothing will happen as a result.

My favorite approach would be to have slapadd return more sophisticated and useful messages, like

Better messages are always a good idea.

the first entry "cn=foo,dc=z" seems to belong to database #X, whose suffix is "dc=z"; did you mean to use -n X (or -b "dc=z")?

It may be a good idea to emit informational warnings about backend selection.

With respect to the "smart" behavior Matthew suggests (loading multiple databases within one execution of slapadd), it looks definitely intriguing, but since it quite departs from the current behavior, I'd protect it behind an explicit switch (e.g. -b "", or - n "detect").

Purely from a UI perspective, -b "" sounds like loading LDIF into the rootDSE; a bit confusing perhaps. Additionally, empty arguments tend to cause great confusion between users and their shell. -n detect sounds okay.

It might be a reasonable default as it is only changing behavior for what was previously an error condition. While users might rely on all sorts of odd features, it seems unlikely that anyone relies on slapadd to print and error and do nothing in this case.

Perhaps if someone were used to populating suffixes with ldifs, and used slapadd in a for-loop to do this, checking the exit code to find out when the right ldif had been found. Seems far-fetched though.

Still, having it available as an option is better than nothing.

Matthew Backes Symas Corporation mbackes@symas.com

Pierangelo Masarati writes:

The inexperienced or incautious user would probably erroneously feel safe when the wrong ldif happens to load in the right, yet unintended database.

I don't quite get it. Which unintended database? There is only one database into which any entry will go, based on the DN.

If you just mean the user slapadds an LDIF he shouldn't have slapadded, well, though. The user might do lots of things he didn't intend to, like accidentally typing rm * instead of rm something*. Besides, the slapadd can succeed already since there already is a default database to try.

My favorite approach would be to have slapadd return more sophisticated and useful messages,

That's always good.

With respect to the "smart" behavior Matthew suggests (loading multiple databases within one execution of slapadd), it looks definitely intriguing, but since it quite departs from the current behavior, I'd protect it behind an explicit switch (e.g. -b "", or -n "detect").

If so, I'd prefer -b- and -n-.

Pierangelo Masarati writes:

Hallvard B Furuseth wrote:

...

There is only one database into which any entry will go, based on the DN.

Right. However, slapadd does not behave like that, right now. It always tries to feed database #1 (possibly skipping "cn=Monitor" and any subordinate database).

Right, but this doesn't mean -b/-n affects which database an entry will be put in. It merely affects whether the attempt to add the entry will succeed. Which is why I've been a confused by the previous messages.

...

If you just mean the user slapadds an LDIF he shouldn't have slapadded, well, though. The user might do lots of things he didn't intend to, like accidentally typing rm * instead of rm something*.

rm has noclobber to prevent misuse. slapadd has -b/-n.

s/noclobber/-i/. (noclobber prevents redirects from overwriting.) And we are talking about the case of not using either option.

...

Besides, the slapadd can succeed already since there already is a default database to try.

Right. I don't quite like that behavior (I don't like defaults, unless they are very intuitive and trivial, and yes, what's intuitive and trivial can be very subjective, so I don't like much defaults)

I agree, which is why I suggested to remove it:-) But removing the default without adding auto-choice would be an option too.

The default wasn't much of a problem before, but with the addition of cn=config people will need to play with multiple databases.

Anyway, let's see for now if your improved error helps helps.

Hallvard B Furuseth wrote:

Anyway, let's see for now if your improved error helps helps.

That's just a first trivial round, I0m open to suggestions (like Michael's).

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 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------