Event-based iprop (patch updated for 1.15)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Event-based iprop (patch updated for 1.15)

Richard Basch
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>


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Event-based iprop (patch updated for 1.15)

Greg Hudson
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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Event-based iprop (patch updated for 1.15)

Richard Basch
In reply to this post by Richard Basch
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 <[hidden email]> Date: 1/10/17  12:36 AM  (GMT-05:00) To: Richard Basch <[hidden email]>, [hidden email] 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Loading...