On Sat, 2 May 2009, Axel Thimm wrote: > 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 > > > made. > > > > > > > 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 from > > one group to another. > > Where is the information "*-vanilla" vs "*-sponsors" vs "*-admins" > 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 group. So > > 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 > > case. > > Why? Custom schemes are quite often found in LDAP world, and it is > really just two attributes you are adding to typical PosixAccounts. > I'm not sure "why" you'd have to ask the fedora-ds and openldap devs. We dropped ldap largly on their recommendation, the comment that did it for me was "what you're trying to do with ldap is not a very ldap way of doing things." Thus why I described what we were trying to do as "hacky" -Mike _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
