On Jul 15, 2008, at 11:21, Klaus Heinrich Kiwi wrote:
> I'd like to know what are the supported methods of usage if I have to
> use two or more KDC instances with one LDAP directory. I can see a
> couple of scenarios but I'm not really sure what is the supported
> way of
> dealing with them. For example:
> 1) Two KDC servers, one LDAP server, same realm:
> Since LDAP has no locking mechanism, would there be potential race
> conditions? Is kpropd the correct way of doing this?

I think it's okay. You could run kadmind on only one server, if you
want to be extra careful. You wouldn't need kpropd in an LDAP setup.

In fact, kpropd is probably a bad idea in an LDAP setup. On the
receiving end, in the db2-backend case, it operates by loading a new
database file, and when that's done, renaming it to use the "real"
database file name. I don't know if it'll work properly at all for an
LDAP back end. However, be aware that this impression *isn't* based
on experience with that code, I mostly work with the db2 back end;
maybe it's flexible enough to deal with that and I hadn't noticed.

(The incremental-propagation changes we're folding in for the 1.7
release won't change this, even if you were propagating between non-
replicated LDAP installations or db2-to-LDAP, because in the too-far-
out-of-date case, it does a full-copy propagation to replace the slave
database, like the current implementation.)

> 3) one KDC server, two mirror LDAP servers, same realm:
> The way I see we would need LDAP synchronization between the LDAP
> servers
> 4) two KDC servers, two mirror LDAP servers, same realm:
> We should use kpropd + ldap synchronization?

Like Simo said, use LDAP replication, not kpropd, and things should be