Re: LDAP title field

[Sam Ruby]

On Sun, Apr 9, 2017 at 9:30 PM, sebb  wrote:
>
>>> I’m not opposed in theory, but grafting a JSON or YAML parser onto the 
>>> existing ap-adduser code is out of scope right now, and more than likely 
>>> not worth the effort. If we want to go down that road, it would make more 
>>> sense to rewrite the acreq process from the ground up.
>>>
>
> What languages are used?

Python.

Here's the relevant sources:

https://svn.apache.org/repos/infra/infrastructure/trunk/tools/new-account-reqs.py
https://svn.apache.org/repos/infra/infrastructure/trunk/tools/updateiclas.py

The relevant regexs are at the top.

- Sam Ruby

Re: LDAP title field

[sebb]

On 10 April 2017 at 02:09, Craig Russell  wrote:
>
>> On Apr 9, 2017, at 5:42 PM, Chris Lambertus  wrote:
>>
>>
>>> On Apr 9, 2017, at 5:22 PM, Craig Russell  wrote:
>>>
>>> tl;dr Adding title field is fine. I see it as secretary's responsibility to 
>>> harmonize iclas.txt and ldap.
>>
>> Ack.
>>
>>> We might as well add Suffix to LDAP to cater for the 23 III and 6 II that 
>>> we have. I've added a comment to IIINFRA-13850
>>
>> Agreed. Are there any other person-data related fields we should consider 
>> capturing/adding? Now’s the time, since I’m committed to updating the infra 
>> ldap/adduser tooling at this point.
>>
> I just took a look at some self-proclaimed Name Data Entry Standards and it 
> looks like adding Prefix (or title) and Suffix should do fine for our 
> purposes. Sometimes Middle Name(s) is also called out but I don't think there 
> is any reason for us to distinguish Middle Name(s) from Given Name. And if 
> John P Erwin III MD shows up we will just have to deal with it.

GivenName is not an ideal attribute name, because many people have
more than one given name, and they don't necessarily use the first one
in daily life.
However if it is treated as a Preferred name, this problem disappears.

> Craig
>
> https://www.lehigh.edu/lewis/data_standards.htm#Name
> https://www.lehigh.edu/lewis/suffix.htm
>
>>
>>
 On Apr 9, 2017, at 10:05 AM, Sam Ruby  wrote:
>>
>> 
>>
 Once created, we need to nail down the responsibility for updating
 names.  Given that names change infrequently and at least one copy
 (iclas.txt) isn't updateable by users themselves, this responsibility
 should go to the secretary (Craig, please confirm?), and the necessary
 tooling needs to be in place to allow the secretarial team to do so.
>>>
>>> Secretary is up to this task, given adequate tooling.
>>
>> Excellent. I think this will be a good use for the existing LDAP/ICLA 
>> comparison tool, which could probably be extended to allow for some simple 
>> “on the fly” editing of the various fields to correct any discrepancies.
>>
 ---

 The format of a new-account-request isn't flexible, but is workable
 (I'd prefer JSON or YAML, but adding still more fields at the end is
 probably easier):
>>

The more fields there are in a single CSV entry the easier it is to
accidentally use the wrong one or omit one, especially if the record
is manually created or editted.
It's also harder to review manually.
So I think a more structured file would be better.

Maybe even use the LDAP attribute names as prefixes?
(i.e. something like LDIF output)

If suitably implemented, this would allow additional fields to be
added without further coding.

>> I’m not opposed in theory, but grafting a JSON or YAML parser onto the 
>> existing ap-adduser code is out of scope right now, and more than likely not 
>> worth the effort. If we want to go down that road, it would make more sense 
>> to rewrite the acreq process from the ground up.
>>

What languages are used?

>>
>>
>> Thanks for the input so far. Technical/implementation details can be 
>> captured in INFRA-13850.
>>
>> -Chris
>>
>>
>
> Craig L Russell
> c...@apache.org
>
>

Re: LDAP title field

[Craig Russell]

