On 25 Mar 2010, at 15:36, John W. Sopko Jr. wrote: > Does anyone have a clue why the "tokens" command sometimes shows the > (AFS ID xxxx) and sometimes it does not as shown below? The > problem is intermittent. > > The systems are rhel5, openafs 1.4.11, using redhats pam_krb5afs. > This occurs when ssh'ing to machines. If you just do an > "aklog" after logging in you always get the (AFS ID xxx) format.
The ID isn't actually used (it's actually a horrible, horrible hack between various different abstraction layers which variously represent it as a string, and as a numeric ID) - so you don't need to worry about the fact that it isn't there. The only thing you'll really lose is some information in debugging messages. When prsent, the number should be the user's pts ID, and is supplied by userspace when it sets tokens. Judging from the copy of RedHat's pam_krb5 (2.2.2) that I found in a random Google code search, they use the local Unix uid of the user obtaining the token to populate this field. If you are obtaining tokens as root, then I suspect this ends up being 0, and so you'll appear to have no pts ID. This behaviour appears on first glance to be broken. "Correct" behaviour requires calling out to the ptserver from the PAM module. Unless you take the approach of Russ's PAM module, and use system() to invoke aklog(), then this means that your PAM module has to pull in a vast set of dependencies, from the ptclient suite, to rx, to the "interesting" threading libraries used by OpenAFS's database clients. It's unlikely that such a PAM module would function reliably, so if you want to do token acquiry without forking another process, you can't populate the ID number. As noted earlier this shouldn't cause you any real problems. Cheers, Simon. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
