From f850b7ddfb3eae04c4d7be187177344b70f9983c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Love=20H=C3=B6rnquist=20=C3=85strand?= Date: Sun, 11 Jan 2009 21:45:17 +0000 Subject: [PATCH] some more iprop git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@24260 ec53bebd-3082-4978-b11e-865c3cabbd6b --- doc/setup.texi | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/doc/setup.texi b/doc/setup.texi index 08b400020..c70377633 100644 --- a/doc/setup.texi +++ b/doc/setup.texi @@ -555,7 +555,7 @@ good idea. @node Incremental propagation, Encryption types and salting, Slave Servers, Setting up a realm @section Incremental propagation -There is also a newer, and still somewhat experimental, mechanism for +There is also a newer mechanism for doing incremental propagation in Heimdal. Instead of sending the whole database regularly, it sends the changes as they happen on the master to the slaves. The master keeps track of all the changes by assigning a @@ -572,6 +572,14 @@ the current version at the master (a series of @samp{FORYOU} messages) or the whole database in a @samp{TELLYOUEVERYTHING} message. There is also a keep-alive protocol that makes sure all slaves are up and running. +In addition on listening on the network to get connection from new +slaves, the ipropd-master also listens on a status unix +socket. kadmind and kpasswdd both open that socket when a transation +is done and written a notification to the socket. That cause +ipropd-master to check for new version in the log file. As a fallback in +case a notification is lost by the unix socket, the log file is +checked after 30 seconds of no event. + @subsection Configuring incremental propagation The program that runs on the master is @command{ipropd-master} and all