I may be abandoning this because there doesn't seem to be any reliable
way for clients to figure out that the cell is its own realm (without
requiring end-users to manually edit or replace their krb5.conf, which
is way beyond the abilities of many people, sad as that fact may be).

Basically, unless I can get this to a truly zero-configuration
situation for users, my project is not gonna fly.  It's just the
realities of how things are.

  - a


ted creedon <[EMAIL PROTECTED]> writes:
> I'd appreciate some documentation when its done.
>
> Thanks.
>
> tedc
>
> Adam Megacz wrote:
>>Ken Hornstein <[EMAIL PROTECTED]> writes:
>>
>>>When I tracked this one down, I found code to specifically disallow
>>>foreign realm users in the code that handles the Bos UserList; it
>>>would not surprise me to find similar code in the pts server.
>>>
>>
>>Is there opposition to removing this code?
>>
>>I'm starting to like the idea of running AFS in its own micro-realm
>>and having all users be cross-realm users.  It cuts down a lot on
>>administrative overhead (asking for favors from kdc admins when stuff
>>changes) and keeps the username namespace nice and tidy without
>>unduely favoring one institution or department over another.
>>
>>  - a
>>
>>

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to