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 <[email protected]> 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 >
