that change the database also write information about the changes to
an ``update log'' file, maintained as a circular buffer of a certain
size. A process on each slave KDC connects to a service on the master
-KDC (currently implmented in the @code{kadmind} server) and
+KDC (currently implemented in the @code{kadmind} server) and
periodically requests the changes that have been made since the last
check. By default, this check is done every two minutes. If the
database has just been modified in the previous several seconds
ACL setup previously described for @code{kprop} propagation is still
needed.
-There are several known bugs and restrictions in the current
-implementation:
+There are several restrictions in the current implementation:
+
@itemize
@item
-The ``call out to @code{kprop}'' mechanism is a bit fragile; if the
-@code{kprop} propagation fails to connect for some reason, the process
-on the slave may hang waiting for it, and will need to be restarted.
+Changes to password policy objects are not propagated incrementally.
+Changes to which policy applies to a principal are propagated.
@item
The master and slave must be able to initiate TCP connections in both
-directions, without an intervening NAT. They must also be able to
-communicate over IPv4, since MIT's kprop and RPC code does not
-currently support IPv6.
+directions, without an intervening NAT.
+@item
+If the slave has an IPv6 interface address but needs to accept
+connections over IPv4, the operating system needs ``dual stack'' support
+(i.e. the ability to accept IPv6 and IPv4 connections on a single IPv6
+listener socket). At this time, all modern Unix-like operating systems
+have dual stack support except OpenBSD.
@end itemize
@menu
projects / krb5.git / blobdiff