Jeffrey Altman wrote:
The problem with the mapping service is that the use of it is completely arbitrary based upon how the cell administrators decide to configure their cell. This makes it virtually impossible to write and distribute a "standard afs client" with tools that can work for every cell transparently.
As a client application developer, I want there to be a standard way to obtain the AFS token which is going to work everywhere. I do not want
to be dependent on the fact that cell A requires gssklog, and cell B
requires kaserver, and cell C requires Kerberos 5, and cell D requires
Kerberos 5 mapped using foobard, and cell E requires ....
But the need for gssklog came from AFS cells that had kaserver but not krb5 and wanted to use the Globus GSI, and where not willing to setup a krb5 cell. So I don't think you as the developer can force AFS to only work with one. You can internally with the token, but AFS may want to keep its options open to support multiple methods of obtaining a token.
AFS needs to work with what ever authentication method is available. It might be the default is no mapping service i.e. use k5 tickets directly with a single or multiple realms, or one that supports only K5 via gssapi, or other gssapi mechenisums.
Even if AFS does not provide a maping service, it can still be done as this is what the gssklog did.
Also note the multiple akog, afslogin, PAM routines and code built into daemons today to get tokens. How would you simplify this?
End users should not be aware of such issues.
I agree with that.
Jeffrey Altman
--
Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
