"kdb5_util load -update" best practice

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

"kdb5_util load -update" best practice

John Devitofranceschi

This week about 100 host and other service principals were deleted by mistake, rendering the owning systems and services unusable.

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.

So instead we loaded the backup dump into a temporary kdb and extracted the missing principals into a separate dump file:

    kdb5_util -d tempKDB load dumpfile
    kdb5_util -d tempKDB dump missing-princs-dumpfile princ1 princ2 … princN

 and ran this:

    kdb5_util load -update missing-princs-dumpfile

which worked. Systems restored; drinks all ‘round.

Questions:

Is there any easier way to do this?

When when loaded the missing principals, we shut down kadmind. Was this necessary? Or will kdb5_util lock the KDB properly when loading? We were worried about potential corruption if the KDB was not in a quiescent state.

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?

We’re using MIT Kerberos 1.13.2, by the way.

jd
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: "kdb5_util load -update" best practice

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

Re: "kdb5_util load -update" best practice

John Devitofranceschi


> On Sep 22, 2018, at 10:39 AM, Greg Hudson <[hidden email]> wrote:
>
> 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.
Thanks!

>
>> Is there any easier way to do this?
>
> I probably would have filtered the dump file with text processing.
>

So, just put  the header line and then any needed principals from the backup dump into a text file? That’s all there is to it?




________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: "kdb5_util load -update" best practice

Greg Hudson
On 09/24/2018 07:07 AM, John Devitofranceschi wrote:
> So, just put  the header line and then any needed principals from the backup dump into a text file? That’s all there is to it?

Correct.  Of course your text processing needs to know that dump lines
are tab-separated, that principal entries have "princ" in the first
field, and that the principal name is in the seventh field.

I will also try to find time to write up documentation for the dump file
format for doc/formats.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos