Hi Ralf,

Thanks for that, after quick discussion with other admins, we've decided just to drop the cn=config configuration and switch the database to file config.
Although cn=config gives the nice ability to do the config on the fly, it is still too undocumented and irritating to use...
And I did what I want in ten minutes with file config, instead of 3 days :)
Anyway, thanks for all answers.

One suggestion is, that it would be great to have a 'config-like' interface for editing cn=config. I mean something like visudo, so an overlay that converts the cn=config to file, displays for editing and then does the forward conversion again when saving..
But this is probably too complicated to implement :)

Thanks guys!

--
Best regards,
Radek Antoniuk


On Tue, Jan 19, 2010 at 9:37 AM, Ralf Haferkamp <rhafer@suse.de> wrote:
Am Montag 18 Januar 2010 11:07:50 schrieb Radosław Antoniuk:
> Hi again guys,
>
> Ok, coming back on the technical track.
> Nobody replied so I'll ask again.. and few more thoughts actually:
>
> 1. Is it okay to stop the daemon, and literally remove the lines from
> the config files in slapd.d dir? (i.e. actually removing the file in
> cn\=config/olcDatabase\=\{0\}config/* )
I wouldn't recommend doing that. But you might try to remove the
corresponding "olcOverlay{[1-3]}=syncprov" files and see what happens.
YMMV. Starting over otoh shouldn't be too hard normally. Just slapcat you
configuration, cleanup and slapadd it again. Same for the "real"
(bdb/hdb) databases.

> I presume that something stays in the bdb/hdb or this is just the
> place of the status counter/pointer?
For the syncprov overlay at least the contextCsn Attribute is stored in
the underlying database backend.

> I know that probably it is a dirty hack but actually when I did that
> for rootDN password it worked..

> Or... I'll ask the question again because there was no answer - is it
> safe to leave it as is and don't bother?
>
> 2. What is the sence at all of having more than one overlay of the
> same type for a backend? shouldn't it be prohibited by the engine? or
> is there a use case when it actually is needed?
I don't know a valid usecase for multiple instances of the syncprov
overlay on one databases. But AFAIK for some other overlays is is
perfectly fine. IIRC the "memberof" Overlay is one of them.
You might want to file an enhancement request that "syncprov" shouldn't
be allowed to be configured multiple times for a single database.

> Question out of curiosity, why the backend doesn't support delete?
> Issues with deletion of the database or a simple reason like "don't
> delete your database" or something deeper technically?
One reason is, that it is pretty hard to cleanup correctly the remaining
of an overlay during runtime. For some overlays it might not be possible
with reasonalbe effort at all. There is however experimental delete
support for databases and overlays in HEAD you might want to test that.

--
Ralf