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.