Leif Johansson <[EMAIL PROTECTED]>
> Has anyone thought to drop pts into ldap? The semantics of pts groups =
>
> should not be that different from groupOfUniqueNames so the schema =
>
> additions should be relatively minor(?) One implementation scenario is to=
> =
>
> drop the pts client altoghether and just keep the pts server as a =
>
> protocol translator into ldap (authenticating to the directory server =
>
> as afs@REALM over GSSAPI perhaps) and do all user and group admin in =
>
> the directory server. I guess DCE must have a schema that kinda does
> this but that may not be appropriate for afs.... Comments?
[ I deleted the other groups, since I'm not sure I can post to them... ]
In no particular order, here are some of the issues that might
arise:
efficient replication (not sure how this works in openldap)
Openldap tracks groups in groups by DN, so changing names
is *real* painful.
pt works with:
keberos (k4) user names.
group names (looks like either k4 names, or
k4.name:k4.name)
vice IDs.
You'd need to map all of these into
appropriate attributes. Entries without
viceIDs would lose. [ Fileservers store viceIDs
in acls. ]
You'd have to provide a pt RPC (rx) interface, including
especially getcps and friends. That's what
all the cache managers currently deployed expect,
so if you want to play, you have to provide it too.
Not sure how openldap performs under load. Performance
could be an issue.
-Marcus Watts
UM ITCS Umich Systems Group