> On Apr 9, 2017, at 5:42 PM, Chris Lambertus  wrote:
> 
> 
>> On Apr 9, 2017, at 5:22 PM, Craig Russell  wrote:
>> 
>> tl;dr Adding title field is fine. I see it as secretary's responsibility to 
>> harmonize iclas.txt and ldap. 
> 
> Ack. 
> 
>> We might as well add Suffix to LDAP to cater for the 23 III and 6 II that we 
>> have. I've added a comment to IIINFRA-13850
> 
> Agreed. Are there any other person-data related fields we should consider 
> capturing/adding? Now’s the time, since I’m committed to updating the infra 
> ldap/adduser tooling at this point.
> 
I just took a look at some self-proclaimed Name Data Entry Standards and it 
looks like adding Prefix (or title) and Suffix should do fine for our purposes. 
Sometimes Middle Name(s) is also called out but I don't think there is any 
reason for us to distinguish Middle Name(s) from Given Name. And if John P 
Erwin III MD shows up we will just have to deal with it.

Craig

https://www.lehigh.edu/lewis/data_standards.htm#Name
https://www.lehigh.edu/lewis/suffix.htm

> 
> 
>>> On Apr 9, 2017, at 10:05 AM, Sam Ruby  wrote:
> 
> 
> 
>>> Once created, we need to nail down the responsibility for updating
>>> names.  Given that names change infrequently and at least one copy
>>> (iclas.txt) isn't updateable by users themselves, this responsibility
>>> should go to the secretary (Craig, please confirm?), and the necessary
>>> tooling needs to be in place to allow the secretarial team to do so.
>> 
>> Secretary is up to this task, given adequate tooling. 
> 
> Excellent. I think this will be a good use for the existing LDAP/ICLA 
> comparison tool, which could probably be extended to allow for some simple 
> “on the fly” editing of the various fields to correct any discrepancies.
> 
>>> ---
>>> 
>>> The format of a new-account-request isn't flexible, but is workable
>>> (I'd prefer JSON or YAML, but adding still more fields at the end is
>>> probably easier):
> 
> I’m not opposed in theory, but grafting a JSON or YAML parser onto the 
> existing ap-adduser code is out of scope right now, and more than likely not 
> worth the effort. If we want to go down that road, it would make more sense 
> to rewrite the acreq process from the ground up.
> 
> 
> 
> Thanks for the input so far. Technical/implementation details can be captured 
> in INFRA-13850.
> 
> -Chris
> 
> 

Craig L Russell
c...@apache.org

Re: LDAP title field

[Chris Lambertus]

> On Apr 9, 2017, at 5:22 PM, Craig Russell  wrote:
> 
> tl;dr Adding title field is fine. I see it as secretary's responsibility to 
> harmonize iclas.txt and ldap.

Ack.

> We might as well add Suffix to LDAP to cater for the 23 III and 6 II that we 
> have. I've added a comment to IIINFRA-13850

Agreed. Are there any other person-data related fields we should consider 
capturing/adding? Now’s the time, since I’m committed to updating the infra 
ldap/adduser tooling at this point.



>> On Apr 9, 2017, at 10:05 AM, Sam Ruby  wrote:



>> Once created, we need to nail down the responsibility for updating
>> names.  Given that names change infrequently and at least one copy
>> (iclas.txt) isn't updateable by users themselves, this responsibility
>> should go to the secretary (Craig, please confirm?), and the necessary
>> tooling needs to be in place to allow the secretarial team to do so.
> 
> Secretary is up to this task, given adequate tooling.

Excellent. I think this will be a good use for the existing LDAP/ICLA 
comparison tool, which could probably be extended to allow for some simple “on 
the fly” editing of the various fields to correct any discrepancies.

>> ---
>> 
>> The format of a new-account-request isn't flexible, but is workable
>> (I'd prefer JSON or YAML, but adding still more fields at the end is
>> probably easier):

