Database locking during kprops, MIT 1.8

[Ken Raeburn]

On Oct 10, 2010, at 19:46, Jeremy Hunt wrote:
> Hi Dominic,
> 
> Thanks for your feedback. You make a good point about reporting a bug. Though my memory is that the Kerberos team knew about them all..
> 
> The second issue is as designed, and given that kprop is so efficient, isn't as bad as I first thought when I read about it. Of course your experience does show its downside.
> 
> The second issue is reported in the Kerberos team's own documentation. Like I said I haven't seen it, ... yet. I reported it because they have and you might miss the warning.

I assume one of these is meant to say "third issue"?

The occasional need for kprop is basically only if iprop fails for long enough that the on-disk queue of changes overflows its configured size (which might just be hard-coded, I forget).  Unless you're making changes to large numbers of principals at once or losing connectivity for extended periods, it ought not to happen much.  And if you're changing most of your principals at once, a full kprop is probably more efficient anyways.

(I don't recall the occasional-losing-connectivity issue offhand, despite having worked with this code before when I was at MIT, but I'm at my non-Kerberos-hacking job at the moment and don't have time to look it up; maybe later.)

> The first issue, I assumed the kerberos development team already knew of. I will have to go back and look at my notes, but I thought I saw something in the code or the documentation that made me think they knew about it and it wasn't an easy fix. Certainly it behoves me to revisit this and to report it as a bug if my memory is wrong. Like I say, it is an observation that operationally does not affect us, btw a full dump/restore a la kprop will take across profiles.

It's not clear to me what you mean by "profile changes".  At least internally, we use "profile" to refer to the configuration settings from the config files.  Such things aren't and never have been recorded in the database nor automatically propagated between KDCs by any means in the Kerberos software; some of the settings are required to be consistent between KDCs for consistent operation, but others only affect the KDC making changes to the database.  If this isn't what you're referring to, please do explain.

Ken