Event-based iprop (patch updated for 1.15)
basch at alum.mit.edu
Tue Jan 10 06:02:35 EST 2017
Personally, I think kpropd functionality should just be merged into kadmind to make it cleaner code. That is fundamentally the split-brain framework I had to work within (it drove me nuts).
The other recommendation would be to create a hook interface for all principal changes and layer this on the hook, but that is significantly more work. This also opens up other user-configurable options to judge if some operations should be performed and possibly override values based on local business rules. Downstream from the master, however, sync is the only logical response, but I guess it could selectively sync (this would be scary).
I'm willing to invest the time in the first (merging into kadmind) if you agree with such. The second, however, isn't on my radar... Eventually, after it is merged into one, I could see a collaborative operating mode between a couple kadmind where multi-master could be implemented... (This might be my next thing.) The hook, however, is something MIT needs to decide upon and deviates a bit from the current hook design.
Sent via my phone.
-------- Original message --------From: Greg Hudson <ghudson at mit.edu> Date: 1/10/17 12:36 AM (GMT-05:00) To: Richard Basch <basch at alum.mit.edu>, krbdev at mit.edu Subject: Re: Event-based iprop (patch updated for 1.15)
On 01/09/2017 09:11 PM, Richard Basch wrote:
> I have been sending a similar patch since 1.12… https://github.com/rbasch/krb5/wiki/1.15-Replication-Enhancements <https://github.com/rbasch/krb5/wiki/1.15-Replication-Enhancements>
Sorry for the lack of communication on this. I did some review and
amending of this patch at https://github.com/krb5/krb5/pull/352 . The
chief reason that it hasn't been merged is that I have some reservations
about the way kpropd notifies kadmind on intermediate KDCs, as noted in
the last two comments in the PR.
krbdev mailing list krbdev at mit.edu
More information about the krbdev