afs pts schema?

[Marcus Watts]

Leif Johansson <leifj@it.su.se>
> 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