Re: ipropd question

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/[email protected]  IPv4:192.168.6.34     7158  Up 
> 2017-03-24T09:15:01
> iprop/[email protected]  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 				[email protected]
4254 Stadium Dr				(301) 405-6135
University of Maryland
College Park, MD 20742-4111