143605 2006-08-11 14:00 0000 mit-krb5-1.4.3-r3 does not warn that you may be unable to read your kerberos database 2007-04-03 20:45:59 0000 1 1 1 Unclassified Gentoo Linux Ebuilds unspecified All Linux RESOLVED FIXED P2 critical --- 1 olivier@calle.org kerberos@gentoo.org doug-gb@elemental.ath.cx sascha-gentoo-bugzilla@silbe.org olivier@calle.org 2006-08-11 14:00:36 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. seemant@gentoo.org 2006-08-11 15:27:12 0000 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. exg@gentoo.org 2006-08-15 14:34:02 0000 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. olivier@calle.org 2006-08-23 12:31:57 0000 Created an attachment (id=94960) 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. exg@gentoo.org 2006-08-31 15:30:58 0000 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. menion@asylumwear.com 2006-11-06 18:18:48 0000 Yeah, this sadly, is a bitch of a bug that just hit me. =( menion@asylumwear.com 2006-11-07 05:31:45 0000 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. doug-gb@elemental.ath.cx 2006-11-30 14:01:43 0000 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? seemant@gentoo.org 2007-04-03 20:45:59 0000 fixed in place (it will fail with USE="berkdb" set. about to commit. 94960 2006-08-23 12:31 0000 Steps I used to migrate my Kerberos database mit-krb5-upgrade-notes.txt text/plain U3RlcHMgSSB1c2VkOgowLiAgQmFja3VwIGV2ZXJ5dGhpbmcKCS9ldGMva3JiNS5jb25mCgkvZXRj L2tyYjVrZGMKCUFueXRoaW5nIGVsc2UuLi4KMS4gIFN0b3AgS0RDIGFuZCBhbnkgcmVsYXRlZCBz ZXJ2ZXJzCgkvZXRjL2luaXQuZC9taXQta3JiNWtkYyBzdG9wCjIuICBNYWtlIHN1cmUgS0RDIGFu ZCByZWxhdGVkIChsaWtlIGthZG1pbmQpIHN0b3BwZWQKMy4gIER1bXAgS2VyYmVyb3MgZGF0YWJh c2UgdG8gdGV4dAoJa2RiNV91dGlsIGR1bXAga3JiLWJhY2t1cC50eHQKNC4gIFVwZ3JhZGUgdG8g bmV3IHZlcnNpb24KCWVtZXJnZSAtLW9uZXNob3QgLWF2IG1pdC1rcmI1CjUuICBVcGRhdGUgL2V0 Yy9rcmI1LmNvbmYgYnkgcmVtb3Zpbmcga2RjLmNvbmYgZGVmaW5pdGlvbgogICAgTmV3IGRlZmF1 bHQgbG9jYXRpb24gaXMgL3Zhci9saWIva3JiNWtkYy9rZGMuY29uZgo2LiAgTW92ZSAvZXRjL2ty YjVrZGMgdG8gL3Zhci9saWIKCW12IC9ldGMva3JiNWtkYyAvdmFyL2xpYgo3LiAgRWRpdCAvdmFy L2xpYi9rcmI1a2RjL2tkYy5jb25mIHRvIGNoYW5nZSAvZXRjL2tyYjVrZGMgcGF0aHMKICAgIHRv IC92YXIvbGliL2tyYjVrZGMKOC4gIERlbGV0ZSBvbGQga2VyYmVyb3MgZGF0YWJhc2UgKGluIG15 IGNhc2UgY2FsbGVkICJwcmluY2lwYWwiKQoJcm0gL3Zhci9saWIva3JiNWtkYy9wcmluY2lwYWwq CjkuICBCdWlsZCBhIG5ldyBlbXB0eSBkYXRhYmFzZSAoZ2l2ZSB0aGUgY29tbWFuZCB0aGUgc2Ft ZSBkYXRhYmFzZSBwYXNzd29yZAogICAgeW91IHByZXZpb3VzbHkgdXNlZCkKCWtkYjVfdXRpbCBj cmVhdGUgLXMKMTAuIExvYWQgZGF0YWJhc2UgdGV4dCBmaWxlIGludG8gbmV3IGRhdGFiYXNlCglr ZGI1X3V0aWwgbG9hZCBrcmItYmFja3VwLnR4dAoxMS4gU3RhcnQgS2VyYmVyb3MKCS9ldGMvaW5p dC5kL21pdC1rcmI1a2RjIHN0YXJ0CgkvZXRjL2luaXQuZC9taXQta3JiNWthZG1pbmQgc3RhcnQK MTIuIFRlc3QKCWtpbml0IGR1ZGVAS0VSQkVST1MuUkVBTE0KCWtsaXN0IC1mYW4K