Changes between Version 10 and Version 11 of GitolitePlan


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

yet more content

Legend:

Unmodified
Added
Removed
Modified
  • GitolitePlan

    v10 v11  
    1313This unfortunately has some downsides: 
    1414 
    15  * Every user needs a full shell account.  
    16  
    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. 
     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. 
    1816 
    1917 * 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.) 
    20  
    2118   * 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. 
    22  
    2319   * 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. 
    2420 
    2521 * 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. 
    2622 
    27  * Git admins need to perform risky direct manipulations in the file-system, even for the simplest Git repository administration tasks. 
     23 * Git admins need to perform risky direct manipulations in the file-system, even for the simplest Git repository administration tasks. Also, Git hook scripts are not centrally managed right now, but placed individually in each git repository that needs them; thus to fix/improve a git hook script, one needs to update all git repositories using the affected script. 
    2824 
    2925The 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. 
     
    3632Below are some notes about how we (Austin & Herbert) would like to go about doing this. 
    3733 
    38 == Setup == 
    39  
    4034== The switch == 
    4135 
     
    4640For 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 
    4741 
    48  `ssh://<user>@darcs.haskell.org/src/darcs/<repo-name>` 
     42 `ssh://<user>@darcs.haskell.org/srv/darcs/<repo-name>` 
    4943 
    5044to 
     
    5347 
    5448This can be accomplished either by editing their '.git/config' manually or using a Git command like `git remote set-url origin NEW-URL`. 
     49 
     50The old Git `ssh://` URLs will continue to work, however, as the user won't have direct write permissions anymore at the filesystem level, they'll effectively become read-only URLs. 
     51 
     52Last but not least, the `sync-all` script needs to be adapted. 
     53 
     54=== Additional user-visible changes === 
     55 
     56 - Ssh public keys for git access are separate from shell account, and will be managed by Gitolite admins (the initial public keys will be populated from the currently authorized shell accounts' `.ssh/authorized_keys` files) 
     57 
     58 - Developers no longer need a shell account for being able to push to git repositories; so ideally, as ghc.haskell.org hosts the critical Trac&Git resources, only *required* shell accounts should remain. 
     59 
     60 - 'ssh [email protected]' shows list of currently accessible repositories (+ respective ACLs) 
     61 
     62 - Optionally later-on: users can manage their pubkeys via "sskm" (self-service key management) 
     63 
     64== Setup (to be done by the Admins) == 
     65 
     66 - Install Gitolite 
     67   * `apt-get install Gitolite & dpkg-reconfigure` 
     68     (Debian7 ships with Gitolite version 2.3 in its main-pool); 
     69     `dpkg-reconfigure` will ask about: 
     70      - username: `git` 
     71      - HOME: `/home/git` 
     72   - Set up Gitolite's permissions (-> umask!) in such a way that Gitolite-owned repositories can only be modified by Gitolite's `git` user, and that Gitolite-owned git repositories remain world readable. 
     73   - old git-repository locations in `/home/darcs` are made symlinks to the new Gitolite-owned git repositories (which are to be moved to `/home/git/repositories` and permission-reset by Gitolite's management scripts) 
     74   - add `www-data` user to `git` group and vice versa, so that Trac and Gitolite can interact with each other. 
     75   - Git hook scripts need to be made Gitolite-friendly 
     76   - Populate Gitolite users & Ssh pubkeys from the `~/.ssh/authorized_keys` files of members of `darcs` group 
     77 
     78 - Register new CNAME `git.haskell.org` (tangential/optional) 
     79   - HTTP vhost `darcs.haskell.org` stays as-is 
     80   - new HTTP vhost `git.haskell.org` serving /home/git/repositories 
     81     (optionally enable smart git http transport); Git uris will be `http://git.haskell.org/<repo-name>` 
     82   - Cgit could be used as front-page on '/', c.f. http://www.kernel.org/ 
    5583 
    5684= Current status =