Re: [OpenAFS] Kernel module on sparc64
On Wednesday 06 December 2006 23:49, Jeffrey Hutzelman wrote: On Wednesday, November 15, 2006 09:44:56 AM +0100 Gunnar Krull [EMAIL PROTECTED] wrote: # modprobe libafs Found system call table at 0x4164b8 (exported) Found 32-bit system call table at 0x416000 (exported) (Shouldn't it be a 64-bit system call table ?) There are two tables - one for native programs, and one for 32-bit programs. We found both. * With OpenAFS 1.5.10 and 1.5.11 # modprobe libafs Warning: Unable to find the address of authtab NFS Translator hooks will not be installed To correct, specify authtab_addr=authtab That's normal; unless you patch your kernel to export this symbol or provide its address on the command line, the NFS translator will not be supported. Unlike the system call table, this is not something we can scan for. # rmmod libafs BUG: warning at fs/proc/generic.c:732/remove_proc_entry() Call Trace: [00406bd4] linux_sparc_syscall32+0x3c/0x40 [00010f2c] 0x10f34 That's the whole trace? That's pretty useless. But no, this is not the cause of your problem. Yes, that's the whole trace. Nothing more the kernel want's to say. The same result now with version 1.5.12. 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 ... The 1.5.11 version improves the amd64 system call table range checking. Is this also the case for sparc64 systems? IIRC, the issue in question only affected amd64 systems. -- Jeff Thanks a lot for your answers! Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Kernel module on sparc64
Gunnar Krull [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. ) /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. :-) -Marcus Watts ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Kernel module on sparc64
On Thursday 07 December 2006 10:03, Marcus Watts wrote: Gunnar Krull [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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! Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Kernel module on sparc64
On Thu, 7 Dec 2006, Gunnar Krull wrote: # rmmod libafs BUG: warning at fs/proc/generic.c:732/remove_proc_entry() Call Trace: [00406bd4] linux_sparc_syscall32+0x3c/0x40 [00010f2c] 0x10f34 I'd guess we try unmapping a proc entry we didn't install, but, not your problem. 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 ... That's good, but, until we know about it, we're not going to fix it, so you can hope that every one is it, and it won't be. Between the fix Marcus found for AIX, and the one I found for s390x Linux, I bet one is related. I will look in an hour or so. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Kernel module on sparc64
On Wednesday, November 15, 2006 09:44:56 AM +0100 Gunnar Krull [EMAIL PROTECTED] wrote: # modprobe libafs Found system call table at 0x4164b8 (exported) Found 32-bit system call table at 0x416000 (exported) (Shouldn't it be a 64-bit system call table ?) There are two tables - one for native programs, and one for 32-bit programs. We found both. * With OpenAFS 1.5.10 and 1.5.11 # modprobe libafs Warning: Unable to find the address of authtab NFS Translator hooks will not be installed To correct, specify authtab_addr=authtab That's normal; unless you patch your kernel to export this symbol or provide its address on the command line, the NFS translator will not be supported. Unlike the system call table, this is not something we can scan for. # rmmod libafs BUG: warning at fs/proc/generic.c:732/remove_proc_entry() Call Trace: [00406bd4] linux_sparc_syscall32+0x3c/0x40 [00010f2c] 0x10f34 That's the whole trace? That's pretty useless. But no, this is not the cause of your problem. 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 1.5.11 version improves the amd64 system call table range checking. Is this also the case for sparc64 systems? IIRC, the issue in question only affected amd64 systems. -- Jeff ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Kernel module on sparc64
Hi all, I have a problem with the OpenAFS kernel modules build on a dual-sparc64 with Debian Etch running, again. The modules for the different afs versions are compiled on a 2.6.18 Debian kernel (linux-image-2.6.18-2-sparc64-smp) and configured with: ./configure --with-afs-sysname=sparc64_linux26 I can compile the modules successfully, after dealing with the afs license problem I had before. The afs filespace also is accessible. This is the kernel output when I insert/remove the module: * With OpenAFS 1.4.2 # modprobe libafs Found system call table at 0x4164b8 (exported) Found 32-bit system call table at 0x416000 (exported) (Shouldn't it be a 64-bit system call table ?) * With OpenAFS 1.5.10 and 1.5.11 # modprobe libafs Warning: Unable to find the address of authtab NFS Translator hooks will not be installed To correct, specify authtab_addr=authtab # rmmod libafs BUG: warning at fs/proc/generic.c:732/remove_proc_entry() Call Trace: [00406bd4] linux_sparc_syscall32+0x3c/0x40 [00010f2c] 0x10f34 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) There is a module parameter to set the authtab_addr but I don't know what to enter here. Can I set it manually or should it be done? The 1.5.11 version improves the amd64 system call table range checking. Is this also the case for sparc64 systems? Regards, Gunnar ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
