[Date Prev][Date Next]
Re: multimaster configuration of openldap-2.0.25
On Fri, Aug 30, 2002 at 09:32:30PM +0000, Pierangelo Masarati wrote:
| Alan Sparks writes:
| > Keep in mind I've done this in 2.1.x, not 2.0.x, but the advice may be
| > useful:
| > 1) I'm not sure that --enable-multimaster is a really valid configure
| > option. Suggest that, after running the configure command, you manually
| > edit the include/portable.h file and make sure SLAPD_MULTIMASTER is
| > defined. Then 'make depend && make'.
| I think at some time there was an --enable-multimaster switch,
| but it was removed because it is experimental and caused some
| complaints. You can also do (with bash; appropriate solutions
| must be applied to different shells):
| prompt$ CPPFLAGS=-DSLAPD_MULTIMASTER ./configure
| > 2) You should use an updatedn in both server configs. I use the same DN
| > on both servers, a different one than the rootdn. In other words, I have
| > the same updatedn config directive on both servers.
| > If you're using access control lists, I've noted that the ACLs need to
| > allow the updatedn write access explicitly. (no different than
| > single-master replication). It's been suggested that updatedn is treated
| > specially, but that hasn't worked for me-- and I don't see the special
| > allowance for it in the code like I do for rootdn.
| It is treated differently (can modify some NO-USER-MODIFICATION
| attributes, and its changes are not propagated to slaves); however
| it is not treated any specially with regard to ACLs (though it could,
| to ease 99% of the administration needs).
| Everything else looks correct.
Not unless there has been some changes to the multimaster code.
When I looked at the latest versions recently, enabling multimaster lets
*anyone* modify no-user-modification attributes. This is *very* broken.
I posted something on openldap-devel about this back in July.