I’m not opposed in theory, but grafting a JSON or YAML parser onto the existing 
ap-adduser code is out of scope right now, and more than likely not worth the 
effort. If we want to go down that road, it would make more sense to rewrite 
the acreq process from the ground up.



Thanks for the input so far. Technical/implementation details can be captured 
in INFRA-13850.

-Chris




signature.asc
Description: Message signed with OpenPGP

Re: LDAP title field

[Craig Russell]

tl;dr Adding title field is fine. I see it as secretary's responsibility to 
harmonize iclas.txt and ldap. 

Kudos to sebb for keeping an eye on our records and pointing out deficiencies.

We might as well add Suffix to LDAP to cater for the 23 III and 6 II that we 
have. I've added a comment to IIINFRA-13850

> On Apr 9, 2017, at 10:05 AM, Sam Ruby  wrote:
> 
> On Sun, Apr 9, 2017 at 11:10 AM, Chris Lambertus  wrote:
>> Hi Whimsy,
>> 
>> I’m proposing in https://issues.apache.org/jira/browse/INFRA-13850 that we
>> implement the Title field in LDAP. This would require some tooling changes
>> that would involve Secretary, possibly whimsy code, and infra mods to the
>> ap-adduser scripts and other tools that manage and process
>> new-account-reqs.txt.
>> 
>> Any thoughts on this change and what would need to be touched to make this
>> happen?
> 
> Related:
> https://issues.apache.org/jira/browse/INFRA-13834
> https://lists.apache.org/thread.html/0c78dee2654469db7ec5873974570dbd26e37ad1b7c5497817f69112@%3Cdev.whimsical.apache.org%3E
> 
> It looks like we new fields: givenName and title.  And a number of
> existing fields, including cn and entries in iclas.txt (which includes
> separate entries for public and full names).
> 
> ---
> 
> Overall, we should be moving in the direction of having the person
> themselves proving (or at least verifying) their name during the
> initial account creation process.  Prerequisites to a new account are
> an ICLA and an invite, and these can happen in either order, so there
> are two paths.
> 
> Once created, we need to nail down the responsibility for updating
> names.  Given that names change infrequently and at least one copy
> (iclas.txt) isn't updateable by users themselves, this responsibility
> should go to the secretary (Craig, please confirm?), and the necessary
> tooling needs to be in place to allow the secretarial team to do so.

Secretary is up to this task, given adequate tooling. 
> 
> ---
> 
> The format of a new-account-request isn't flexible, but is workable
> (I'd prefer JSON or YAML, but adding still more fields at the end is
> probably easier):
> 
> https://svn.apache.org/repos/infra/infrastructure/trunk/acreq/new-account-reqs.txt
> 
> If this changes, three (and possibly four) tools will need to be updated:
> 
> https://svn.apache.org/repos/infra/infrastructure/trunk/tools/new-account-reqs.py
> https://whimsy.apache.org/officers/acreq
> https://whimsy.apache.org/secmail/
> 
> and possibly:
> 
> https://svn.apache.org/repos/infra/infrastructure/trunk/tools/updateiclas.py
> 
> ---
> 
> The secretarial team already can update cn and givenName; and I
> presume that we will be allowed to update title too when it is added.
> 
> There is a tool for detecting mismatches between iclas.txt and LDAP;
> but given that givenName and title aren't in iclas.txt, that is not
> likely to be affected.
> 
> What I would like to see as the preferred interface for the secretary
> to use to update names is the roster tool:
> 
> https://whimsy.apache.org/roster/committer/

Yes, this makes sense for corrections, once tooling is in place.

Note that it's relatively easy to fix most of the issues in 
https://issues.apache.org/jira/browse/INFRA-13834 given that we understand 
that: Dr. is a title; van, von, Van, and Von are part of family name, II and 
III are suffixes, and most everything else is part of given name.

Note also that asian names in particular are problematic because many iclas 
have last name first which is the custom, but many iclas have last name last 
which meets Western custom. I attempt to figure out which is which but I know 
there are some wrong entries. 

