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 attachment 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.
