My experience is that ipropd-slave will try to apply the change log
sent from the master, but if it cannot for some reason, it will ignore
the change but bump the database version (and log a warning/error in
its logs).  There are pros and cons of that behavior; briefly it makes
the ipropd service more "robust" but also means that if one is not monitoring
the logs the DBs can get out of sync.

The upshot is, monitoring DB synchronization by looking at slaves-stats file is NOT sufficient.

We generally do a listing of the names, kvnos, and last mod
times for all principals on all the KDCs every night around 3-4 AM
(to minimize false positives from actual updates) and compare to ensure the DBs stay synchronized.



On Fri, 24 Mar 2017, Martin Flemming wrote:

Hi !

I want to use the iprop-mechanism but i'm little confused
if all running really well ...

My setup looks like follow

3 heimdal-server with Centos 7.3.1611

heimdal-rpms from epel :

heimdal-libs-1.6.0-0.9.20140621gita5adc06.el7.x86_64
heimdal-server-1.6.0-0.9.20140621gita5adc06.el7.x86_64

On the first view everything seems to be ok :

master :

cat slaves-stats
Status for slaves, last updated: 2017-03-24T09:16:31

Master version: 7158

Name Address Version Status Last Seen iprop/server2.desy...@desy.de IPv4:192.168.6.34 7158 Up 2017-03-24T09:15:01 iprop/server3.desy...@desy.de IPv4:192.168.6.37 7158 Up 2017-03-24T09:15:01

On both Slaves seems also everything ok

Mar 24 09:25:02 server2 ipropd-slave[3001]: slave status change: up-to-date with version: 7158 at 2017-03-24T09:25:02 Mar 24 09:27:32 server2 ipropd-slave[3001]: slave status change: up-to-date with version: 7158 at 2017-03-24T09:27:32
Mar 24 09:30:01 server2 ipropd-slave[3001]: replaying entry 7159
Mar 24 09:30:01 server2 ipropd-slave[3001]: slave status change: up-to-date with version: 7159 at 2017-03-24T09:30:01 Mar 24 09:30:01 server2 ipropd-slave[3001]: slave status change: up-to-date with version: 7159 at 2017-03-24T09


But if i dump and count all Principals on these 3 heimdal-server,
i've got 3 differents results :-(

kadmin -l list  \* > kadmin_list.txt
cat kadmin_list.txt |wc


Master : 31027
Slave1 : 30453
Slave2 : 29311

Can somebody explain this behaviour or is the ipropd-mechanism buggy ?

Or have i to upgrade to Heimdal 7.1.0 (own build from tar-package :-( ) ?

Major changes

   ....
   ....
iprop has been revamped to fix a number of race conditions that could lead to inconsistent replication.
   ....
   ....

thanks & cheers

      Martin




Tom Payerle
IT-ETI-EUS                              paye...@umd.edu
4254 Stadium Dr                         (301) 405-6135
University of Maryland
College Park, MD 20742-4111

Reply via email to