> Translation: Derrick will piss and moan about it for a few years, but
> eventually stop ... or you will learn to ignore it, I can't really
> tell the difference anymore :-)
>
> I am not particularly in love with the idea of exec'ing translate_et just
> to translate errors for asetkey ... the people who run that SHOULD be able
> to just run translate_et for themselves (although somehow that doesn't
> seem to be the case). If we can provide a useful error we should try
> (or at least issue a message saying "run translate_et to determine the
> error"). That would argue toward linking against the Kerberos com_err
> library, though.
>
> --Ken
It's certainly possible to make an asetkey that does all the
right stuff:
bruson:/home/mdw/src/openafs/src/aklog# dd </dev/urandom count=1 bs=30
> /tmp/not.kt
1+0 records in
1+0 records out
30 bytes (30 B) copied, 6.2e-05 seconds, 484 kB/s
bruson:/home/mdw/src/openafs/src/aklog# ./asetkey add 2 /tmp/not.kt foo
./asetkey: Unsupported key table format version number while extracting
AFS service key
bruson:/home/mdw/src/openafs/src/aklog# ./asetkey delete 25
./asetkey: could not find entry so failed to delete key 25
bruson:/home/mdw/src/openafs/src/aklog# file asetkey
asetkey: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for
GNU/Linux 2.6.0, dynamically linked (uses shared libs), not stripped
bruson:/home/mdw/src/openafs/src/aklog#
This is on an amd64 linux machine with debian linux (64-bit userland);
first error comes from MIT kerberos 5 and 2nd error comes from AFS.
Are there people here who really think numeric error codes
are better?
-Marcus Watts
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