I'm looking forward to the time when we have the ability for people to enter 
their own icla information, assuming that they can understand that there are 
three fields required: Family Name, Given Name, and Title (optional). Of 
course, we also have a couple of III lurking in there.

Craig
> 
> This tool already will update LDAP and iclas.txt.
> 
>> -Chris
> 
> - Sam Ruby

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org http://db.apache.org/jdo

[jira] [Commented] (WHIMSY-84) Add ability to list podling committers separate from PPMC members

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15962298#comment-15962298
 ] 

John D. Ament commented on WHIMSY-84:
-

There are two cases I know of - and probably others.

1. RocketMQ explicitly wants to vote people in as committer then PPMC, until 
they get comfortable with the process.
2. Tamaya had done committer == PPMC, they had someone voted in who they 
weren't sure of, so decided to make committer only.

In both of these cases, its not a podling specific question, but a combination 
of person + podling.  There are other cases, I have no idea which, where it is 
a binary choice.

> Add ability to list podling committers separate from PPMC members
> -
>
> Key: WHIMSY-84
> URL: https://issues.apache.org/jira/browse/WHIMSY-84
> Project: Whimsy
>  Issue Type: Improvement
>Reporter: John D. Ament
>
> The roster tool for podlings currently doesn't have the ability to 
> differentiate committers and PPMC members.  While its true that the aim is to 
> have committer == PPMC, not all podlings do this.  I think it would be useful 
> for the tool to have the roster listed include some attribute for PPMC 
> members different from regular committers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (WHIMSY-84) Add ability to list podling committers separate from PPMC members

[John D. Ament (JIRA)]

John D. Ament created WHIMSY-84:
---

 Summary: Add ability to list podling committers separate from PPMC 
members
 Key: WHIMSY-84
 URL: https://issues.apache.org/jira/browse/WHIMSY-84
 Project: Whimsy
  Issue Type: Improvement
Reporter: John D. Ament


The roster tool for podlings currently doesn't have the ability to 
differentiate committers and PPMC members.  While its true that the aim is to 
have committer == PPMC, not all podlings do this.  I think it would be useful 
for the tool to have the roster listed include some attribute for PPMC members 
different from regular committers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Bug in account creation process?

[Sam Ruby]

On Sat, Apr 8, 2017 at 5:31 PM, Greg Stein  wrote:
>
> I would suggest allowing the LDAP maintainers access to the Whimsy page:
>   cn=apldap,ou=groups,ou=services,dc=apache,dc=org

Done.

This demonstrates two things:

1) It is possible to allow multiple disjoint groups access to access a
resource using only HTTPD.

2) There is demand for wider groups to access some of these scripts,
even if only in a degraded (read-only) mode.

My conclusion: there is no "one size fits all" answer to
authentication that fits all tools.  See also:
https://issues.apache.org/jira/browse/WHIMSY-54

- Sam Ruby

RECOVERY: whimsy.apache.org (whimsy.apache.org (https)) is back up!

[Ping My Box]

Hi there!
The service at whimsy.apache.org (whimsy.apache.org (https)) seems to be back 
in working order.

With regards,
Ping My Box - https://www.pingmybox.com/

ALERT: whimsy.apache.org (whimsy.apache.org (https)) is DOWN!

[Ping My Box]

Hi there!
The service at whimsy.apache.org (whimsy.apache.org (https)) appears to be down 
from multiple locations around the world.

The exact error is:

Error component: connect
Error code: [Errno 111] Connection refused
Debug output:
[Sun Apr  9 19:55:39 2017]: Initialising socket
[Sun Apr  9 19:55:39 2017]: Looking up hostname whimsy.apache.org...
[Sun Apr  9 19:55:39 2017]: Connecting to 207.244.88.137:443
[Sun Apr  9 19:55:39 2017]: Caught exception: [Errno 111] Connection refused




With regards,
Ping My Box - https://www.pingmybox.com/

[jira] [Commented] (WHIMSY-54) Re-organise auth. by TLD?

