Hi I'm not going to be any help but I've noticed that it also fails in slackware 10.1 same place and error (when doing the make checks). Interestingly other MIT kerberos implementations fail at the same place in slackware 10.1 (10.2 as well no doubt) - I've tried 1.4, 1.3.3 and 1.3 and they compile but fail during the checks. I'm guessing there must be something about the compiler/tools/library in slackware 10.x that doesn't like MIT Kerberos - unless someone from another distro has noticed it does not work for them either :-)
If you look in that /root/krb5-1.4.2/src/util/db2/test directory you'll find the test program ./dbtest and the files it uses as data for the test: t1,t2 and t3. The t1 file is based on the first 200 entries of the word list from the dictionary (/usr/share/dictionary/words). The t2 file is a command file that is used to generate test database file - it has commands to add data and keys (based on the dictionary words) and retrieve a particular keyed piece of data (there are other commands as well but they are not particularly used). The t3 file is the result of running the ./dbtest command and if it works should be the same as the original (./t1) wordlist data file. The dbtest command appears to only fail when running hash tests (the btree tests appear to work). From what I can find out - I've only experimented for a few hours is: 1) The first command set from the ./t2 (to store a key/data pair and then retrieve it) always fails with a "get failed, no such key" error, no matter what the data/key pair actually are. 2) I have not figured out if the hash function does not like lines over 8 characters long i.e. it truncates them to 8 so confuses longer words with the same first 8 characters.....or if the hash function does not like any word that shares the same root e.g. "abandon" and "abandonment". Suspiciously there is a dictionary file in the src/util/db2/test directory (which the script will use if it can find no other) that seems to be all 8 character long words! 3) It does not appear to fail consistently - in my examples (below) I'm only using a few words but in the full 200 words there are plenty of instances where it has longs words (that share the same first 8 characters) but the dbtest routine does not complain about them all. BTW, my slackware 10.1 is running a 2.6.11 kernel with gcc-3.3.4. Here's some examples: If my t2 file contains the following lines: -------------------------------> snip <------------------------------------------------- p kaback daback g kaback p kabaft dabaft g kabaft p kabandon dabandon g kabandon p kabandoned dabandoned g kabandoned ------------------------------------------> snip <--------------------------------------------------- The command "./dbtest hash t2" fails with the following errors: 5: aback: get failed, no such key abaft 15: abandon: get failed, no such key abandoned If I add some extra lines to the start of the ./t2 file to simply store (not retrieve) some data. For example add the lines: ------------------------------------------> snip <--------------------------------------------------- p kzzzzzz dzzzzzz ------------------------------------------> snip <--------------------------------------------------- (but it could be any key/data information) Then the command fails with: aback abaft 18: abandon: get failed, no such key abandoned If I delete the lines for "abandon" then I get no failures from the command. However, if I add an entry for "abafts" to change the file to: ------------------------------------------> snip <--------------------------------------------------- p kzzzzzz dzzzzzz p kaback daback g kaback p kabaft dabaft g kabaft p kabafts dabafts g kabafts p kabandon dabandon g kabandon p kabandoned dabandoned g kabandoned ------------------------------------------> snip <--------------------------------------------------- The command failure becomes: aback abaft 18: abafts: get failed, no such key abandon abandoned For some reason it has now stopped complaining about not being able to find a key for "abandon" If I move the entry for "abafts" to the end of the file the failure suddenly returns to moaning about "abandon" and stops complain about abafts: aback abaft 18: abandon: get failed, no such key abandoned abafts If I move "abandon" to the end of the file now so it becomes: ------------------------------------------> snip <--------------------------------------------------- p kzzzzzz dzzzzzz p kaback daback g kaback p kabaft dabaft g kabaft p kabandoned dabandoned g kabandoned p kabafts dabafts g kabafts p kabandon dabandon g kabandon ------------------------------------------> snip <--------------------------------------------------- It will return to moaning about abafts: aback abaft abandoned 23: abafts: get failed, no such key abandon Somehow ordering is important in the command file. I'm sure there will be someone who understands hashing algorithms and how this little test program works and will simply say "HAH! Fool does he not see the problem - it is *so* obvious?!?" but I don't know what's up with it. I cannot decide if the problems are because the test routines are simply faulty and therefore the actual install of MIT Kerberos is actually sound or if there is some sort of fundamental problem with the Kerberos install. Either way I notice that Heimdal 0.7.1 compiles on Slackware 10.1 (and probably 10.2) and runs all it's self checks without hitch - big question is if everything else in the universe will compile against Heimdal. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
