On Fri, 24 Mar 2017, Adam Lewenberg wrote:




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.


I wouldn't merge hprop and iprop together, we use hprop (all 15 minutes)
for years without any problems, but now we consider to switch to be little more modern ;-)

Maybe we've to test the new version 7.1, unfortunatley without any official packages support, only on selfmade packages ... or we still stay in hprop-mechanism ...

Any further suggestions or experiences ?

thanks & have a nice weeekend


        martin






 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



Gruss

       Martin Flemming


______________________________________________________
Martin Flemming
DESY / IT          office : Building 2b / 008a
Notkestr. 85       phone  : 040 - 8998 - 4667
22603 Hamburg      mail   : martin.flemm...@desy.de
______________________________________________________

Reply via email to