On 3/24/2017 7:21 AM, Thomas M. Payerle wrote:
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.

That makes me think that doing a periodic "hprop" from the master to each replica might not be a bad thing.

However, what happens when a slave gets an hprop dump at the same time the slave is running ipropd-slave? Might there not be some contention? For example, if in the middle of the hprop dump the master sends a change through ipropd.







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