[Sam Ruby (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15962198#comment-15962198
 ] 

Sam Ruby commented on WHIMSY-54:


And then there are more exceptions.  Every committer can visit the roster tool, 
but what data you see and what data you can modify depends on which groups you 
belong to.

> Re-organise auth. by TLD?
> -
>
> Key: WHIMSY-54
> URL: https://issues.apache.org/jira/browse/WHIMSY-54
> Project: Whimsy
>  Issue Type: Improvement
>Reporter: Sebb
>
> Various parts of Whimsy require auth.
> At present this is done per app, which results in quite a complicated scheme.
> Also the auth conf is held in puppet whereas the app is in the Whimsy repo, 
> so it's tricky to relate them.
> When adding a new app, the puppet config has to be updated as well.
> This can easily be overlooked.
> Maybe we should just use auth at the top level directory?
> This might require some apps to be moved, but would be much simpler to 
> maintain going forward.
> The following levels are used currently:
> None
> ASF Committers
> ASF Members and Incubator PMC
> ASF Members and Officers
> ASF Members
> ASF Secretarial Team
> This suggests the following directories as a minimum:
> committers
> incubator
> officers
> members
> secretary



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: LDAP title field

[Sam Ruby]

On Sun, Apr 9, 2017 at 11:10 AM, Chris Lambertus  wrote:
> Hi Whimsy,
>
> I’m proposing in https://issues.apache.org/jira/browse/INFRA-13850 that we
> implement the Title field in LDAP. This would require some tooling changes
> that would involve Secretary, possibly whimsy code, and infra mods to the
> ap-adduser scripts and other tools that manage and process
> new-account-reqs.txt.
>
> Any thoughts on this change and what would need to be touched to make this
> happen?

Related:
https://issues.apache.org/jira/browse/INFRA-13834
https://lists.apache.org/thread.html/0c78dee2654469db7ec5873974570dbd26e37ad1b7c5497817f69112@%3Cdev.whimsical.apache.org%3E

It looks like we new fields: givenName and title.  And a number of
existing fields, including cn and entries in iclas.txt (which includes
separate entries for public and full names).

---

Overall, we should be moving in the direction of having the person
themselves proving (or at least verifying) their name during the
initial account creation process.  Prerequisites to a new account are
an ICLA and an invite, and these can happen in either order, so there
are two paths.

Once created, we need to nail down the responsibility for updating
names.  Given that names change infrequently and at least one copy
(iclas.txt) isn't updateable by users themselves, this responsibility
should go to the secretary (Craig, please confirm?), and the necessary
tooling needs to be in place to allow the secretarial team to do so.

---

The format of a new-account-request isn't flexible, but is workable
(I'd prefer JSON or YAML, but adding still more fields at the end is
probably easier):

https://svn.apache.org/repos/infra/infrastructure/trunk/acreq/new-account-reqs.txt

If this changes, three (and possibly four) tools will need to be updated:

https://svn.apache.org/repos/infra/infrastructure/trunk/tools/new-account-reqs.py
https://whimsy.apache.org/officers/acreq
https://whimsy.apache.org/secmail/

and possibly:

https://svn.apache.org/repos/infra/infrastructure/trunk/tools/updateiclas.py

---

The secretarial team already can update cn and givenName; and I
presume that we will be allowed to update title too when it is added.

There is a tool for detecting mismatches between iclas.txt and LDAP;
but given that givenName and title aren't in iclas.txt, that is not
likely to be affected.

What I would like to see as the preferred interface for the secretary
to use to update names is the roster tool:

https://whimsy.apache.org/roster/committer/

This tool already will update LDAP and iclas.txt.

> -Chris

- Sam Ruby

LDAP title field

[Chris Lambertus]

Hi Whimsy,

I’m proposing in https://issues.apache.org/jira/browse/INFRA-13850 
 that we implement the Title 
field in LDAP. This would require some tooling changes that would involve 
Secretary, possibly whimsy code, and infra mods to the ap-adduser scripts and 
other tools that manage and process new-account-reqs.txt.

Any thoughts on this change and what would need to be touched to make this 
happen?

-Chris



signature.asc
Description: Message signed with OpenPGP

Re: Gathering Data (Was: ToDo list)

[Sam Ruby]

On Sat, Apr 8, 2017 at 3:27 PM, Christian Grobmeier
 wrote:
> hi,
>
> On Thu, Apr 6, 2017, at 14:43, Sam Ruby wrote:
>> Perhaps the data that I am drawing from is bad, if so perhaps Jim
>> (copied) can help.  See:
>>
>> https://svn.apache.org/repos/private/foundation/Meetings/20170328/attend
>>
>> People on that list are considered to have attended.  People with (v)
>> next to their names did so only through voting.  You voted but aren't on
>> that list?

I've identified 50 people (including you) who are listed as voting but
aren't listed as attending (with or without a (v)). I'm continuing to
investigate...

> Exactly.
>
> Thanks!
>
> Christian

- Sam Ruby

[jira] [Commented] (WHIMSY-54) Re-organise auth. by TLD?

[Sam Ruby (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15962117#comment-15962117
 ] 

Sam Ruby commented on WHIMSY-54:


The commits you saw were not successful; but I'm certainly experimenting along 
those lines.

I believe I have working on my machine asf-secretary and root, but I won't know 
for sure until it is deployed as I don't have a test id (and certainly not one 
as root).

Not yet explored: dissimilar ldap configurations.  For example, member is a 
list of memberUids, but pmc-chair is a list of members (full dn's).  This poses 
two challenges: finding a way to represent this cleanly in the YAML and making 
it work.  Both appear to be solvable.

There remains one notable exception: if a committer is invited to a board 
meeting, they have access to the agenda even if they are neither a member or 
pmc-chair.  

> Re-organise auth. by TLD?
> -
>
> Key: WHIMSY-54
> URL: https://issues.apache.org/jira/browse/WHIMSY-54
> Project: Whimsy
>  Issue Type: Improvement
>Reporter: Sebb
>
> Various parts of Whimsy require auth.
> At present this is done per app, which results in quite a complicated scheme.
> Also the auth conf is held in puppet whereas the app is in the Whimsy repo, 
> so it's tricky to relate them.
> When adding a new app, the puppet config has to be updated as well.
> This can easily be overlooked.
> Maybe we should just use auth at the top level directory?
> This might require some apps to be moved, but would be much simpler to 
> maintain going forward.
> The following levels are used currently:
> None
> ASF Committers
> ASF Members and Incubator PMC
> ASF Members and Officers
> ASF Members
> ASF Secretarial Team
> This suggests the following directories as a minimum:
> committers
> incubator
> officers
> members
> secretary



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (WHIMSY-54) Re-organise auth. by TLD?

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15962107#comment-15962107
 ] 

Sebb commented on WHIMSY-54:


It looks as though HTTPD does support alternate LDAP auth - as per recent 
changes to the secretary tree.

So long as there is an LDAP group for each of the qualifying classes of logins, 
it may now be possible to delegate all auth to the HTTPD server?

> Re-organise auth. by TLD?
> -
>
> Key: WHIMSY-54
> URL: https://issues.apache.org/jira/browse/WHIMSY-54
> Project: Whimsy
>  Issue Type: Improvement
>Reporter: Sebb
>
> Various parts of Whimsy require auth.
> At present this is done per app, which results in quite a complicated scheme.
> Also the auth conf is held in puppet whereas the app is in the Whimsy repo, 
> so it's tricky to relate them.
> When adding a new app, the puppet config has to be updated as well.
> This can easily be overlooked.
> Maybe we should just use auth at the top level directory?
> This might require some apps to be moved, but would be much simpler to 
> maintain going forward.
> The following levels are used currently:
> None
> ASF Committers
> ASF Members and Incubator PMC
> ASF Members and Officers
> ASF Members
> ASF Secretarial Team
> This suggests the following directories as a minimum:
> committers
> incubator
> officers
> members
> secretary



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)