From e87bba2e8a8c753b761227dda5f2e216a6771db2 Mon Sep 17 00:00:00 2001 From: Greg Hudson Date: Tue, 28 Jan 2014 14:19:33 -0500 Subject: Document hierarchical iprop Also remove an outdated caveat, but add a new one about policy changes causing full resyncs. ticket: 7855 --- doc/admin/database.rst | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/doc/admin/database.rst b/doc/admin/database.rst index ab134b029f..7e7e8de9a5 100644 --- a/doc/admin/database.rst +++ b/doc/admin/database.rst @@ -826,12 +826,19 @@ point in the update log at which the slave should resume fetching incremental updates. Thus, all the keytab and ACL setup previously described for kprop propagation is still needed. -There are several known bugs and restrictions in the current -implementation: - -- The "call out to kprop" mechanism is a bit fragile; if the kprop - propagation fails to connect for some reason, the process on the - slave may hang waiting for it, and will need to be restarted. +If an environment has a large number of slaves, it may be desirable to +arrange them in a hierarchy instead of having the master serve updates +to every slave. To do this, run ``kadmind -proponly`` on each +intermediate slave, and ``kpropd -A upstreamhostname`` on downstream +slaves to direct each one to the appropriate upstream slave. + +There are several known restrictions in the current implementation: + +- The incremental update protocol does not transport changes to policy + objects. Any policy changes on the master will result in full + resyncs to all slaves. +- The slave's KDB module must support locking; it cannot be using the + LDAP KDB module. - The master and slave must be able to initiate TCP connections in both directions, without an intervening NAT. -- cgit