> 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 >> 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. hbh...@oxy.edu
