[28256] in CVS-changelog-for-Kerberos-V5
krb5 commit: Document hierarchical iprop
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Feb 20 21:25:47 2014
Date: Thu, 20 Feb 2014 21:25:37 -0500
From: Greg Hudson <ghudson@mit.edu>
Message-Id: <201402210225.s1L2Pbrx025703@drugstore.mit.edu>
To: cvs-krb5@mit.edu
Reply-To: krbdev@mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cvs-krb5-bounces@mit.edu
https://github.com/krb5/krb5/commit/e87bba2e8a8c753b761227dda5f2e216a6771db2
commit e87bba2e8a8c753b761227dda5f2e216a6771db2
Author: Greg Hudson <ghudson@mit.edu>
Date: Tue Jan 28 14:19:33 2014 -0500
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 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/doc/admin/database.rst b/doc/admin/database.rst
index ab134b0..7e7e8de 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.
_______________________________________________
cvs-krb5 mailing list
cvs-krb5@mit.edu
https://mailman.mit.edu/mailman/listinfo/cvs-krb5
