On 04/25/2014 10:05 AM, Kenneth MacDonald wrote: > Thinking aloud ... I wonder how difficult it would be to have krb5kdc > optionally stop recording failures while the database is locked.
The database is frequently locked for short periods of time, so I think this would make failure recording pretty unpredictable. I agree that we need to do something, though. I can see two basic avenues: 1. We might not really need to lock around iprop full resync dumps. Instead of creating a snapshot of serial number N, we can create a dump where every entry reflects at least serial number N, as long as updates for subsequent serial numbers are idempotent (which requires a small change to how we handle deletes). We've been reluctant to do this in the past because it makes the iprop system harder to analyze, but we don't know of anything it actually breaks. 2. We could somehow arrange for longer-term global locks to still allow updates to the (non-replicated) account lockout attributes, or store the non-replicated attributes in a completely different database. This is a more difficult change but could result in some code simplifications. I will file an issue in our bug tracker for this. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
