Re: ipropd question

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/[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