1
Some (intentional) changes from Sun's submission are noted in the
6
The "full resync" part of the protocol involves the master side firing
7
off a normal kprop (and going back to servicing requests), and the
8
slave side stopping all the incremental propagation stuff and waiting
9
for the kprop. If the connection from the master never comes in for
10
some reason, the slave side just blocks forever, and never resumes
11
incremental propagation.
13
The protocol does not currently pass policy database changes; this was
14
an intentional decision on Sun's part. The policy database is only
15
relevant to the master KDC, and is usually fairly static (aside from
16
refcount updates), but not propagating it does mean that a slave
17
maintained via iprop can't simply be promoted to a master in disaster
18
recovery or other cases without doing a full propagation or restoring
19
a database from backups.
21
Shawn had a good suggestion after I started the integration work, and
22
which I haven't had a chance to implement: Make the update-log code
23
fit in as a sort of pseudo-database layer via the DAL, being called
24
through the standard DAL methods, and doing its work around calls
25
through to the real database back end again through the DAL methods.
26
So for example, creating a "iprop+db2" database would create an update
27
log and the real db2 database; storing a principal entry would update
28
the update log as well; etc. At least initially, we wouldn't treat it
29
as a differently-named database; the installation of the hooks would
30
be done by explicitly checking if iprop is enabled, etc.
32
The "iprop role" is assumed to be either master or slave. The master
33
writes a log, and the slave fetches it. But what about a cascade
34
propagation model where A sends to B which sends to C, perhaps because
35
A's bandwidth is highly limited, or B and C are co-located? In such a
36
case, B would want to operate in both modes. Granted, with iprop the
37
bandwidth issues should be less important, but there may still be
38
reasons one may wish to run in such a configuration.
40
The propagation of changes does not happen in real time. It's not a
41
"push" protocol; the slaves poll periodically for changes. Perhaps a
42
future revision of the protocol could address that.
44
kadmin/cli/kadmin.c call to kadm5_init_iprop - is this needed in
45
client-side program? Should it be done in libkadm5srv instead as part
46
of the existing kadm5_init* so that database-accessing applications
47
that don't get updated at the source level will automatically start
48
changing the update log as needed?
50
Locking: Currently DAL exports the DB locking interface to the caller;
51
we want to slip the iprop code in between -- run it plus the DB update
52
operation with the DB lock held, whether or not the caller grabbed the
53
lock. (Does the caller always grab the lock before making changes?)
54
Currently we're using a file lock on the update log itself; this will
55
be independent of whether the DB back end implements locking (which
56
may be a good thing or a bad thing, depending).
58
Various logging calls with odd format strings like "<null>" should be
61
Why are different principal names used, when incremental propagation
62
requires that normal kprop (which uses host principals) be possible
65
Why is this tied to kadmind, aside from (a) wanting to prevent other
66
db changes, which locking protocols should deal with anyways, (b)
67
existing acl code, (c) existing server process?
69
The incremental propagation protocol requires an ACL entry on the
70
master, listing the slave. Since the full-resync part uses normal
71
kprop, the slave also has to have an ACL entry for the master. If
72
this is missing, I suspect the behavior will be that every two
73
minutes, the master side will (at the prompting of the slave) dump out
74
the database and attempt a full propagation.
76
Possible optimizations: If an existing dump file has a recent enough
77
serial number, just send it, without dumping again? Use just one dump
78
file instead of one per slave?
80
Requiring normal kprop means the slave still can't be behind a NAT or
81
firewall without special configuration. The incremental parts can
82
work in such a configuration, so long as outgoing TCP connections are
85
Still limited to IPv4 because of limitations in MIT's version of the
86
RPC code. (This could be fixed for kprop, if IPv6 sites want to do
87
full propagation only. Doing incremental propagation over IPv6 will
88
take work on the RPC library, and probably introduce
89
backwards-incompatible ABI changes.)
91
Overflow checks for ulogentries times block size?
93
If file can't be made the size indicated by ulogentries, shoud we
94
truncate or error out? If we error out, this could blow out when
95
resizing the log because of a too-large log entry.
97
The kprop invocation doesn't specify a realm name, so it'll only work
98
for the default realm. No clean way to specify a port number, either.
99
Would it be overkill to come up with a way to configure host+port for
100
kpropd on the master? Preferably in a way that'd support cascading
103
The kadmind process, when it needs to run kprop, extracts the slave
104
host name from the client principal name. It assumes that the
105
principal name will be of the form foo/hostname@REALM, and looks
106
specifically for the "/" and "@" to chop up the string form of the
107
name. If looking up that name won't give a working IPv4 address for
108
the slave, kprop will fail (and kpropd will keep waiting, incremental
109
updates will stop, etc).
111
Mapping between file offsets and structure addresses, we should be
112
careful about alignment. We're probably okay on current platforms,
113
but if we break log-format compatibility with Sun at some point, use
114
the chance to make the kdb_ent_header_t offsets be more strictly
115
aligned in the file. (16 or 32 bytes?)
117
Not thread safe! The kdb5.c code will get a lock on the update log
118
file while making changes, but the lock is per-process. Currently
119
there are no processes I know of that use multiple threads and change
120
the database. (There's the Novell patch to make the KDC
121
multithreaded, but the kdc-kdb-update option doesn't currently
124
Logging in kpropd is poor to useless. If there are any problems, run
125
it in debug mode ("-d"). You'll still lose all output from the
126
invocation of kdb5_util dump and kprop run out of kadmind.
128
Other man page updates needed: Anything with new -x options.
132
Verify both client and server are demanding privacy from RPC.
134
Authorization code in check_iprop_rpcsec_auth is weird. Check realm
135
checking, is it trusting the client realm length?
137
What will happen if my realm is named "A" and I can get a cross realm
138
(though multihop) to ATHENA.MIT.EDU's iprop server?
140
Why is the ACL not applied before we get to the functions themselves?
added
removed
doc/iprop-notes.txt
