388594 - Create LDAP accounts for existing CVS committers for access to buildbot-try and hg

Status: RESOLVED FIXED

(mozilla.org :: Repository Account Requests, task)

Description

[Benjamin Smedberg]

Both mercurial and the buildbot-try support are new projects that use/will use LDAP auth. Both should be accessible to all our current CVS committers. 

We should create/import LDAP accounts for existing CVS committers and granting them access to these two functions.

Theoretically I suppose we could even use LDAP auth for CVS commit access to avoid having multiple accounts, but I don't know how hard that is.

Comment 1

[Dave Miller [:justdave]]

I'm going to say this depends on getting despot to talk to LDAP or we're going to have no way to manage this effectively.

Comment 2

[Benjamin Smedberg]

Despot to talk to LDAP to control CVS checkins, or Hg? You really can't control Hg permissions on a per-directory basis, because of the way changesets are pushed.

Comment 3

[Reed Loden [:reed]]

Bug 353463? :)

Comment 4

[Dave Miller [:justdave]]

LDAP to control CVS checkins.  Putting all the CVS accounts into LDAP creates a much larger burden on IT to keep the accounts in sync with CVS any time people make changes to their accounts or new accounts are created.

Since we can already get ssh keys out of LDAP, having CVS accounts in LDAP will get rid of the necessity for IT to drop in SSH keys every time a new account is created, too, which would be a nice bonus (user will be able to manage their own keys, or the normal admin (marcia) can, right from despot).

Comment 5

[Reed Loden [:reed]]

Attachment: List of accounts that haven't checked-in in 6 months

Spoke with Brendan yesterday about whether to import all ~300 CVS accounts or a subset of those based on people that have last committed something to CVS within a period of time. He said he wanted to see about only importing those who have checked something in within the last 6 months. Attached is a list of people with a CVS account who have NOT checked-in within the 6 months. These people would not have an LDAP/Hg account created for them if we went with list list of people to exclude. Please note that some of these people just recently received a CVS account and have not checked anything in yet, so the list is somewhat flawed in that sense. I personally feel that this list is too large to be used as an exclude list. Maybe the time frame could be extended to some larger period (1 year, 2 years, etc.), or maybe just import all ~300 accounts directly.

Brendan, what do you think?

Comment 6

[Brendan Eich [:brendan]]

If it were up to me, I'd automate things so you can add individuals on demand. Two reasons:

1. Don't want to pull focus from 1.9/fx3 and the cvs trunk.
2. Don't want all the old accounts added by default, we just don't need the (small, unknown magnitude, but non-zero) risk.

If you want to include all new accounts without activity, new meaning <= 1 year old, and all accounts active in that last year, ok by me. Please produce that positive list as well as a negative list. If we have new accounts craeted 11 months ago that have not been used, that would be good to know (11, 10, 9, ... -- you get what I mean). We grant access fairly liberally and based on patch rate, so if someone got access but then stopped patching, it would be good to know.

/be

Comment 7

[Reed Loden [:reed]]

Attachment: List of accounts who have checked-in in the last year

These people have committed something to the CVS repository in the last year.

Comment 8

[Reed Loden [:reed]]

Attachment: List of accounts who have NOT checked-in in the last year and are not new

These are the accounts that have not checked-in in the last year and are not new within the last 3 months. These would be the accounts I would exclude when creating Hg/LDAP accounts.

Comment 9

[Reed Loden [:reed]]

Brendan, are these sufficient-enough lists for me to use to start creating Hg accounts for people?

Comment 10

[Robert Helmer [:rhelmer]]

reed asked me to comment here; I am fine with this list. One note - cltbld needs r/w access for the immediate future, although I'd like to get away from this eventually if we can. 

Comment 11

[Brendan Eich [:brendan]]

I'm fine with the lists. The idea is not to be exclusive of anyone, just to reduce the sysadmin overhead to a dull roar.

/be

Comment 12

[Reed Loden [:reed]]

Brendan, another question:

Once I create these accounts, all these people will immediately have access to commit to the "mozilla-central" repo (and maybe other repos that haven't specifically been locked down to certain people). Since it seems like decisions haven't been made about how Hg will work and how the process of going from 1.9 to Moz2 will work, maybe the repos should all be locked down for now until decisions can be made about these questions? Your thoughts on the matter would be appreciated.

I was told that the 1.9 to Moz2 migration was discussed at the Gecko meeting yesterday but that no real consensus had been made on how this would work, so I just want to make sure we aren't opening the flood gates for things that shouldn't be occurring yet.

Comment 13

[Stuart Parmenter]

There is a large number of people in the list of contributors who already have ldap accounts with a different account name.  What is the plan to sync those/alias them?

Comment 14

[Reed Loden [:reed]]

(In reply to comment #13)
> There is a large number of people in the list of contributors who already have
> ldap accounts with a different account name.  What is the plan to sync
> those/alias them?

I am working on a "map" list that my script will use when creating accounts. This "map" will contain the old CVS address and the new LDAP address for each of the accounts I can find that already have an LDAP account (such as all Mozilla employees). My script will just process the map file and modify the appropriate LDAP account to give it access to Hg instead of creating another LDAP account (which would be a maintenance nightmare).

Comment 15

[Brendan Eich [:brendan]]

Reed: we trust these people with commit access to cvs.mozilla.org, where most partitions are unrestricted. If you think anyone is going to do damage (invertible as in cvs.m.o since the operations are via a VCS protocol, not raw filesystem ops) then why does that person have CVS commit access?

I'd rather not waste time with pessimistic policing.

/be

Comment 16

[Brendan Eich [:brendan]]

Why not extend despot with the map from old to new names? Or extend LDAP -- I have no reason to favor extending despot. Just looking for something other than a map private to a one-time script, in case we need to do this again or to reverse-map.

/be

Comment 17

[Reed Loden [:reed]]

(In reply to comment #15)
> Reed: we trust these people with commit access to cvs.mozilla.org, where most
> partitions are unrestricted. If you think anyone is going to do damage
> (invertible as in cvs.m.o since the operations are via a VCS protocol, not raw
> filesystem ops) then why does that person have CVS commit access?
> 
> I'd rather not waste time with pessimistic policing.

Well, this was just brought up by somebody I was discussing this bug with today, so I thought it a valid point to bring up to make sure you were aware and ok with it. If you feel it is not necessary, then so be it.

This person was mostly concerned that we had no build infrastructure (tinderboxen) for Hg yet and that the webtools (http://hg.mozilla.org) were not sufficient enough for work to begin.

Comment 18

[Brendan Eich [:brendan]]

Let's not go back and forth in the bug. If "someone" is concerned, they can mail me. It's silly to think a bunch of people will start committing changes (of any kind, good or bad) to hg.mozilla.org's repos, given sudden access. If we see any commits at all, we'll (a) be surprised; (b) invest precious time investigating *then*, not chinwagging now.

Mozilla 2 tinderboxen and viewvc or better are on the build team's to-do list for this quarter.

/be

Comment 19

[Reed Loden [:reed]]

(In reply to comment #16)
> Why not extend despot with the map from old to new names? Or extend LDAP -- I
> have no reason to favor extending despot. Just looking for something other than
> a map private to a one-time script, in case we need to do this again or to
> reverse-map.

I filed bug 353463 almost a year ago to deal with rewriting Despot to handle multiple VCSs and be LDAP-based, but that project hasn't really gone anywhere so far. It's going to be a large project (if it ever happens), so I wouldn't count on having it any time soon.

The current Despot does not understand Hg nor LDAP currently, so we can't really do anything there. It may be possible to set up aliases somehow in LDAP that could be used to map between CVS and LDAP accounts, but I'm unsure of how that would work exactly, and it would need to be researched and planned out before anything on a larger scale could be done. Aravind would know more about this.

Comment 20

[Reed Loden [:reed]]

(In reply to comment #18)
> Let's not go back and forth in the bug.
...
> Mozilla 2 tinderboxen and viewvc or better are on the build team's to-do list
> for this quarter.

Ok, that sounds good. Do you see anything stopping the creation of these accounts currently? Is my use of a one-time map between CVS and LDAP accounts sufficient for now until more research is put into the aliasing question?

Comment 21

[Brendan Eich [:brendan]]

Well, worse is better, I suppose. Just attach that script's map file to a bug for posterity, at least.

I'm in favor of non-grand plans. Instead of "replace despot" or "rewrite despot", "extend despot" or "extend LDAP". Seems about as hard as writing a script with its private map file, but what do I know?

/be

Comment 22

[Reed Loden [:reed]]

(In reply to comment #21)
> Well, worse is better, I suppose. Just attach that script's map file to a
> bug for posterity, at least.

Sure, that's very doable. I will work on finishing the map and completing my testing of my script tonight, and I will attach the map to the bug.

> I'm in favor of non-grand plans. Instead of "replace despot" or "rewrite
> despot", "extend despot" or "extend LDAP". Seems about as hard as writing a
> script with its private map file, but what do I know?

Getting Despot to understand LDAP and Hg would require major changes, none of which are trivial with its codebase, so, imho, it would actually be better and far easier just to rewrite it from scratch with a more general thought in place on how it should work (abstracting out the VCS component to allow for multiple VCSs, hooking into LDAP, allowing better management of modules, more fine-grained permissions, etc.). It's not at all tied to anything besides CVS, so adding aliasing ability to it wouldn't serve much of a purpose currently.

Comment 23

[Reed Loden [:reed]]

Attachment: CVS to LDAP user map - v1

I spent a good bit of time tracking down accounts and mapping them to current LDAP accounts, but it's very possible I've missed some. I purposely left out any of the interns, as their @mozilla.com LDAP accounts will be deleted at the end of the summer, so it's more logical to have separate accounts created for them for now so we don't have to worry about renaming later. Please let me know if you see anybody I missed. This is mostly a manual job of just comparing lists of people and checking if they have an LDAP account already, so it's not something that is guaranteed to be correct or complete. However, I think I have most of the accounts, so if I did miss somebody, it's not that difficult to merge the new and old account together.

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm assuming the account name used for auth isn't going to show up in any permanent logs?  (That's sort of a problem in itself, but here it might be an advantage.)  I want my permanent email address in history showing my commits, not my @mozilla.com address.  But with hg I can do that (or, for that matter, blame anybody I want).

Comment 25

[Reed Loden [:reed]]

All accounts were created this afternoon. New users received an e-mail with their LDAP username and password while old users just had their accounts modified to have access to Hg.

Comment 26

[Robert Sayre]

My CVS commit access is for [e-mail]. That should be true for Hg.

Comment 27

[Reed Loden [:reed]]

(In reply to comment #26)
> My CVS commit access is for [e-mail]. That should be true for Hg.

File a new bug for this issue. This bug as requested is fixed.

Comment 28

[Reed Loden [:reed]]

This isn't your bug. I fixed this bug as requested. Please do not hijack bugs. If you have a problem with the way this bug was fixed, file a new bug.

Comment 29

[Robert Sayre]

(In reply to comment #28)
> This isn't your bug. I fixed this bug as requested. Please do not hijack bugs.
> If you have a problem with the way this bug was fixed, file a new bug.
> 

Reed: if you fail to fix a bug, it gets reopened. You mapped [e-mail] to [e-mail]. That is a failure for so many reasons it's hard to believe I have to explain it. I am very irritated with you right now, so I am going to leave the bug alone.

Do not touch any bug I am involved in, ever.

Comment 30

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

See comment 24.