Okay, it's ugly, but the -524 test should be good enough. My main concern here is users at well-established AFS sites (say, CMU/MIT/Stanford) who access my cell. The way it's set up, things work great with the latest aklog, zero configuration needed. I've found that prior aklogs fail (sometimes nondeterministically) because I rely so heavily on AFSDB, Kerberos SRV, and cross-realm authentication. These all work quite well in the 1.4.1 aklog, though.
If a collaborator at one of these other AFS sites has troubles aklogging, I need a quick way for them to determine if their aklog version is the problem. I guess that for now I can explain to them that looking for this strange flag is the only way to figure out what version they're using. - a Ken Hornstein <[EMAIL PROTECTED]> writes: >>It's distinguishing the aklog that "shipped with OpenAFS" from the >>serveral versions with varying abilities that "are often >>deployed/bundled with OpenAFS" that is at issue here. > > I don't view that as a problem that OpenAFS needs to solve; that problem > lies squarely in the laps of the people who create those binary bundles. > I think if you have an issue regarding those bundles, you need to talk > to the people who create them. > > That being said ... > > - You should be able to get a rough idea of the capabilities of aklog with > "ident". Also, looking at the usage statement for the -524 flag ought to > be helpful. > - I have been told that future releases will include the aklog that ships > with OpenAFS, so eventually this will be a non-issue. > > --Ken -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
