Next: , Previous: Slave Servers, Up: Setting up a realm

4.10 Incremental propagation

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 version number to every change to the database. The slaves know which was the latest version they saw and in this way it can be determined if they are in sync or not. A log of all the changes is kept on the master, and when a slave is at an older version than the oldest one in the log, the whole database has to be sent.

Protocol-wise, all the slaves connect to the master and as a greeting tell it the latest version that they have (`IHAVE' message). The master then responds by sending all the changes between that version and the current version at the master (a series of `FORYOU' messages) or the whole database in a `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.

4.10.1 Configuring incremental propagation

The program that runs on the master is ipropd-master and all clients run ipropd-slave.

Create the file /var/heimdal/slaves on the master containing all the slaves that the database should be propagated to. Each line contains the full name of the principal (for example `iprop/').

You should already have `iprop/tcp' defined as 2121, in your /etc/services. Otherwise, or if you need to use a different port for some peculiar reason, you can use the --port option. This is useful when you have multiple realms to distribute from one server.

Then you need to create those principals that you added in the configuration file. Create one `iprop/hostname' for the master and for every slave.

     master# /usr/heimdal/sbin/ktutil get iprop/`hostname`
     slave# /usr/heimdal/sbin/ktutil get iprop/`hostname`

The next step is to start the ipropd-master process on the master server. The ipropd-master listens on the UNIX domain socket /var/heimdal/signal to know when changes have been made to the database so they can be propagated to the slaves. There is also a safety feature of testing the version number regularly (every 30 seconds) to see if it has been modified by some means that do not raise this signal. Then, start ipropd-slave on all the slaves:

     master# /usr/heimdal/libexec/ipropd-master &
     slave#  /usr/heimdal/libexec/ipropd-slave master &

To manage the iprop log file you should use the iprop-log command. With it you can dump, truncate and replay the logfile.

4.10.2 Status of iprop master and slave

Both the master and slave provides status of the world as they see it.

The master write outs the current status of the slaves, last seen and their version number in /var/heimdal/slaves-stats.

The slave write out the current status in /var/heimdal/ipropd-slave-status.

These locations can be changed with command line options, and in the case of ipropd_master, the configuration file.