diff options
author | Ken Raeburn <raeburn@mit.edu> | 2008-07-31 13:42:49 +0000 |
---|---|---|
committer | Ken Raeburn <raeburn@mit.edu> | 2008-07-31 13:42:49 +0000 |
commit | bbe00be17ce30e83975e1ecbb70da14c04e52095 (patch) | |
tree | 20ea3dd60ba83e4bd55a79c13a016addc299448a /doc | |
parent | 915deb505f7446c4c5a43fe01e983b5e0355ad95 (diff) | |
download | krb5-bbe00be17ce30e83975e1ecbb70da14c04e52095.tar.gz krb5-bbe00be17ce30e83975e1ecbb70da14c04e52095.tar.xz krb5-bbe00be17ce30e83975e1ecbb70da14c04e52095.zip |
note lack of policy propagation
git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@20592 dc483132-0cff-0310-8789-dd5450dbe970
Diffstat (limited to 'doc')
-rw-r--r-- | doc/iprop-notes.txt | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/doc/iprop-notes.txt b/doc/iprop-notes.txt index 2b1ee43c20..890efdc1e9 100644 --- a/doc/iprop-notes.txt +++ b/doc/iprop-notes.txt @@ -10,6 +10,14 @@ for the kprop. If the connection from the master never comes in for some reason, the slave side just blocks forever, and never resumes incremental propagation. +The protocol does not currently pass policy database changes; this was +an intentional decision on Sun's part. The policy database is only +relevant to the master KDC, and is usually fairly static (aside from +refcount updates), but not propagating it does mean that a slave +maintained via iprop can't simply be promoted to a master in disaster +recovery or other cases without doing a full propagation or restoring +a database from backups. + Shawn had a good suggestion after I started the integration work, and which I haven't had a chance to implement: Make the update-log code fit in as a sort of pseudo-database layer via the DAL, being called |