So a year ago we talked back and forth about what to do for FAS2. We've spent a LOT of time on getting an easy front end to an LDAP back end. It was a reasonably heated debate whether or not to use LDAP or postgres for the back end. I was heavily in favor of LDAP for 3rd party support.
Well, over time its become clear that LDAP is just not very good at doing groups as we want it to do. We need to have people self-add themselves to groups, track when they were added, who added them. People can have different access levels in the group (unapproved, user, sponsor, admin). LDAP is very geared towards what most people need (someone in charge of a group and adding people to that group). In an open environment like ours, we need the whole application process. Its not that LDAP is bad, just not the right tool for the job.
At the same time, during this last year, we've seen a huge push towards OpenID adaptation which is something we've always wanted on the front end. Our turbogears apps have proved to work very well and creating an api to work with FAS2 is very easy. In light of these things, the big benefit of having ldap on the back end (3rd party apps) seems less grand and less of a win.
We've been working on FAS2 for almost a year now, and with the deadline looming the FAS2 dev's (me and ricky) talked about the best way to move forward. We've decided to stick with an rdms. Fortunately it shouldn't be too difficult for us.
We had been basing our application on fedora-ds, during the last year we've seen great changes in this application and how its packaged. This has made it less stable/desirable as a back end. All signs point to using postgres on the back end as being both the easier choice and the more reliable choice based on what we've seen.
I don't like to make decisions like this in a vacuum but time is tight and I really want to make this deadline.
Thoughts? Comments? Concerns?
-Mike
On Wed, 2008-02-13 at 13:32 -0600, Mike McGrath wrote:
So a year ago we talked back and forth about what to do for FAS2. We've spent a LOT of time on getting an easy front end to an LDAP back end. It was a reasonably heated debate whether or not to use LDAP or postgres for the back end. I was heavily in favor of LDAP for 3rd party support.
At the same time, during this last year, we've seen a huge push towards OpenID adaptation which is something we've always wanted on the front end. Our turbogears apps have proved to work very well and creating an api to work with FAS2 is very easy. In light of these things, the big benefit of having ldap on the back end (3rd party apps) seems less grand and less of a win.
We've been working on FAS2 for almost a year now, and with the deadline looming the FAS2 dev's (me and ricky) talked about the best way to move forward. We've decided to stick with an rdms. Fortunately it shouldn't be too difficult for us.
We had been basing our application on fedora-ds, during the last year we've seen great changes in this application and how its packaged. This has made it less stable/desirable as a back end. All signs point to using postgres on the back end as being both the easier choice and the more reliable choice based on what we've seen.
I don't like to make decisions like this in a vacuum but time is tight and I really want to make this deadline.
Thoughts? Comments? Concerns?
If ldap doesn't fly, it doesn't fly.
my only question is how do you plan on doing the nss-integration for id lookups? Continue using nss_db?
thanks
On Feb 13, 2008 1:07 PM, seth vidal skvidal@fedoraproject.org wrote:
On Wed, 2008-02-13 at 13:32 -0600, Mike McGrath wrote:
So a year ago we talked back and forth about what to do for FAS2. We've spent a LOT of time on getting an easy front end to an LDAP back end. It was a reasonably heated debate whether or not to use LDAP or postgres for the back end. I was heavily in favor of LDAP for 3rd party support.
At the same time, during this last year, we've seen a huge push towards OpenID adaptation which is something we've always wanted on the front end. Our turbogears apps have proved to work very well and creating an api to work with FAS2 is very easy. In light of these things, the big benefit of having ldap on the back end (3rd party apps) seems less grand and less of a win.
We've been working on FAS2 for almost a year now, and with the deadline looming the FAS2 dev's (me and ricky) talked about the best way to move forward. We've decided to stick with an rdms. Fortunately it shouldn't be too difficult for us.
We had been basing our application on fedora-ds, during the last year we've seen great changes in this application and how its packaged. This has made it less stable/desirable as a back end. All signs point to using postgres on the back end as being both the easier choice and the more reliable choice based on what we've seen.
I don't like to make decisions like this in a vacuum but time is tight and I really want to make this deadline.
Thoughts? Comments? Concerns?
If ldap doesn't fly, it doesn't fly.
my only question is how do you plan on doing the nss-integration for id lookups? Continue using nss_db?
thanks
Speaking for myself.. in most large 'projects' with goals like this we ended up with a database backend that was the feed to the LDAP and other 'authentication/authorization' servers. The web-app was the feed into the database, and the LDAP/Radius/Kerberos/whatever was the frontends.
On Wed, 13 Feb 2008, Stephen John Smoogen wrote:
On Feb 13, 2008 1:07 PM, seth vidal skvidal@fedoraproject.org wrote:
Speaking for myself.. in most large 'projects' with goals like this we ended up with a database backend that was the feed to the LDAP and other 'authentication/authorization' servers. The web-app was the feed into the database, and the LDAP/Radius/Kerberos/whatever was the frontends.
In our talkings with #ldap and #fedora-ds people I ran into a couple of people doing something similar. I hate to admit this publically but in a former life I did a lot of stuff with FreeRadius. had custom plugins and even a MSSQL backend for it (yikes). There are options available here though we'll probably stick with a version similar to what we're doing now but a bit saner, no race conditions and hopefully pulling right from the webapp instead of generating then pulling.
-Mike
On Wed, 13 Feb 2008, Anand Capur wrote:
hopefully pulling right from the webapp instead of generating then pulling.
-Mike*No idea what i'm talking about here* but is there a way to cache the main things to reduce the load of querying a DB every time?
The cache is actually the problem with the race condition now. In order to do a manual push we have to run scripts on our app servers to 'generate' the cache. then we have to pull it. I'm sure there's a better way to do it even without the cache for now. We're only talking about 60-70 hosts right now. That will grow with time. But with plenty of time to wait until caching is really needed.
-Mike
On Feb 13, 2008, at 11:32 AM, Mike McGrath wrote:
Well, over time its become clear that LDAP is just not very good at doing groups as we want it to do. We need to have people self-add themselves to groups, track when they were added, who added them. People can have different access levels in the group (unapproved, user, sponsor, admin). LDAP is very geared towards what most people need (someone in charge of a group and adding people to that group). In an open environment like ours, we need the whole application process. Its not that LDAP is bad, just not the right tool for the job.
...
Thoughts? Comments? Concerns?
Will using Postgres as the back-end and LDAP as a middle piece work with FAS2? Perhaps using LDAP to integrate with NSS and other 3rd party apps, but just for authentication/authorization (read access).
Right now I'm using LDAP as my primary data store for our Library systems at OSU, but I'm considering moving to a tiered LDAP+SQL system, so if there are reasons why it doesn't work well I'd be especially happy to hear about them. :-)
Ryan
-- Ryan Ordway E-mail: rordway@oregonstate.edu Unix Systems Administrator rordway@library.oregonstate.edu OSU Libraries, Corvallis, OR 97331 Office: Valley Library #4657
On Thu, 14 Feb 2008, Ryan Ordway wrote:
...
Thoughts? Comments? Concerns?
Will using Postgres as the back-end and LDAP as a middle piece work with FAS2? Perhaps using LDAP to integrate with NSS and other 3rd party apps, but just for authentication/authorization (read access).
Right now I'm using LDAP as my primary data store for our Library systems at OSU, but I'm considering moving to a tiered LDAP+SQL system, so if there are reasons why it doesn't work well I'd be especially happy to hear about them. :-)
Thats certainly a possibility though I'd rather wait and see what won't work with this system. As it is right now everything will work except the wiki (which wouldn't have worked out of the box anyway AFAIK) and since we're pushing to move towards mediawiki (see today's meeting) I think even that won't be a problem.
-Mike
I thought this was an interesting article/concept. http://www.vanemery.com/Opinion/OpenDAS.html
With the move to mediawiki, would we want to try and integrate a FAS2 authentication system? I know that mediawiki supports LDAP authentication with some extension. -Anand
On Sat, 16 Feb 2008, Anand Capur wrote:
With the move to mediawiki, would we want to try and integrate a FAS2 authentication system? I know that mediawiki supports LDAP authentication with some extension.
Yeah, I think that will be a requisite, no local accounts.
-Mike
infrastructure@lists.fedoraproject.org
-
Anand Capur -
Mike McGrath -
Ryan Ordway -
Seth Vidal -
Stephen John Smoogen