Changes between Version 8 and Version 9 of GitolitePlan


Ignore:
Timestamp:
Jul 30, 2013 8:35:30 AM (22 months ago)
Author:
hvr
Comment:

some additions

Legend:

Unmodified
Added
Removed
Modified
  • GitolitePlan

    v8 v9  
    11= The Gitolite Switch = 
    22 
    3 Currently, the developer setup on `ghc.haskell.org` is a bit complicated and unfortunate. Most importantly, it hosts all of the git repositories we use. When a developer for GHC is inducted, we: 
     3Currently, the developer setup on `ghc.haskell.org` is a bit complicated and unfortunate. Most importantly, it hosts all of the Git repositories we use. When a developer for GHC is inducted, we: 
    44 
    5  * Create them a user on ghc.haskell.org 
     5 * Create them a user (i.e. a full shell account) on `ghc.haskell.org` 
    66 
    7  * Add their SSH key 
     7 * Add their SSH public key 
    88 
    9  * Add them access to the darcs group (which owns the canonical, public facing git repositories.) 
     9 * Add them access to the darcs group (which owns the canonical, public facing Git repositories.) 
    1010 
    1111Then, that user can clone from the server over SSH, and also push to the repositories directly with their new permissions. 
     
    1313This unfortunately has some downsides: 
    1414 
    15  * Every user needs a full shell account. While we probably *won't* be forkbombed by someone, few people actually *need* a full shell account, and the principle of least privilege applies here. Really, everybody is just pushing to git. 
     15 * Every user needs a full shell account.  
    1616 
    17  * Because of the last point, group and access permissions on the repositories regularly get screwed up, causing situations where people don't have access (and can't push,) or we have to have `post-receive` hooks that modify the permissions. Both of these suck (this doesn't affect e.g. the Linux kernel developers, who have pull-based development models, because they can afford to.) 
     17   * While we probably *won't* be forkbombed by someone, few people actually *need* a full shell account, and the *principle of least privilege* applies here. Really, everybody is just pushing to Git. 
    1818 
    19  * Leading on more with the last point, people invariably fix this but it's always slightly patchy, and so the repositories that need 'fixing' for things like permissions are inconsistent, and it's hard to keep track of what needs to be maintained. 
     19 * Because of the previous point, group and access permissions on the repositories regularly get screwed up, causing situations where people don't have access (and can't push,) or we have to have `post-receive` hooks that modify the permissions. Both of these suck (this doesn't affect e.g. the Linux kernel developers, who have pull-based development models, because they can afford to.) 
    2020 
    21  * All users can willy nilly create tags and branches. Ideally, only release maintainers should have permission to do things like cut a release tag. 
     21   * Due to the current permission scheme, all users in the `darcs` group are effectively at the level of Trac admins, which can manipulate the `trac.db` database (this is needed by the Git hooks to update the Trac tickets). Again, the *principle of least privilege* should apply here. 
    2222 
    23 Gitolite is a piece of software that can alleviate most of these pains and also make central management easier: https://github.com/sitaramc/gitolite/wiki 
     23   * Moreover, people invariably fix this but it's always slightly patchy, and so the repositories that need 'fixing' for things like permissions are inconsistent, and it's hard to keep track of what needs to be maintained. 
    2424 
    25 TODO FIXME: elaborate on why Gitolite is awesome. 
     25 * All users can willy nilly create (and delete!) tags and branches, and perform some risky Git operations. Ideally, only release maintainers should have permission to do things like cut a release tag. 
     26 
     27 * Git admins need to perform risky direct manipulations in the file-system, even for the simplest Git repository administration tasks. 
     28 
     29The proposed remedy is to use the Git-access wrapper [[https://github.com/sitaramc/gitolite/wiki|**Gitolite**]] which provides an authorization layer on top of Git, and is executed as a separate system user (thus accessing the git repositories with only one Unix UID).  Users accessing git repositories via ssh are discriminated by their ssh public key. 
     30 
     31Gitolite also greatly simplifies user management, as a user management is little more than adding/removing a file containing the user's public key, and pushing that the administrative "`gitolite-admin`" git repository (Gitolite is administrated via git itself!). Similarly, adding a new git repository comes down to adding a few lines to the central Gitolite repository config file and pushing that file to the "`gitolite-admin`" Git repository. 
     32 
    2633 
    2734= Proposed plan = 
     
    3340== The switch == 
    3441 
    35 Ideally, most of the new setup can occur concurrently with the normal one undisturbed. Presumably 'the big switch' can happen in an hour or so downtime, in which we take the old URIs offline, bring gitolite online and tell people this is the time to fix your push URLs. 
     42Ideally, most of the new setup can occur concurrently with the normal one undisturbed. Presumably 'the big switch' can happen in an hour or so downtime, in which we take the old URIs offline, bring Gitolite online and tell people this is the time to fix your push URLs. 
    3643 
    3744== Developer changes == 
    3845 
    39 TODO FIXME: note what changes here for developers who already have push based access 
     46For developers (with push permissions) who have already checked out repositories, the only change needed is to go over their repositories and update their git uris from 
     47 
     48 `ssh://<user>@darcs.haskell.org/src/darcs/<repo-name>` 
     49 
     50to 
     51 
     52 `ssh://[email protected]/<repo-name>` 
     53 
     54This can be accomplished either by editing their '.git/config' manually or using a Git command like `git remote set-url origin NEW-URL`. 
    4055 
    4156= Current status = 
     
    4560== Questions == 
    4661 
    47  * Tangential: should we deprecate the darcs.haskell.org URL? Who uses it? The name was known to be a funny misnomer from the git switchover times, but As Far As Austin Knows, only GHC developers really use it these days. Perhaps we could just retire it. 
     62 * Tangential: should we deprecate the darcs.haskell.org URL? Who uses it? The name was known to be a funny misnomer from the Git switchover times, but As Far As Austin Knows, only GHC developers really use it these days. Perhaps we could just retire it. 
    4863   * Austin notes that both nhc and yhc use it, so Malcolm and Neil will need to be asked. 
     64 
     65   * We can leave `darcs.haskell.org` as-is for legacy reasons, while creating new VHOST on `http://git.haskell.org/` which would expose only the Gitolite-owned git repositories (and maybe also a Cgit front-page as e.g. on http://git.kernel.org) 
    4966 
    5067 * Who's actively committing, and does anybody beyond that actually *need* a shell account? It's unclear who uses `ghc.haskell.org` for what at the moment, beyond push access. 
     
    5269 * Tangential: The current directory setup is a total mess on `darcs.haskell.org`, especially since the old darcs repos hang around there. Maybe we should clean it up if we're going to use it for a browseable directory. 
    5370 
     71 
    5472== Contact points == 
    5573