On Fri, 20 Nov 2009 13:30:59 +0100 Holger Rauch <holger.ra...@empic.de> wrote:
> > 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. Yes, but the question is still "why?". Is this because you want one place to backup? Or because you want to be able to change all user/group information with only LDAP-aware tools? Some other reason? > > 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. Well, if you allow supergroups in your ptservers, you're going to need to account for this, or something is going to break. > > There are more pt rpcs you have to support if you want to provide > > read-only 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? I believe Marcus was saying this assuming you were implementing a new ptserver implementation that uses LDAP as its backend storage. You obviously do not need to implement any of them if you have _both_ the 'normal' ptservers running and also have some LDAP server running that allows you to query ptserver data. > > 2/ ptserver front-end, ldap backend. > > almost certainly useful to cache > > Any more precise hints for this? "It's a lot of work". What I believe Marcus is hinting at is basically rewriting a large portion of the ptserver backend. This isn't something you want to do unless you want to invest a lot of time or money in it. > > 3/ ptserver "as is", ldap front-end into prdb. > > Openldap provides some dandy frameworks for this. > > Haven't yet come accross them. Any links. We're not OpenLDAP developers :) (At least, I'm not). I don't have information on the plugin APIs, but I would imagine something like this would not be a difficult plugin to create. > > 4/ use "pag" in kerberos ticket. Like DCE and MS. > > What's "pag"? Haven't heard about this one as of yet. I think Marcus is referring to the MS (and DCE, apparently?) practice of storing a bunch of authorization data in the kerberos ticket when you acquire your ticket, instead of getting that information from a separate server (in this case, ptserver). This route would require modifications to the KDC, or some way of using Microsoft's PAC data or something along those lines. -- Andrew Deason adea...@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info