Bug 143605 - mit-krb5-1.4.3-r3 does not warn that you may be unable to read your kerberos database
|
Bug#:
143605
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: critical
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: kerberos@gentoo.org
|
Reported By: olivier@calle.org
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: mit-krb5-1.4.3-r3 does not warn that you may be unable to read your kerberos database
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2006-08-11 14:00 0000
|
Due to 2 changes between -r1 and -r3 of mit-krb5-1.4.3, you may be unable to
access your kerberos database with -r3.
First, localstatedir used to be /etc, and is now /var/lib, but the ebuild makes
no effort to notify you of that change so that you may move things around.
However, even if you succeed in passing the first obstacle, you run into a
second, more serious problem. Because -r3 now uses the internal berkdb, you
may not be able to access your kerberos database at all. For the time being,
so that I could still have a working KDC, I built my own local ebuild which
returned the localstatedir to /etc and used the system berkdb.
It would have really been nice to _at least_ have had some warning from the
ebuild that this could occur.
Olivier,
you are absolutely correct, we should have put some notifications in the ebuild
and given a smoother across-grade path for the db change. Allow us to ponder
this among the team. In the meantime, I offer you my hearfelt apology.
Sorry from me too, but I'm afraid I can't do more than adding a warning (which
should have been there in the first place, blame me); the problem is, upstream
does not support a configuration with external db; moreover with the previous
ebuilds the user could create a mess by switching on/off the berkdb use flag,
meaning in this case "use the external/internal db". Doing the db location
change together with unconditionally using the internal db at the same time was
the safest choice and no, it wouldn't be wise to suggest to move the db to the
new location because you can't be sure the existing ones are compatible if the
previous build was with berkdb in USE. Suggestions are welcome.
Created an attachment (id=94960) [details]
Steps I used to migrate my Kerberos database
First of all thanks for the apologies :-) I agree that making these changes
was the correct thing to do.
Anyway, I've attached some notes outlining the steps I took to use 1.4.3-r3
while migrating my Kerberos database. These steps seem to have worked for me.
I hope they are of some use.
Thanks, I really appreciate your help. The problem is, there is no way I can
tell the user to dump the db before the old kdb5_util is replaced by the new
one.
Yeah, this sadly, is a bitch of a bug that just hit me.
=(
FYI - Somehow, I lost the master password to my database. Or, I typed it in
wrong a year ago. So, after emergeing 1.4.3-r1, I ran this:
kdb5_util dump -mkey_convert > dump.txt
*note: It prompts you for a new password on stdout (wtf) so you can't see the
two requests for input. So, just type the /new/ password in twice, then the
export will complete.
After doing this, I was able to resume following the instructions. I have
1.4.3-r3 installed and running now. Thanks for the instructions. =) I could
not remember how to do that, and I was about to go through the Admin Guide
again.
Is it possible to have the package block or fail if the currently installed
version has the berkdb flag? This way, the user would have to export his db,
unmerge the old package, and then merge the new one?
fixed in place (it will fail with USE="berkdb" set.
about to commit.
