> On Mar 24, 2017, at 8:09 AM, Adam Lewenberg <ada...@stanford.edu> 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
>> 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
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. hbh...@oxy.edu