RE: ApacheDS for ASF
Emmanuel Lecharny wrote: Graham Leggett wrote: This brings a discussion as to where the authoritative source of data lies. Right now today that authoritative source is svn, and I also imagine people would want this to stay that way for some time. As a result, our first task would be to synchronise LDAP with the various members.txt (etc) files. This would need a bit of shell scripting, probably tied into the svn server so the synchronise is triggered on commit. This is where the Use-Case descriptions are needed : they will exhibit the data we will manipulate, plus the workflow we have to follow. This brings a potential ASF schema into the picture. objectclass: asfMember objectclass: asfCommitter This has to be discussed, but we first have to analyze what data we really need to handle. And there are a lot of them, in different files and different formats ! No kidding! I'd really like to see a project objectclass, too. Especially for some of the things that we have in the Incubator. The redundant meta-data is really hurting. I want one canonical definition of a project, including reporting dates, PMC members, Committers, etc. --- Noel
Re: ApacheDS for ASF
On Tue, Apr 15, 2008 at 11:38 AM, Noel J. Bergman [EMAIL PROTECTED] wrote: Emmanuel Lecharny wrote: Graham Leggett wrote: This brings a discussion as to where the authoritative source of data lies. Right now today that authoritative source is svn, and I also imagine people would want this to stay that way for some time. As a result, our first task would be to synchronise LDAP with the various members.txt (etc) files. This would need a bit of shell scripting, probably tied into the svn server so the synchronise is triggered on commit. This is where the Use-Case descriptions are needed : they will exhibit the data we will manipulate, plus the workflow we have to follow. This brings a potential ASF schema into the picture. objectclass: asfMember objectclass: asfCommitter This has to be discussed, but we first have to analyze what data we really need to handle. And there are a lot of them, in different files and different formats ! No kidding! I'd really like to see a project objectclass, too. Especially for some of the things that we have in the Incubator. The redundant meta-data is really hurting. I want one canonical definition of a project, including reporting dates, PMC members, Committers, etc. Right and we can leverage DOAP files for most of this information I think. Importing it into an Apache Project schema will be trivial. Alex
Re: ApacheDS for ASF
+ Need a schema and script to import DOAP files into DS. On Fri, Apr 11, 2008 at 7:25 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Just a quick heads up for Graham, mainly : we have had a BoF last thursday where we discussed about using ADS to manage the ASF. To make a long story short, we agreed on a few things : - we have to install ADS on the zone Graham created - we must first try to manage our own users (ADS users) - we have to define complete and validated uses-cases for what we want to do - to avoid f*cking up access to the ASF servers for our users, we must be sure that we keep the current text file updated - we might start with access to Confluence, as it's not a critical component - some sites like Jim's page ( http://people.apache.org/~jim/committers.htmlhttp://people.apache.org/%7Ejim/committers.html) or http://people.apache.org/committers.html might also be seen as perfect target for initial experimentations Graham Leggett wrote: Emmanuel Lecharny wrote: I suggest we discuss that during AMS, and have a chat session then. Alex is just totally dead (he finished the release last night), and will be flying tomorrow morning. I emphathise, was flying over Easter and was wiped out afterwards... I may also create a place on the directory wiki where we can discuss the project. That may be an idea. Part of the driver for getting a proper LDAP server going is that I have just landed some more user friendly login module options with httpd, meaning that it is easier to create a per user website (backed by LDAP) for the ASF. PS : I saw that you were moving from Africa to London ? A new job there ? Been in London for the last year or so, finally got round to updating my details :) Regards, Graham -- -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: ApacheDS for ASF
Emmanuel Lecharny wrote: Just a quick heads up for Graham, mainly : we have had a BoF last thursday where we discussed about using ADS to manage the ASF. To make a long story short, we agreed on a few things : - we have to install ADS on the zone Graham created - we must first try to manage our own users (ADS users) - we have to define complete and validated uses-cases for what we want to do - to avoid f*cking up access to the ASF servers for our users, we must be sure that we keep the current text file updated - we might start with access to Confluence, as it's not a critical component - some sites like Jim's page (http://people.apache.org/~jim/committers.html) or http://people.apache.org/committers.html might also be seen as perfect target for initial experimentations One recurring theme that has come up on the infra lists when this has been discussed in the past is a concern that an insufficiently secure LDAP server could leak private data out to the wider world. As a result, before we stick any real data into the server, we need to secure it to the point where the server is production ready. What this means depends on the capabilities of ADS server: SSL? I would say this would be a minimum requirement, we could probably use our own cert for now as this is for our consumption, rather than consumption of the wider world, but this may change. Access via client certificates only? One option is to keep the server truly private initially (ie on localhost), accessible initially via ssh port forwarding. This way we can prevent any surprised people on the infra list, and ensure privacy concerns are addressed before opening up the server to a wider world. Once this is done, the next job (I would imagine) would be to automatically populate / synchronise the data based on the contents of members.txt, etc, as you've described above. This brings a discussion as to where the authoritative source of data lies. Right now today that authoritative source is svn, and I also imagine people would want this to stay that way for some time. As a result, our first task would be to synchronise LDAP with the various members.txt (etc) files. This would need a bit of shell scripting, probably tied into the svn server so the synchronise is triggered on commit. The LDAP server doesn't have to be limited to just member and/or committer data, it could (and probably should) contain login details for virtually anybody. The members.txt file could supplement existing data in LDAP with extra details about that person. This brings a potential ASF schema into the picture. objectclass: asfMember objectclass: asfCommitter ... How would these schemas be defined, and how would they change over time? Something I have been working on in httpd-land for a while is the problem of effective single sign-on with applications. Bugzilla for example might want you to log in with your email address, while something like Moveable Type might want you to log in with your username. Rather than expecting people to log in twice, httpd is capable of allowing a user to log in with their email address, but provide (say) their username to the backend instead without either the user or the backend application being aware of it. This is obviously a thought for down the line, but it does give an idea of what is possible. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: ApacheDS for ASF
Hi Graham, On Sat, Apr 12, 2008 at 12:47 PM, Graham Leggett [EMAIL PROTECTED] wrote: Emmanuel Lecharny wrote: snip/ One recurring theme that has come up on the infra lists when this has been discussed in the past is a concern that an insufficiently secure LDAP server could leak private data out to the wider world. This has been mentionned during the BoF. As a result, before we stick any real data into the server, we need to secure it to the point where the server is production ready. What this means depends on the capabilities of ADS server: SSL? I would say this would be a minimum requirement, we could probably use our own cert for now as this is for our consumption, rather than consumption of the wider world, but this may change. SSL is absolutly a must, if we are to access to the LDAP server directly. However, I would be more restrictive : I would not allow access to the server but to someone already logged via SSH on, say, people.apache.org. The main issue is DOS attacks... So one solution would be to define an intermediat elayer (for instance, a web site, or web-services), becaue they can be protected much more efficiently than ADS itself. Access via client certificates only? Well, this is something we should consider. One option is to keep the server truly private initially (ie on localhost), accessible initially via ssh port forwarding. This way we can prevent any surprised people on the infra list, and ensure privacy concerns are addressed before opening up the server to a wider world. Damn,I should read forward before answering :) Anyways, that is good to see that we are really on the same page here ! Once this is done, the next job (I would imagine) would be to automatically populate / synchronise the data based on the contents of members.txt, etc, as you've described above. Yep This brings a discussion as to where the authoritative source of data lies. Right now today that authoritative source is svn, and I also imagine people would want this to stay that way for some time. As a result, our first task would be to synchronise LDAP with the various members.txt (etc) files. This would need a bit of shell scripting, probably tied into the svn server so the synchronise is triggered on commit. This is where the Use-Case descriptions are needed : they will exhibit the data we will manipulate, plus the workflow we have to follow. The LDAP server doesn't have to be limited to just member and/or committer data, it could (and probably should) contain login details for virtually anybody. The members.txt file could supplement existing data in LDAP with extra details about that person. Yes. We also mentionned JIRA's and Confluence's users, who may not be committers. This brings a potential ASF schema into the picture. objectclass: asfMember objectclass: asfCommitter ... How would these schemas be defined, and how would they change over time? This has to be discussed, but we first have to analyze what data we really need to handle. And there are a lot of them, in different files and different formats ! Something I have been working on in httpd-land for a while is the problem of effective single sign-on with applications. yeah... Again, has been mentionned during the BoF (I'm starting to think that my abstract was a little bit too abstracted ...) Bugzilla for example might want you to log in with your email address, while something like Moveable Type might want you to log in with your username. We may use some internal mechanism to handle this case. To be further analyzed. Rather than expecting people to log in twice, httpd is capable of allowing a user to log in with their email address, but provide (say) their username to the backend instead without either the user or the backend application being aware of it. This is obviously a thought for down the line, but it does give an idea of what is possible. Yes. And some more can exist that we are not aware of. We have to start small, and grow like a snowball, I think. Thanks Graham ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: ApacheDS for ASF
Just a quick heads up for Graham, mainly : we have had a BoF last thursday where we discussed about using ADS to manage the ASF. To make a long story short, we agreed on a few things : - we have to install ADS on the zone Graham created - we must first try to manage our own users (ADS users) - we have to define complete and validated uses-cases for what we want to do - to avoid f*cking up access to the ASF servers for our users, we must be sure that we keep the current text file updated - we might start with access to Confluence, as it's not a critical component - some sites like Jim's page (http://people.apache.org/~jim/committers.html) or http://people.apache.org/committers.html might also be seen as perfect target for initial experimentations Graham Leggett wrote: Emmanuel Lecharny wrote: I suggest we discuss that during AMS, and have a chat session then. Alex is just totally dead (he finished the release last night), and will be flying tomorrow morning. I emphathise, was flying over Easter and was wiped out afterwards... I may also create a place on the directory wiki where we can discuss the project. That may be an idea. Part of the driver for getting a proper LDAP server going is that I have just landed some more user friendly login module options with httpd, meaning that it is easier to create a per user website (backed by LDAP) for the ASF. PS : I saw that you were moving from Africa to London ? A new job there ? Been in London for the last year or so, finally got round to updating my details :) Regards, Graham -- -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: ApacheDS for ASF
Emmanuel Lecharny wrote: This is interesting ! We just discussed yesturday with Alex about having a BoF related to using ADS for Apache. May be we can submit this BoF and have this convo there ? At the moment I won't be in AMS next week, but I can be on IRC. What we have right now is a zone that is ready to go, all we need is some people willing to set the server up, and getting the right access to the people who need it. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: ApacheDS for ASF
Graham Leggett wrote: Emmanuel Lecharny wrote: This is interesting ! We just discussed yesturday with Alex about having a BoF related to using ADS for Apache. May be we can submit this BoF and have this convo there ? At the moment I won't be in AMS next week, but I can be on IRC. What we have right now is a zone that is ready to go, all we need is some people willing to set the server up, and getting the right access to the people who need it. This can be done easily. I suggest we discuss that during AMS, and have a chat session then. Alex is just totally dead (he finished the release last night), and will be flying tomorrow morning. I may also create a place on the directory wiki where we can discuss the project. Thanks Graham ! PS : I saw that you were moving from Africa to London ? A new job there ? Regards, Graham -- -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: ApacheDS for ASF
Graham Leggett wrote: Hi all, Hi Graham, In time for Apachecon, I'd like to give another stab at getting a version of ApacheDS running on the ldap.zones.apache.org zone. The idea would be that this would become a testbed that would eventually graduate off the zone and onto its own machine, but baby steps... The problem I have had to date is that I have a zone, but not the experience to get the server up and running and properly configured on that zone, and time has always been an issue. Is there anyone on the ADS list that is willing to set up an ApacheDS server on the ldap.zones.apache.org zone, securely configure it, and make it ready for populating it with data? This is interesting ! We just discussed yesturday with Alex about having a BoF related to using ADS for Apache. May be we can submit this BoF and have this convo there ? Once it is there, the work can start with populating the directory with something useful, but none of that can happen till the server works :) yes, that's true :) FYI, we will all arrive around sunday (Alex) and monday (Pierre-Arnaud, me), I don't exactly know for the other peeps (Stefan Zörner, Stefan Seelmann and Christine Koppelt). See you there ! Put the beers on ice ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: ApacheDS for ASF
Emmanuel Lecharny wrote: I suggest we discuss that during AMS, and have a chat session then. Alex is just totally dead (he finished the release last night), and will be flying tomorrow morning. I emphathise, was flying over Easter and was wiped out afterwards... I may also create a place on the directory wiki where we can discuss the project. That may be an idea. Part of the driver for getting a proper LDAP server going is that I have just landed some more user friendly login module options with httpd, meaning that it is easier to create a per user website (backed by LDAP) for the ASF. PS : I saw that you were moving from Africa to London ? A new job there ? Been in London for the last year or so, finally got round to updating my details :) Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: ApacheDS for ASF
Count me in. Alex On Fri, Apr 4, 2008 at 11:47 AM, Graham Leggett [EMAIL PROTECTED] wrote: Hi all, In time for Apachecon, I'd like to give another stab at getting a version of ApacheDS running on the ldap.zones.apache.org zone. The idea would be that this would become a testbed that would eventually graduate off the zone and onto its own machine, but baby steps... The problem I have had to date is that I have a zone, but not the experience to get the server up and running and properly configured on that zone, and time has always been an issue. Is there anyone on the ADS list that is willing to set up an ApacheDS server on the ldap.zones.apache.org zone, securely configure it, and make it ready for populating it with data? Once it is there, the work can start with populating the directory with something useful, but none of that can happen till the server works :) Regards, Graham --
