1:32 p.m.
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
2:07 p.m.
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
--
I only speak for me.
3 p.m.
On Feb 13, 2008 1:07 PM, seth vidal <skvidal(a)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.
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
3:17 p.m.
On Wed, 13 Feb 2008, Stephen John Smoogen wrote:
On Feb 13, 2008 1:07 PM, seth vidal <skvidal(a)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
3:41 p.m.
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
5:18 p.m.
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(a)oregonstate.edu
Unix Systems Administrator rordway(a)library.oregonstate.edu
OSU Libraries, Corvallis, OR 97331 Office: Valley Library #4657
6:17 p.m.
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
6:24 p.m.
I thought this was an interesting article/concept.
http://www.vanemery.com/Opinion/OpenDAS.html
11 p.m.
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
5914
days inactive
5917
days old
infrastructure@lists.fedoraproject.org
10 comments
5 participants
participants (5)
-
Anand Capur -
Mike McGrath -
Ryan Ordway -
Seth Vidal -
Stephen John Smoogen