19 Jan
2010
19 Jan
'10
2:09 a.m.
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
>