Juha Jäykkä wrote:
It and its friends can be found at ftp://achilles.ctd.anl.gov/pub/DEE
pam_afs2-0.1.tar
gafstoken-0.3.tar
gssklog-0.11.tar
This is the beast I was referring to. I'm sorry I was too lazy to check
who created it and properly credit you.
The design goals of all of this was to keep AFS as far away from
Kerberos as possible, and never have to rely on a vendor's daemon to
have to link (even dynamically via pam) with either and especially with
both.
I agree that this is the cleanest way to go. And it is in good old unix
philosophy that one thing does one thing - "ls" does not remove files and
"rm" does not list them. =)
I never tried it, though, except for debugging other pam modules (I used
it to all a little shell script). The reason was that it did not appear
have any signs of activity since a year ago and I shun inactive upstreams.
Obviously, I was wrong. Perhaps you just made such a damn good module that
it needs no further development? =) Testing pam_afs2 and friends is now
back on my todo list...
Perhaps someone would like to start maintaining a Debian package of these
three? I'd do that myself but I lack the status of a DD (that could be
corrected, though).
I would like to see the OpenAFS people pick this up and distribute the pam_afs2
or its equivalent with OpenAFS, as it is only used by AFS. The discussions
on the list lately are headed this way.
The gssapi used in gssklog does not even have to be Kerberos! It was
originally designed for use with the Globus GSI gssapi. (But that is
It might be a very important story for us, since we participate in two
grid projects (NorduGrid: http://www.nordugrid.dk and M-grid:
http://www.csc.fi/proj/mgrid/) which both use Globus.
I used to be on the Globus project, but not any more. The gatekeeker
was setup to be able to fork/exec the gssklog. There is a gatekeeper
patch in with it too. You could run the gssklog for the GLobus uses
while still using Keerberos for your normal users.
gssklog. ( There is no MIT or Heimdal Kerberos on these machines, other
then what the AFS kernel has built in.)
This sounds like the way to go: separate OpenAFS and Kerberos
*implementations* as well as possible. The fact that AFS uses Kerberos
internally means this is a little more complicated an issue than just not
linking with kerberos, but still you're obviously going the right way.
Cheers,
Juha
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
