I suspect you are being bitten by a problem with the multi-realm support in 1.4.11. The src/util directory is not being compiled with the correct environment variable set so the cross-realm support is failing. The quick fix is to remove the
#if defined(AFS_ATHENA_STDENV) || defined(AFS_KERBREALM_ENV) #endif pair in src/util/get_krbrlm.c fs_is_foreign_ticket_name() Jeffrey Altman Eric Chris Garrison wrote: > Hello, > > We're doing a cutover from MIT Kerberos to ADS, and while it works most > everywhere else, one of our supercomputers' nodes is giving us problems. > > AFS works fine with MIT Kerberos. > > AFS "hangs" with ADS. That is, it'll try to reach the /afs/iu.edu > directory for 10-15 minutes, then time out, saying: > > ls: /afs/iu.edu: No such file or directory > > Interestingly, if I do a "bos status -noauth" from the client it works > fine. If I do it with a proper (ADS) token, it hangs and times out with > the following error: > > bos: failed to contact host's bosserver (communications failure (-1)). > > Watching a tcpdump of the session from the server's point of view, it > appears that the client never responds to rx requests: > > bos: rx data bos call enumerate-instance 0 (36) > 15:51:54.485660 IP RFSHOST.afs3-bos > CLIENT.53057: rx challenge (44) > 15:51:54.586685 IP RFSHOST.afs3-bos > CLIENT.53057: rx ack first 1 serial > 0 reason delay acked 16777216 (66) > 15:51:56.486625 IP RFSHOST.afs3-bos > CLIENT.53057: rx challenge (44) > 15:51:58.487591 IP RFSHOST.afs3-bos > CLIENT.53057: rx ack first 1 serial > 0 reason ping acked 16777216 (66) > 15:51:58.487610 IP RFSHOST.afs3-bos > CLIENT.53057: rx challenge (44) > 15:51:58.488850 IP CLIENT.53057 > RFSHOST.afs3-bos: rx ack first 1 serial > 4 reason ping response (65) > ...and so on. > > Again, this works fine with the MIT Kerberos realm, so it does not seem to > be a firewall or router filter type issue, and we're able to get Kerberos > tickets and tokens just fine with either realm. It just has > communications issues when we have tokens gotten with ADS. > > Any ideas what would cause this behavior? I had them update to a recent > (1.4.11) openafs client, just in case our current dual realm status was > the problem, but that does not seem to make a difference. > > Thanks, > > Chris
smime.p7s
Description: S/MIME Cryptographic Signature
