On Fri, May 01, 2009 at 08:57:22AM -0500, Mike McGrath wrote:
On Fri, 1 May 2009, Axel Thimm wrote:
> On Fri, May 01, 2009 at 02:54:08AM -0400, Ricky Zhou wrote:
> > On 2009-05-01 09:11:11 AM, Axel Thimm wrote:
> > > Maybe if someone gives some detail on why the LDAP setup looked like
> > > too hacky we could find a better solution and use LDAP?
> > We were basically trying to use LDAP like a relational DB instead of a
> > directory, so we were trying to force our entire sponsorship system to
> > be totally contained in LDAP. Looking back at this, the best approach
> > with LDAP would probably have been a DB for sponsorship data, and LDAP
> > for holding approved user/group data. As I mentioned, I'd be interested
> > in exploring this approach a bit more in the future.
> With details I mean something more like what exact bits where not
> mapping naturally into some LDAP structure, existent or custom schema
Both ldap groups basically suggested to us to have 3 groups for each
'group'. SO if you have a sysadmin group we'd have 'sysadmin'
'sysadmin-sponsors' and 'sysadmin-admins'. Then we'd move people
one group to another.
Where is the information "*-vanilla" vs "*-sponsors" vs
needed? If nothing else outside of FAS needs it, then I'd simply add a
custom attribute. If you would need to export this information to say
filesystem ACLs to allow different access to sysadmin-sponsors and
sysadmin-admins, then you would have to split into these subgroups
anyway somewhere in the FAS -> filesystem ACLs process.
Then there was the concept of marking who sponsored who in that
if Axel joined the sysadmin group and I sponsored him in that group, that
I be able to track that information.
That really sounds like a simple custom attribute, possibly not even
needed anywhere else outside of FAS scope.
Those two requirements together make ldap a poor solution in our use
Why? Custom schemes are quite often found in LDAP world, and it is
really just two attributes you are adding to typical PosixAccounts.
Axel.Thimm at ATrpms.net