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 ; 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 To: krb5-bugs@MIT.EDU Subject: kdb5_util load, et seq., messages may be misleading >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 >Release: beta-7 >Environment: System: SunOS all-purpo 4.1.4 4 sun4m Architecture: sun4 >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. >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. >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...) >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" 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. >Unformatted: