[OpenAFS] Kernel module on sparc64
Thu, 7 Dec 2006 11:04:41 +0100
On Thursday 07 December 2006 10:03, Marcus Watts wrote:
> Gunnar Krull <firstname.lastname@example.org> and others wrote:
> > > > I think that's the reason why my token gets discarded when trying to
> > > > access a protected folder of our afs filespace:
> > > > afs: Tokens for user of AFS id 1032 for cell ****** are discarded
> > > > (rxkad error=19270410)
> > >
> > > 19270410 is RXKADSEALEDINCON, which effectively means that either you
> > > or the fileserver is not encrypting data correctly. Usually it means
> > > that one of you is using the wrong key, but in this case, there is a
> > > known problem on some 64-bit platforms, which should be fixed in the
> > > next release.
> > The encryption and keys on the server side are correct. I've checked this
> > to be sure that the problem is the client. Sparc64 in combination with
> > Linux/Debian is the only effected architecture here.
> > So, I'm waiting impatiently for the fixed release ...
> This sounds like it might be the same problem that Steve Roseman
> <sgr0@Lehigh.EDU> ran into on powerpc. In his case, his cache manager
> was using wrong-endian encryption right at the point of setting up an
> encrypted rx connection with a fileserver, so wasn't in fact capable of
> doing authenticated file access. The definitive proof would be to use
> tcpdump & knowledge of the keys used to prove this is what happening,
> but you probably won't need to do that.
> I would be *very* interested in knowing two things:
> /1/ do pts and other userland commands work while using authenticated
> access with a token immediately before you access afs filespace and lose
> that token?
> ( since your error report contains your vice id, this
> seems likely to be true. )
Yes, that works.
I can e.g. create and remove user groups with pts. Creating/removing volumes
per vos command also works.
Interestingly: after my token got discarded I can still execute commands that
need authentication (pts, vos, ...) !?
> /2/ does this build fix produces a working cache manager for you?
> > The "simple" kludge is to just append the line "#define WORDS_BIGENDIAN
> > 1" at the end of src/config/afsconfig.h after configuring afs, then at
> > the top do ( cd src/libafs; make clean )
> > -- if you have old kernel objects in your build tree
> > make only_libafs
> > -- build just the cache manager
> > You can then copy the cache manager pieces to your already existing
> > system. Of course you can also build the whole thing.
> > Just remember that if you type configure or config.status you'll
> > have to patch afsconfig.h again.
> If these are both true, then that's good, that means I may actually
> have an interesting patch that will help you as well as others shortly.
> Also, you'll have a working cache manager, and won't need to be quite
> so impatient. :-)
Yes, that's it!
Now I can open files and directories in "authentication only" area of our afs
filespace and the token resides in my system. I will test it more in the next
days but it should be ok now.
Thanks for the hint!