You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by Paul Querna <pq...@apache.org> on 2008/12/06 02:20:58 UTC
CLAs and LDAP
In the ldap schema, we likely need some way to mark someone as having a
CLA or not.
We have a couple ASF members, who have never contributed code before, so
while they would be in the ASF members group, they have not signed a CLA
-- and therefore should _not_ have access to the public svn code areas.
Maybe having a CLA is just another group?
Re: CLAs and LDAP
Posted by sebb <se...@gmail.com>.
On 06/12/2008, Paul Querna <pq...@apache.org> wrote:
> Emmanuel Lécharny wrote:
>
> > sebb wrote:
> >
> > > On 06/12/2008, Emmanuel Lécharny <el...@apache.org> wrote:
> > >
> > >
> > > > Paul Querna wrote:
> > > >
> > > >
> > > >
> > > > > In the ldap schema, we likely need some way to mark someone as
> having a
> > > > >
> > > > >
> > > > CLA or not.
> > > > If the person has a CLA, then the attribute will be present with
> the CLA as
> > > > a pdf. Otherwise, the attribute will be empty.
> > > >
> > > >
> > >
> > > By the way:
> > >
> > > Not all CLAs are PDFs.
> > > There are also GIF, JPG, PNG, TIF, RTF and even at least one TXT file
> ...
> > >
> > >
> > This is something we will have to take care of.
> >
> > One way to do that is to encapsulate the file and its content into a java
> object, and store this java object into the server (it will be serialized).
> Not all the LDAP server support java serialization/deserialization ...
> >
> > Another option would be to use attribute options :
> >
> > asf-cla;pdf for pdf file
> > or
> > asf-cla;tif for TIF file,
> >
> > etc... (Not all the LDAP server support attributes options.)
> >
>
> meh, I wouldn't bother storing the CLA in LDAP -- we already have them in
> SVN, no reason to duplicate the contents in LDAP.
>
Actually, we don't have all the CLAs in SVN at present - there are
quite a few entries in iclas.txt which don't have a corresponding file
in SVN. It's also sometimes useful to be able to find the CLA file
from the person's details.
> -Paul
>
>
Re: CLAs and LDAP
Posted by Paul Querna <pq...@apache.org>.
Emmanuel Lécharny wrote:
> sebb wrote:
>> On 06/12/2008, Emmanuel Lécharny <el...@apache.org> wrote:
>>
>>> Paul Querna wrote:
>>>
>>>
>>>> In the ldap schema, we likely need some way to mark someone as having a
>>>>
>>> CLA or not.
>>> If the person has a CLA, then the attribute will be present with
>>> the CLA as
>>> a pdf. Otherwise, the attribute will be empty.
>>>
>>
>> By the way:
>>
>> Not all CLAs are PDFs.
>> There are also GIF, JPG, PNG, TIF, RTF and even at least one TXT file ...
>>
> This is something we will have to take care of.
>
> One way to do that is to encapsulate the file and its content into a
> java object, and store this java object into the server (it will be
> serialized). Not all the LDAP server support java
> serialization/deserialization ...
>
> Another option would be to use attribute options :
>
> asf-cla;pdf for pdf file
> or
> asf-cla;tif for TIF file,
>
> etc... (Not all the LDAP server support attributes options.)
meh, I wouldn't bother storing the CLA in LDAP -- we already have them
in SVN, no reason to duplicate the contents in LDAP.
-Paul
Re: CLAs and LDAP
Posted by Emmanuel Lécharny <el...@apache.org>.
sebb wrote:
> On 06/12/2008, Emmanuel Lécharny <el...@apache.org> wrote:
>
>> Paul Querna wrote:
>>
>>
>>> In the ldap schema, we likely need some way to mark someone as having a
>>>
>> CLA or not.
>>
>> If the person has a CLA, then the attribute will be present with the CLA as
>> a pdf. Otherwise, the attribute will be empty.
>>
>
> By the way:
>
> Not all CLAs are PDFs.
> There are also GIF, JPG, PNG, TIF, RTF and even at least one TXT file ...
>
This is something we will have to take care of.
One way to do that is to encapsulate the file and its content into a
java object, and store this java object into the server (it will be
serialized). Not all the LDAP server support java
serialization/deserialization ...
Another option would be to use attribute options :
asf-cla;pdf for pdf file
or
asf-cla;tif for TIF file,
etc... (Not all the LDAP server support attributes options.)
> Also, some CLAs are currently stored as multiple files, one file per page.
>
Same problem, same solution.
> Furthermore, sometimes there is more than one distinct CLA for the
> same person - perhaps because of change of address or e-mail.
>
Attributes can be multivalued, so it's not a problem in this case.
However, I think we should update the spec document with the given
constraints.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: CLAs and LDAP
Posted by sebb <se...@gmail.com>.
On 06/12/2008, Emmanuel Lécharny <el...@apache.org> wrote:
> Paul Querna wrote:
>
> > In the ldap schema, we likely need some way to mark someone as having a
> CLA or not.
> >
> If the person has a CLA, then the attribute will be present with the CLA as
> a pdf. Otherwise, the attribute will be empty.
By the way:
Not all CLAs are PDFs.
There are also GIF, JPG, PNG, TIF, RTF and even at least one TXT file ...
Also, some CLAs are currently stored as multiple files, one file per page.
Furthermore, sometimes there is more than one distinct CLA for the
same person - perhaps because of change of address or e-mail.
> But it might be easier to add a boolean attribute hasCLA, in order to
> facilitate the filtering of person without a CLA.
>
Sounds good.
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: CLAs and LDAP
Posted by Emmanuel Lécharny <el...@apache.org>.
Paul Querna wrote:
> In the ldap schema, we likely need some way to mark someone as having
> a CLA or not.
If the person has a CLA, then the attribute will be present with the CLA
as a pdf. Otherwise, the attribute will be empty.
But it might be easier to add a boolean attribute hasCLA, in order to
facilitate the filtering of person without a CLA.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: CLAs and LDAP
Posted by Emmanuel Lécharny <el...@apache.org>.
Henning Schmiedehausen wrote:
> On Sun, 2008-12-07 at 21:30 +0100, Emmanuel Lécharny wrote:
>
> <snip/>
>>> The first one restricts you to having a "CLA attribute". Which means,
>>> when we need a new thing, you need to add another attribute and another
>>> and another.
>>>
>>>
>> Only if we didn't listed the attributes we need before starting to
>> define the schema. Generally speaking, it might be better to keep the
>> number of ObjectClass low, because it's a burden from the administration
>> POV to manage many abstract ObjectClasses (you always have to remember
>> to add this and that objectClass to get a correct entry).
>>
>
> Huh? Only if you plan to manage this whole thing by hand.
Certainly not ! I'm too lazzy ;)
> I use ApacheDS
> Studio all the time and honestly, it is a nice, but very basic schema
> browser, nothing more. If user creation is to be automated, it will have
> to create new user objects anyway, which means that the object class
> assignment has to be correct in there and that is all places that you
> need.
>
If user creation is to be automated, the best would be to have a
dedicated UI. Especially if we have to define more than one ObjectClass,
otherwise, it will be a PITA...
btw, what do you mean by 'user objects' ?
> If you insist on adding users with ldapadd, phpldapadmin or similar
> toys, then yes, you are in a world of pain. But you don't do that in a
> serious context anyway, do you?
>
cf a previous comment : I'm too lazzy ;)
>
>
>> Remember that the data structure will change orders of magnitude less
>> than the data themselves (if we do a correct analysis first, of course ;)
>>
>
> LOL. The data structure will changes in ways that are unimaginable to
> anyone of us yet all the time. Otherwise we would add them now. So what
> we need to do is to organize the data in a way that it is flexible and
> extensible. That is why I would use multiple object classes and not
> extend existing ones. Along that road lies IME tremendous pain.
>
Whatever you do, the main issue is _not_ adding some new AttributeType
to an ObjectClass, but to modify the thousands of entries if you add a
new mandatory AttributeType. The flexibility is not an issue, the data
managment is. It's perfectly sane and easy to add a newt AT in a big
ASFPerson OC, so I don't see any reason not to do so and to define
dozens of Abstract OC. Not to say that decoupling some part of the
schema does not make sense, but I want to stress the fact that it's not
a common practice in LDAP. Just have a look at M$ ObjectClasses :)
>
>>> What you *want* is a custom object class representing the CLA, e.g.
>>> "CLAPerson". This contains all required attributes (e.g. "CLA on file"
>>> as a boolean and "scannedCLA" as a binary attribute) and if a person is
>>> eligible to a CLA, you just add it to its object classes. Make claOnFile
>>> mandatory and scannedCLA optional and you are good to go.
>>>
>>>
>> This is an option. The main issue, IMO, is how to handle CLAs stored in
>> many files, and CLA type (pdf, tif, ...).
>>
>
> What is the relevance? Make it a multivalue bianry field and add a mime
> type.
You can't associate a content and a Mime type in a attribute without
having to add some structure to your attribute, which will make it
impossible to manage by a simple ldap browser. In other words, even if
you use options, managing both the mime type, the multi-file CLA and the
content in one single attribute is by no mean simple.
for instance, if you have a PDF CLA in two parts, you may have something
like :
AsfCLA;pdf;part-1: <blah>
AsfCLA;pdf;part-2: <blah 2>
Now, from the browser perspective, this is quite complicated to manage.
Assuming that the LDAP server handle options correctly ...
> </snip>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: CLAs and LDAP
Posted by Henning Schmiedehausen <he...@schmiedehausen.org>.
On Sun, 2008-12-07 at 21:30 +0100, Emmanuel Lécharny wrote:
> Henning Schmiedehausen wrote:
> > On Sat, 2008-12-06 at 15:09 +0200, Graham Leggett wrote:
> >
[...]
> > The first one restricts you to having a "CLA attribute". Which means,
> > when we need a new thing, you need to add another attribute and another
> > and another.
> >
> Only if we didn't listed the attributes we need before starting to
> define the schema. Generally speaking, it might be better to keep the
> number of ObjectClass low, because it's a burden from the administration
> POV to manage many abstract ObjectClasses (you always have to remember
> to add this and that objectClass to get a correct entry).
Huh? Only if you plan to manage this whole thing by hand. I use ApacheDS
Studio all the time and honestly, it is a nice, but very basic schema
browser, nothing more. If user creation is to be automated, it will have
to create new user objects anyway, which means that the object class
assignment has to be correct in there and that is all places that you
need.
If you insist on adding users with ldapadd, phpldapadmin or similar
toys, then yes, you are in a world of pain. But you don't do that in a
serious context anyway, do you?
> Remember that the data structure will change orders of magnitude less
> than the data themselves (if we do a correct analysis first, of course ;)
LOL. The data structure will changes in ways that are unimaginable to
anyone of us yet all the time. Otherwise we would add them now. So what
we need to do is to organize the data in a way that it is flexible and
extensible. That is why I would use multiple object classes and not
extend existing ones. Along that road lies IME tremendous pain.
> > What you *want* is a custom object class representing the CLA, e.g.
> > "CLAPerson". This contains all required attributes (e.g. "CLA on file"
> > as a boolean and "scannedCLA" as a binary attribute) and if a person is
> > eligible to a CLA, you just add it to its object classes. Make claOnFile
> > mandatory and scannedCLA optional and you are good to go.
> >
> This is an option. The main issue, IMO, is how to handle CLAs stored in
> many files, and CLA type (pdf, tif, ...).
What is the relevance? Make it a multivalue bianry field and add a mime
type. The rest is left as an exercise to the reader (Hint: How does a
browser deal with this?).
> About the storage, I think that having a binary multivalued attribute to
> store the CLAs is better than relying on svn. CLAs never change, and
> LDAP can handle those big files.
+1
> > And if you look for all the CLA holders, you do a query on
> > (&(objectClass=CLAOHolder)(claOnFile=true)
> (claOnFile=true) is enough. As this attribute is 'own' by the CLAHolder
> ObjectClass, if the entry does not have this OC, it can't have the
> 'claOnFile' attribute, so no need to filter on the objectclass (but you
> will have to index the claOnFile attribute, which is ok)
Yes.
Ciao
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Java, J2EE, Linux
Mail: henning@schmiedehausen.org -- Consultant, Architect, Developer
Web: http://henning.schmiedehausen.org/
Re: CLAs and LDAP
Posted by Emmanuel Lécharny <el...@apache.org>.
Henning Schmiedehausen wrote:
> On Sat, 2008-12-06 at 15:09 +0200, Graham Leggett wrote:
>
>> Paul Querna wrote:
>>
>>
>>> In the ldap schema, we likely need some way to mark someone as having a
>>> CLA or not.
>>>
>>> We have a couple ASF members, who have never contributed code before, so
>>> while they would be in the ASF members group, they have not signed a CLA
>>> -- and therefore should _not_ have access to the public svn code areas.
>>>
>>> Maybe having a CLA is just another group?
>>>
>> There are two approaches you can take with this.
>>
>> The first is to add an attribute to the person's object, probably with
>> something sensible in it like the URL of the CLA. The catch is that you
>> need to add something to the schema for this.
>>
>> The second is to create a group representing people with CLAs on file as
>> you suggested. This doesn't require any schema change.
>>
>
> The first one restricts you to having a "CLA attribute". Which means,
> when we need a new thing, you need to add another attribute and another
> and another.
>
Only if we didn't listed the attributes we need before starting to
define the schema. Generally speaking, it might be better to keep the
number of ObjectClass low, because it's a burden from the administration
POV to manage many abstract ObjectClasses (you always have to remember
to add this and that objectClass to get a correct entry).
Remember that the data structure will change orders of magnitude less
than the data themselves (if we do a correct analysis first, of course ;)
> The second one restricts you on how to organize the tree.
>
True.
> What you *want* is a custom object class representing the CLA, e.g.
> "CLAPerson". This contains all required attributes (e.g. "CLA on file"
> as a boolean and "scannedCLA" as a binary attribute) and if a person is
> eligible to a CLA, you just add it to its object classes. Make claOnFile
> mandatory and scannedCLA optional and you are good to go.
>
This is an option. The main issue, IMO, is how to handle CLAs stored in
many files, and CLA type (pdf, tif, ...).
About the storage, I think that having a binary multivalued attribute to
store the CLAs is better than relying on svn. CLAs never change, and
LDAP can handle those big files.
> And if you look for all the CLA holders, you do a query on
> (&(objectClass=CLAOHolder)(claOnFile=true)
(claOnFile=true) is enough. As this attribute is 'own' by the CLAHolder
ObjectClass, if the entry does not have this OC, it can't have the
'claOnFile' attribute, so no need to filter on the objectclass (but you
will have to index the claOnFile attribute, which is ok)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: CLAs and LDAP
Posted by Henning Schmiedehausen <he...@schmiedehausen.org>.
On Sat, 2008-12-06 at 15:09 +0200, Graham Leggett wrote:
> Paul Querna wrote:
>
> > In the ldap schema, we likely need some way to mark someone as having a
> > CLA or not.
> >
> > We have a couple ASF members, who have never contributed code before, so
> > while they would be in the ASF members group, they have not signed a CLA
> > -- and therefore should _not_ have access to the public svn code areas.
> >
> > Maybe having a CLA is just another group?
>
> There are two approaches you can take with this.
>
> The first is to add an attribute to the person's object, probably with
> something sensible in it like the URL of the CLA. The catch is that you
> need to add something to the schema for this.
>
> The second is to create a group representing people with CLAs on file as
> you suggested. This doesn't require any schema change.
The first one restricts you to having a "CLA attribute". Which means,
when we need a new thing, you need to add another attribute and another
and another.
The second one restricts you on how to organize the tree.
What you *want* is a custom object class representing the CLA, e.g.
"CLAPerson". This contains all required attributes (e.g. "CLA on file"
as a boolean and "scannedCLA" as a binary attribute) and if a person is
eligible to a CLA, you just add it to its object classes. Make claOnFile
mandatory and scannedCLA optional and you are good to go.
And if you look for all the CLA holders, you do a query on
(&(objectClass=CLAOHolder)(claOnFile=true))
At least that is my understanding on how LDAP should be used.
Ciao
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Java, J2EE, Linux
Mail: henning@schmiedehausen.org -- Consultant, Architect, Developer
Web: http://henning.schmiedehausen.org/
Re: CLAs and LDAP
Posted by Graham Leggett <mi...@sharp.fm>.
Paul Querna wrote:
> In the ldap schema, we likely need some way to mark someone as having a
> CLA or not.
>
> We have a couple ASF members, who have never contributed code before, so
> while they would be in the ASF members group, they have not signed a CLA
> -- and therefore should _not_ have access to the public svn code areas.
>
> Maybe having a CLA is just another group?
There are two approaches you can take with this.
The first is to add an attribute to the person's object, probably with
something sensible in it like the URL of the CLA. The catch is that you
need to add something to the schema for this.
The second is to create a group representing people with CLAs on file as
you suggested. This doesn't require any schema change.
The first option is slightly more work, but allows you to do some cool
checks-and-balances, such as a script that can ask "do the CLAs within
everyone's attributes actually exist or have mistakes been made".
Regards,
Graham
--
Re: CLAs and LDAP
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 6, 2008, at 6:45 PM, Paul Querna wrote:
> Roy T. Fielding wrote:
>> On Dec 5, 2008, at 5:20 PM, Paul Querna wrote:
>>> In the ldap schema, we likely need some way to mark someone as
>>> having a CLA or not.
>> If we had a self-maintained account system, then we could incorporate
>> the CLA in the account-granting process. In other words, display the
>> CLA and have them enter their name (while logged in) to indicate that
>> they accept the CLA (or not). That amounts to a digital signature
>> under US law and we wouldn't need the scans.
>
> *cough* So, just to confirm, if we came out with a web based 'sign
> the cla' web app, which was directly tied to svn (and shell)
> account creation, this would eliminate the current need for how we
> do CLAs?
Yes. We'd just need to log the acceptance and version of CLA accepted.
That also allows folks who want commit access to agree to the CLA long
before we vote to give them commit access, thus removing another
barrier.
It is actually more provable than a written signature, since there
won't be any question that the person with the account is the same
as the one that signed the paper.
....Roy
Re: CLAs and LDAP
Posted by Paul Querna <pq...@apache.org>.
Roy T. Fielding wrote:
> On Dec 5, 2008, at 5:20 PM, Paul Querna wrote:
>
>> In the ldap schema, we likely need some way to mark someone as having
>> a CLA or not.
>
> If we had a self-maintained account system, then we could incorporate
> the CLA in the account-granting process. In other words, display the
> CLA and have them enter their name (while logged in) to indicate that
> they accept the CLA (or not). That amounts to a digital signature
> under US law and we wouldn't need the scans.
*cough* So, just to confirm, if we came out with a web based 'sign the
cla' web app, which was directly tied to svn (and shell) account
creation, this would eliminate the current need for how we do CLAs?
I've always wondered why we couldn't do it all digital, and if there
really aren't any other barriers, we should just go do it.
Re: CLAs and LDAP
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 5, 2008, at 5:20 PM, Paul Querna wrote:
> In the ldap schema, we likely need some way to mark someone as
> having a CLA or not.
If we had a self-maintained account system, then we could incorporate
the CLA in the account-granting process. In other words, display the
CLA and have them enter their name (while logged in) to indicate that
they accept the CLA (or not). That amounts to a digital signature
under US law and we wouldn't need the scans.
....Roy