Re: ipropd question

> On Mar 24, 2017, at 8:09 AM, Adam Lewenberg <[email protected]> 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’d recommend forcing iprop to do a full download instead. This used to be entirely too easy to trigger, but there has been some work since. “False” downloads seemed to be more common when you have a lot of slaves.

I don’t know what the “recommended” way to trigger a re-download would be, but certainly if you delete the kdb and the log file on a slave and start ipropd-slave it will re-download. Just make sure you don’t have the slave’s kdc running until the new kdb is available or it will be telling people (including its own ipropd-slave!!) that principals don’t exist when it shouldn’t!

Personal email.  [email protected]