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
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
W/o having in-depth knowledge of FAS I'd start with a typical account
LDAP setup and add the extra FAS functionality with a custom schema.
The group mapping should be done via conventional LDAP Posix
Account/Group schemas, and I guess most of the extra bits could be
converted to group memberships. That way, not only will you be able to
map special FAS bits to simple POSIX semantics and thus reduce any
special FAS schemes, but also use FAS information in anything that
reads nss. E.g. you could use group memberships in filesystem acls to
allow provenpackager some access to some files, sponsors other access
to other files etc.
Axel.Thimm at ATrpms.net