test5.fedora.phx.redhat.com has an instance of FDS running on it with the current schemas and sample data that I've been working with. For a primer on the schema, please see http://fedoraproject.org/wiki/Infrastructure/AccountSystem2/Schema .Pretty screenshot attached.
I need to figure out the group situation still and hope to solidify the schema so that development against it may commence. I have already tested and verified apache authentication against it using mod_authnz_ldap.
As always, if there's anything I can improve, let me know.
~lyz
On Thursday 04 January 2007 22:03, TomLy wrote:
test5.fedora.phx.redhat.com has an instance of FDS running on it with the current schemas and sample data that I've been working with.
These are the completely OSS parts of FDS right?
On 1/4/07, Jesse Keating jkeating@redhat.com wrote:
On Thursday 04 January 2007 22:03, TomLy wrote:
test5.fedora.phx.redhat.com has an instance of FDS running on it with the current schemas and sample data that I've been working with.
These are the completely OSS parts of FDS right?
I thought the whole thing was OSSed and worked with gcj now? If not its not a huge deal we'll just use a different management frontend.
-Mike
On Thu, 2007-01-04 at 21:03 -0600, TomLy wrote:
test5.fedora.phx.redhat.com has an instance of FDS running on it with the current schemas and sample data that I've been working with. For a primer on the schema, please see http://fedoraproject.org/wiki/Infrastructure/AccountSystem2/Schema .Pretty screenshot attached.
I need to figure out the group situation still and hope to solidify the schema so that development against it may commence. I have already tested and verified apache authentication against it using mod_authnz_ldap.
Do you have some ideas on how we should proceed with development? There are a few separate threads to this:
1) New development is being done in TurboGears. TurboGears has an identity structure that even has an LDAP plugin. We need to test that against our servers. TurboGears also needs to save state (so that you don't have to reauth on every page load), so we'll have to provide a supplemental database to save the session information.
2) Old applications are built using the fedora-accounts python modules. From my brief usage of it, I believe the main API is in the website.py file. We need to compile a list of what applications are using this and port them to the new infrastructure. It may be easiest to port website.py to the new infrastructure so the applications don't have to worry about the changes or it may be better to port the applications to the new LDAP + session interface. It depends on how many apps exist and what they are currently using in website.py.
3) Porting/pointing third party applications that we use to LDAP. This includes MoinMoin, Plone, and OTRS. Since this is the reason we're moving to an LDAP backend, this should be relatively straightforward.
4) OpenID. I think the idea is we host an OpenID server and then new pieces of infrastructure can use either ldap or OpenID to authenticate. The hope is that other places will use Fedora's OpenID service to authenticate our users to their services. I believe that nothing currently has an openID plugin that doesn't have an ldap plugin so this can be put off for a bit.
-Toshio
We need to compile a list of what applications are using this and port them to the new infrastructure.
I'd like to get this moving more sooner than later. Can we get a wiki page going for this? Something that lists the application or function that authenticates and the type of authentication it uses (whether through website.py or apache mods etc.) . I would do this myself, but am not the best person for it.
~tom
On Fri, 2007-01-05 at 20:14 -0600, TomLy wrote:
We need to compile a list of what applications are using this and port them to the new infrastructure.
I'd like to get this moving more sooner than later. Can we get a wiki page going for this? Something that lists the application or function that authenticates and the type of authentication it uses (whether through website.py or apache mods etc.) . I would do this myself, but am not the best person for it.
Started a page here: http://www.fedoraproject.org/wiki/Infrastructure/AccountSystem2/LegacyApps
I've made three sections:
Apps using the Python API * voting * Old Account System interface * Syncing the accounts to the infrastructure servers -- export-*.{py,sh}
Apps using the DB Directly
Apps using an apache module * OTRS
Please fill the lists in with any applications that you can think of.
-Toshio
Do you have some ideas on how we should proceed with development?
Here's the stages that I see at this time:
1. LDAP structure gets stabilized. Of course, there may be slight tweaks to this during the following stages.
2. The syncing mechinism is set up to sync the production DB to LDAP (nightly?)
3. The easy apps are ported to authenticate against LDAP (moin moin, apps that use apache auth).
4. Website.py ported and apps moved to LDAP
5. Turbo gears authentication framework devised and TG apps ported
6. Account system web administration rewritten in TG to work with LDAP
7. Old system retired
8. OpenID
Please add/edit this I will make a wiki page out of it when it's accepted.
~tom
On Fri, 2007-01-05 at 20:45 -0600, TomLy wrote:
Website.py ported and apps moved to LDAP
Turbo gears authentication framework devised and TG apps ported
As long as we're going to port website.py to LDAP we might want to build the TG framework against the website.py interface. Then we could port to a direct LDAP+session db connection at leisure.
-Toshio
On Jan 4, 2007, at 10:03 PM, TomLy wrote:
test5.fedora.phx.redhat.com has an instance of FDS running on it with the current schemas and sample data that I've been working with. For a primer on the schema, please see http://fedoraproject.org/wiki/Infrastructure/AccountSystem2/ Schema .Pretty screenshot attached.
I need to figure out the group situation still and hope to solidify the schema so that development against it may commence. I have already tested and verified apache authentication against it using mod_authnz_ldap.
Just noticed that the project_group.prerequisite_id field is not carried over to the new schema, and the page didn't sound like there was a general understanding of why the field is there.
It's there to allow you to specify that anyone who joins a group must be in another group first. Most of the time it is used to enforce CLA compliance for a particular group, by setting cla_done as a prerequisite for any groups that give access that needs the CLA (e.g. all the cvs* groups).
AFAIK, enforcing CLA compliance is a must for the future, and if we're going to implement a solution for that, it might as well be generic (instead of just a 'needs_cla' field in the DB, for example).
Best, -- Elliot
On 1/7/07, Elliot Lee sopwith@gmail.com wrote:
On Jan 4, 2007, at 10:03 PM, TomLy wrote: Just noticed that the project_group.prerequisite_id field is not carried over to the new schema, and the page didn't sound like there was a general understanding of why the field is there.
It's there to allow you to specify that anyone who joins a group must be in another group first. Most of the time it is used to enforce CLA compliance for a particular group, by setting cla_done as a prerequisite for any groups that give access that needs the CLA (e.g. all the cvs* groups).
AFAIK, enforcing CLA compliance is a must for the future, and if we're going to implement a solution for that, it might as well be generic (instead of just a 'needs_cla' field in the DB, for example).
This is true, it would be nice to enforce this at the LDAP level somewhere. Lyz do you know of any way to do this? We may want to talk to the FDS people.
-Mike
AFAIK, enforcing CLA compliance is a must for the future, and if we're going to implement a solution for that, it might as well be generic (instead of just a 'needs_cla' field in the DB, for example).
This is true, it would be nice to enforce this at the LDAP level somewhere. Lyz do you know of any way to do this? We may want to talk to the FDS people.
-Mike
I'll ask the FDS person we were working with if this is doable. This wasn't truly implemented in the db schema as it appears there could only be one prerequisite. This was set to the cla_done group in almost every case (except sysadmin).
In this case, adding attributes to the person's shema isn't the solution (as I was thinking previously). This is because it would require a software layer to check the attribute. One of my thoughts on the new account system is to have LDAP handle as much as possible to avoid having to wright a software layer to wrap it.
~lyz
On 1/7/07, TomLy lyz27@yahoo.com wrote:
I'll ask the FDS person we were working with if this is doable. This wasn't truly implemented in the db schema as it appears there could only be one prerequisite. This was set to the cla_done group in almost every case (except sysadmin).
In this case, adding attributes to the person's shema isn't the solution (as I was thinking previously). This is because it would require a software layer to check the attribute. One of my thoughts on the new account system is to have LDAP handle as much as possible to avoid having to wright a software layer to wrap it.
So what will be the best way to say "in order to be in this group, you must also be in this group and have a signed CLA"?
-Mike
On Jan 7, 2007, at 3:59 PM, TomLy wrote:
I'll ask the FDS person we were working with if this is doable. This wasn't truly implemented in the db schema as it appears there could only be one prerequisite. This was set to the cla_done group in almost every case (except sysadmin).
In this case, adding attributes to the person's shema isn't the solution (as I was thinking previously). This is because it would require a software layer to check the attribute. One of my thoughts on the new account system is to have LDAP handle as much as possible to avoid having to wright a software layer to wrap it.
Well, realistically speaking, it is a little bit of a pain to implement checking this constraint even in SQL, and I imagine LDAP just can't do it. I don't see a huge need to be worried about implementing the constraint in a software layer, because only the part of the system that adds people to groups will need to worry about it. It is not as if this is something that absolutely every directory client will need to do, just something that will need to go into the administration codebase.
(This is assuming, of course that you choose to implement it the same way it is implemented in the old account system. I can think of other ways that /would/ require each and every client to pay attention to it unless there was LDAP support...)
Best, -- Elliot
infrastructure@lists.fedoraproject.org
-
Elliot Lee -
Jesse Keating -
Mike McGrath -
TomLy -
Toshio Kuratomi