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.
Post by Richard BaschI 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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailm