From jhawk@bbnplanet.com Fri Oct 4 17:43:11 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id RAA22866 for <bugs@RT-11.MIT.EDU>; Fri, 4 Oct 1996 17:43:11 -0400
Received: from all-purpose-gunk.near.net by MIT.EDU with SMTP
id AA03851; Fri, 4 Oct 96 17:43:10 EDT
Received: (from jhawk@localhost) by all-purpose-gunk.near.net (8.8.0/8.8.0) id RAA01527; Fri, 4 Oct 1996 17:43:02 -0400 (EDT)
Message-Id: <199610042143.RAA01527@all-purpose-gunk.near.net>
Date: Fri, 4 Oct 1996 17:43:02 -0400 (EDT)
From: John Hawkinson <jhawk@bbnplanet.com>
To: krb5-bugs@MIT.EDU
Subject: kdb5_util load, et seq., messages may be misleading
Architecture: sun4
Ted asked me to submit this as a PR. I spent some
nontrivial amount of time banging my head against a wall
this morning trying to move my krb5b5 database to krb5b7. Hopefully
this is clear -- if not please bug me.
Essentially there were confusion error messages and my lack
of sleep didn't help.
Beta 5 was installed with --prefix=/krb5. Beta 7 with
--prefix=/usr/local/krb5.
I dumped the B5 database to /var/tmp/dump with kdb5_edit.
Initially, I attempted to load the database:
# kdb5_util load -old /var/tmp/dump
kdb5_util: Cannot find/read stored master key while initializing the kerberos context
load: cannot delete bad database /usr/local/krb5/lib/krb5kdc/principal~ (No such file or directory)
The second error doesn't seem to have a good reason for existing...
At this point I managed to conclude that it was necessary to "kdb5_util
create" the database before "kdb5_util load"-ing it. This produced
the following:
# kdb5_util create -s
Initializing database '/usr/local/krb5/lib/krb5kdc/principal' for realm 'BBNPLANET.NET',
master key name 'K/M@BBNPLANET.NET'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
# kdb5_util load -update -old /var/tmp/dump
# kadmin.local
kadmin.local: Decrypt integrity check failed while initializing kadmin.local interface
Because K/M is not consistent. I guess that error message is sane,
though specifying a bit more clearly might be better. I understood
it correctly.
At that point I tried a number of combinations of -update and load and
stashing the master key and trying to hack kdb5_util to read the
stashed key and failed miserably (should have gone to sleep, then).
Anyhow, I talked to Ted and it was clarified the problem was I needed
to:
# rm princ*
# cp /.k5.BBNPLANET.NET .
# kdb5_util load -old /var/tmp/dump
# kadmin.local
kadmin.local:
and things worked fine, rah, rah.
Umm, perhaps making the documentation a bit clearer on whether
"create" is a prerequisite for "load".
While we're at it, what's the deal with this:
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
Now, I deliberately forgget my Master Key. In fact, I generate it by
md5ing whatever's handy lying around and adding some random
characters. As far as I can tell there's no good reason to change this
practice...
Ummph.
--jhawk (still running since Thursday with no sleep...)
State-Changed-From-To: open-closed
State-Changed-By: bjaspan
State-Changed-When: Fri Oct 18 14:26:27 1996
State-Changed-Why:
Fixed. Files:
doc/kadm5/api-server-design.tex
lib/kadm5/ChangeLog
lib/kadm5/srv/adb_openclose.c
kadmin/dbutil/ChangeLog
kadmin/dbutil/dump.c
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: jhawk@bbnplanet.com
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/58: kdb5_util load, et seq., messages may be misleading
Date: Fri, 18 Oct 1996 14:23:22 -0400
I have once again changed the behavior of kdb5_util load somewhat. In
our last round, I changed it so that when you are loading a database
from a prior version of Kerberos it would create the policy database
automatically. I realized this was non-symmetric with the KDC
database, which is always created automatically. Therefore, kdb5_util
*always* will create a new policy database if one does not already
exist.
This means that kdb5_util create and kdb5_util load are the same
except in the following (significant) ways:
- create creates the default principals (K/M, krbtgt, kadmin/*). load
only creates kadmin/*, and only when loading a pre-beta-7 version; in
other cases, the default principals are assumed to exist in the dump
file.
- create has the ability to create a stash file, while load always
uses an existing stash file; the stash file must of course match the
dump file
So, your original problem (migrating from an old db to the current
system) is now solved:
% ./kdb5_util dump -old > /tmp/b5-dump
% ./kdb5_util destroy
Deleting KDC database stored in '/var/local/bjaspan/krb5/build/kadmin/testing/krb5-test-root/kdb5', are you sure?
(type 'yes' to confirm)? yes
OK, deleting database '/var/local/bjaspan/krb5/build/kadmin/testing/krb5-test-root/kdb5'...
** Database '/var/local/bjaspan/krb5/build/kadmin/testing/krb5-test-root/kdb5' destroyed.
% ./kdb5_util load /tmp/b5-dump
% ../cli/kadmin.local
kadmin.local:
Obviously, you would also have to copy the stash file to the right
place, etc. This should be documented.
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id RAA22866 for <bugs@RT-11.MIT.EDU>; Fri, 4 Oct 1996 17:43:11 -0400
Received: from all-purpose-gunk.near.net by MIT.EDU with SMTP
id AA03851; Fri, 4 Oct 96 17:43:10 EDT
Received: (from jhawk@localhost) by all-purpose-gunk.near.net (8.8.0/8.8.0) id RAA01527; Fri, 4 Oct 1996 17:43:02 -0400 (EDT)
Message-Id: <199610042143.RAA01527@all-purpose-gunk.near.net>
Date: Fri, 4 Oct 1996 17:43:02 -0400 (EDT)
From: John Hawkinson <jhawk@bbnplanet.com>
To: krb5-bugs@MIT.EDU
Subject: kdb5_util load, et seq., messages may be misleading
Show quoted text
>Number: 58
>Category: krb5-admin
>Synopsis: kdb5_util load, et seq., messages may be misleading
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: bjaspan
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Oct e 17:44:00 EDT 1996
>Last-Modified: Fri Oct e 14:28:00 EDT 1996
>Originator: John Hawkinson
>Organization:
BBN Planet>Category: krb5-admin
>Synopsis: kdb5_util load, et seq., messages may be misleading
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: bjaspan
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Oct e 17:44:00 EDT 1996
>Last-Modified: Fri Oct e 14:28:00 EDT 1996
>Originator: John Hawkinson
>Organization:
Show quoted text
>Release: beta-7
>Environment:
System: SunOS all-purpo 4.1.4 4 sun4m>Environment:
Architecture: sun4
Show quoted text
>Description:
Ted asked me to submit this as a PR. I spent some
nontrivial amount of time banging my head against a wall
this morning trying to move my krb5b5 database to krb5b7. Hopefully
this is clear -- if not please bug me.
Essentially there were confusion error messages and my lack
of sleep didn't help.
Show quoted text
>How-To-Repeat:
Beta 5 was installed with --prefix=/krb5. Beta 7 with
--prefix=/usr/local/krb5.
I dumped the B5 database to /var/tmp/dump with kdb5_edit.
Initially, I attempted to load the database:
# kdb5_util load -old /var/tmp/dump
kdb5_util: Cannot find/read stored master key while initializing the kerberos context
load: cannot delete bad database /usr/local/krb5/lib/krb5kdc/principal~ (No such file or directory)
The second error doesn't seem to have a good reason for existing...
At this point I managed to conclude that it was necessary to "kdb5_util
create" the database before "kdb5_util load"-ing it. This produced
the following:
# kdb5_util create -s
Initializing database '/usr/local/krb5/lib/krb5kdc/principal' for realm 'BBNPLANET.NET',
master key name 'K/M@BBNPLANET.NET'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
# kdb5_util load -update -old /var/tmp/dump
# kadmin.local
kadmin.local: Decrypt integrity check failed while initializing kadmin.local interface
Because K/M is not consistent. I guess that error message is sane,
though specifying a bit more clearly might be better. I understood
it correctly.
At that point I tried a number of combinations of -update and load and
stashing the master key and trying to hack kdb5_util to read the
stashed key and failed miserably (should have gone to sleep, then).
Anyhow, I talked to Ted and it was clarified the problem was I needed
to:
# rm princ*
# cp /.k5.BBNPLANET.NET .
# kdb5_util load -old /var/tmp/dump
# kadmin.local
kadmin.local:
and things worked fine, rah, rah.
Show quoted text
>Fix:
Umm, perhaps making the documentation a bit clearer on whether
"create" is a prerequisite for "load".
While we're at it, what's the deal with this:
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
Now, I deliberately forgget my Master Key. In fact, I generate it by
md5ing whatever's handy lying around and adding some random
characters. As far as I can tell there's no good reason to change this
practice...
Ummph.
--jhawk (still running since Thursday with no sleep...)
Show quoted text
>Audit-Trail:
State-Changed-From-To: open-closed
State-Changed-By: bjaspan
State-Changed-When: Fri Oct 18 14:26:27 1996
State-Changed-Why:
Fixed. Files:
doc/kadm5/api-server-design.tex
lib/kadm5/ChangeLog
lib/kadm5/srv/adb_openclose.c
kadmin/dbutil/ChangeLog
kadmin/dbutil/dump.c
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: jhawk@bbnplanet.com
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/58: kdb5_util load, et seq., messages may be misleading
Date: Fri, 18 Oct 1996 14:23:22 -0400
I have once again changed the behavior of kdb5_util load somewhat. In
our last round, I changed it so that when you are loading a database
from a prior version of Kerberos it would create the policy database
automatically. I realized this was non-symmetric with the KDC
database, which is always created automatically. Therefore, kdb5_util
*always* will create a new policy database if one does not already
exist.
This means that kdb5_util create and kdb5_util load are the same
except in the following (significant) ways:
- create creates the default principals (K/M, krbtgt, kadmin/*). load
only creates kadmin/*, and only when loading a pre-beta-7 version; in
other cases, the default principals are assumed to exist in the dump
file.
- create has the ability to create a stash file, while load always
uses an existing stash file; the stash file must of course match the
dump file
So, your original problem (migrating from an old db to the current
system) is now solved:
% ./kdb5_util dump -old > /tmp/b5-dump
% ./kdb5_util destroy
Deleting KDC database stored in '/var/local/bjaspan/krb5/build/kadmin/testing/krb5-test-root/kdb5', are you sure?
(type 'yes' to confirm)? yes
OK, deleting database '/var/local/bjaspan/krb5/build/kadmin/testing/krb5-test-root/kdb5'...
** Database '/var/local/bjaspan/krb5/build/kadmin/testing/krb5-test-root/kdb5' destroyed.
% ./kdb5_util load /tmp/b5-dump
% ../cli/kadmin.local
kadmin.local:
Obviously, you would also have to copy the stash file to the right
place, etc. This should be documented.
Show quoted text
>Unformatted: