On 09/22/2018 09:44 AM, John Devitofranceschi wrote: > In order to remedy this, we tried using a pre-mistake backup (dump format) of > the kdb to restore the principals: > > kdb5_util load -update dumpfile principal > > However this did not work. This is what’s documented in the MIT docs. We > were expecting to be able to run this once per missing principal.
I found an example in database.rst which implies this capability, and yeah, it's wrong. The kdb5_util man page instead says that load has an optional dbname parameter at the end, which is also wrong (and wouldn't make much sense; such a parameter would be redundant with kdb5_util -d). I will consider adding a principal matching feature to kdb5_util load, and will definitely make a pass over the dump/load documentation for accuracy. > Is there any easier way to do this? I probably would have filtered the dump file with text processing. > When when loaded the missing principals, we shut down kadmind. Was this > necessary? Or will kdb5_util lock the KDB properly when loading? Shutting down kadmind was not necessary. > When the missing principals were being added, the load process also reported > that it added polices. Why did it do that? If the policies are already > there, is this a no-op? It looks like when kdb5_util dump is given principal names, it still dumps policy entries; that should probably be considered a bug. The policy load operations were not no-ops; if there were any changes to policy entries between the dump file and the current state, those changes have likely been reverted. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
