[OpenAFS] Re: LDAP backend for PTS?

[Holger Rauch]

--Pd0ReVV5GZGQvF3a
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Marcus,

thanks a lot for your reply?

On Tue, 17 Nov 2009, Marcus Watts wrote:

> [...]=20
> prdb is NOT berkeley db.

Ok, I was wrong with this one. Sorry.

>=20
> Why do you care how many berkeley DB's you have?

Because I want to store all user/group/authentication related data in
a centralized way via OpenLDAP, so that only one Berkeley DB is
maintained.

> [...]
> Are you planning to store vldb in ldap as well?

Well, what I'm looking for is a backend storing all information
manipulated/queried via the pts set of commands in an OpenLDAP schema.

> [...]=20
> username is easy (uid.  or not.  cn?)
> user viceid is easy (uidNumber.)
> groupname is easy (cn, probably)
> group viceid.  Um.  uidNumber?  Do your groups have numbers?

Yes, the groups do have numbers since I'm using the ldapscripts
package from Debian Lenny to populate my OpenLDAP DIT with Unix group
info and I choose the same UIDs/GIDs also for OpenAFS users/group when
creating them via pts commands.

> Then there's the intersection data.

What's that exactly?

> members of groups?

That's possible for "regular" POSIX accounts, so why shouldn't it be
possible with OpenAFS pts info? Or am I missing something here?

> Also you might want to support "groups within groups".

While it certainly might be useful for some case, it looks like a
rather special case to me.

> You should have an option to support kerberos 5 names.

There's an OpenLDAP backend for MIT Kerberos that can be used via the
kdb5_ldap_util command so that's not necessarily a problem.
Furthermore, e.g. the kadmin uses OpenLDAP provided that krb5.conf
includes the relevant DB info.

> You don't want to know about gssapi names.

Why would they be needed?

>=20
> For openafs/prdb, the important rpc you *have* to support
> is GetCPS.  name goes in - list of all user and group viceids come out.
> Note that an afs client may contact several servers in
> rapid succession - caching results may be useful.

Ok, that's an important point I surely missed.

>=20
> Unless you organize your ldap store to optimize this query, you
> won't be doing this as one ldap call.  If you do optimize this
> query, your ldap associates may question your sanity.

This one too.

>=20
> There are more pt rpcs you have to support if you want to provide read-on=
ly
> query access (pts examine, members, etc.) - and even more if you want
> to provide group read/write support as well.

The interesting question is: Why do I have to support the pt rpcs if
all I want to do is storing and querying pt data in an LDAP schema?

> If you don't
> support group maintenance via pts, then you should provide this via ldap.

It is provided for POSIX accounts.

>=20
> For ldap in general, and openldap in particular, you have 2 more
> interesting issues:
> 	transactions
> 	referential integrity

Thanks a lot for pointing this out.

> [...]=20
> Some approaches
>=20
> 1/ sync ldap into ptserver (Andrew describes a low-tech way;
> 	higher tech approaches are also possible.)

Do you have some link for me where this is described in more detail?

>=20
> 2/ ptserver front-end, ldap backend.
> 	almost certainly useful to cache

Any more precise hints for this?

>=20
> 3/ ptserver "as is", ldap front-end into prdb.
> 	Openldap provides some dandy frameworks for this.

Haven't yet come accross them. Any links.

>=20
> 4/ use "pag" in kerberos ticket.  Like DCE and MS.

What's "pag"? Haven't heard about this one as of yet.

Thanks for any info & kind regards,

       Holger
      =20
--Pd0ReVV5GZGQvF3a
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksGjAMACgkQbiVtWpZdKQIluACbB/4p8OetWKkRWngG6N6q0Ojn
2aEAnApYs9FRW3vR1dln31lTnvvk3X8t
=FcDO
-----END PGP SIGNATURE-----

--Pd0ReVV5GZGQvF3a--