Gitoite 简介与搭建教程

标签:
  • gitolite
  • git

其实，每一个Git库只需要–bare -shared就可以简单实现类似共享代码库服务器的功能，在git的世界，代码都是自由share的，每个人扮演的角色，和linux系统赋予这个用户的权限有关。但如果采用这种SSH authorized_keys的方式，直接系统通过shell进行 git clone的方法，会缺少了一项很必须的权限管理——每个用户对某个repository中所有项目均拥有完整的读写权限(可通过linux系统的权限设定，但依然麻烦)，如果在一些大项目，涉及到多种角色权限，并要指定访问路径时，直接管理authorized_keys的方式，就显得力不从心，试想一下如果你要管理超过1000号人的authorized_keys？

Gitolite，是一套用来管理 authorized_keys 文件的，为git server实现了细粒度的访问控制的perl脚本。它的官方网址是: http://github.com/sitaramc/gitolite，起先，gitolite受到gitosis的影响而开发，其命名就是gitosis+lite的意思，轻量版的gitosis，目标是打造比gitosis更人性化和更稳定的软件套件。如今，gitolite不仅早已超过它的前辈gitosis，还占据了众多大型开源社区的一席之地，由它为git server管理着代码仓库的ACL，其中包括Fedora社区(管理着超10000个仓库)、KDE社区、Gentoo社区、MeeGo社区以及Kernel.org。Gitolite进行用户管理和访问控制设定的方法，是通过管理一个指定的 Git 仓库来实现。你只需要在这个指定的仓库内做好相应的设定，然后推送到服务器上，Gitolite就会随之改变运行策略。

下面是一些特征：

  • 在服务器端，提供一个单独的unix用户
  • 提供多用户访问
    • 他们不是真正的用户
    • 它们不会获得shell权限
  • 控制对多个git仓库的访问
    • 真正的读访问被repo层控制
    • 写访问在branch/tag/file/directory层控制，包括谁能够rewind，create以及delete branches/tags
  • 能够不经过root允许进行安装，假设git和perl已经被安装了
  • 访问认证通常采用sshd，但是也可以使用httpt

它是怎样工作的

gitolite 依赖 sshd 给用户授权并提供用户名;基于此选择是否接受用户的请求。 考虑ssh模式下push命令，正常情况下（未安装gitolite）服务端会调用’git-receive-pack’,工作流如下图所示（左边的是客户端，右边的是服务端）

当你安装完gitolite并设置好用户后，gitolite-shell接管直接的命令请求方式。 ‘git-shell’程序使用ssh提供的用户名和在命令中指定的git仓库来决定用户是否有写入库的权利. 如果用户有写入的权利，git-receive-pack会触发，但这还没完，用户写入的分支/标签/文件需要被检查，gitolite 在库上设置了修改的钩子程序。如下图所示：

gitolite-admin 仓库

gitolite 通过gitolite-admin这个特殊的库来做管理git库的工作，包括但不限于管理用户，授权。 大部分的日常管理工作可能通过克隆这个库，做一些配置方面的修改，然后提交到服务器端就可以了。 特别的，库中包含”keydir”文件夹，里面是管理员和相关的用户公钥文件。 其次是”conf/gitolite.conf”配置文件，你可以在文件中设置权限规则。

一个简单的例子：

# these lines were already in the file
repo foo
    RW+     =   alice
    RW      =   bob

# these lines were added just now
repo bar
    RW+     =   bob
    R       =   alice

当这个文件提交到服务器时，会发生什么呢，如下所示： 1. git-receive-pack会调用gitolite-admin库中的’post-update’钩子程序。 2. Gitolite 检查keydir中公钥文件，同时用这些公钥来修改ssh的授权文件，让ssh知道哪些是合法的用户。 3. 更新~/.gitolite的一些中间文件。 4. 一些在conf/gitolite.conf中提及的库，但~/repositories中不存在，则创建之 5. 为每一个库更新与权限相关的文件。

在开始之前

  1. 安装gitolite后，你将是系统管理员，需要熟悉ssh.
  2. 熟悉git.
  3. Unix shell.
  4. 一些简单的正则表达式，有助你更好设置管理规则.

服务器端

  • Unix 系统.
  • Git 版本在1.6.6以上.
  • Perl在5.8.8以上.
  • Openssh.
  • 通常，gitolite运行在一个用户不能直接访问的主机上，你采用其他的一些用户名登录，然后使用su -git命令。 在此，没有密钥被用来获取shell访问，因此没有冲突。 另外的方法是使用两个不同的密钥，用别名来区分。

客户端

  • Openssh.
  • Git 版本在1.6.6以上.

安装准备工作

以mac环境安装gitolite为例. 假设服务器名称为gitbox. 1. 在本地用ssh-keygen生成会话钥匙

 ssh-keygen -t rsa -f id_rsa
  1. 将公钥上传到服务器~/.ssh/目录下
 ssh-copy-id -i ~/.ssh/id_rsa.pub git@gitbox
  1. 以git身份登陆服务器
 ssh git@gitbox

如果git用户不存在，则需要以管理员的身份登陆到gitbox ,并添加git用户.

sudo adduser --system --shell /bin/bash --group git
sudo adduser git ssh
udo adduser git sudo

  1. 确保 ~/.ssh/authorized_keys 是空的或者不存在

  2. 将之前上传的id_rsa.pub copy 到 $HOME/alice.pub

 sudo cp ~/.ssh/git_rsa.pub $HOME/alice.pub

接下来，就可以用下面的命令安装了。

git clone git://github.com/sitaramc/gitolite
mkdir -p $HOME/bin
gitolite/install -to $HOME/bin

最后，设置你自己为管理员 $HOME/bin/gitolite setup -pk alice.pub

在客户端管理用户与库

  1. 运行git clone git@gitbox:gitolite-admin.
  2. 用各种渠道收集协作开发队员的公用钥，并改名copy到keydir/目录下。
  3. 然后 git add keydir; git commit; git push;

具体如图所示：

编辑配置文件

编辑conf/gitolite.conf

例子如下：

# sample conf/gitolite.conf file

@staff              =   dilbert alice           # groups
@projects           =   foo bar

repo @projects baz                              # repos
    RW+             =   @staff                  # rules
    -       master  =   ashok
    RW              =   ashok
    R               =   wally

    option deny-rules           =   1           # options
		    config hooks.emailprefix    = '[%GL_REPO] ' # git-config

上面的例子定义了开发团队，项目组，并为开发团队，队员，进行了详细的授权。

repo foo bar
    RW+                     =   alice @teamleads
    -   master              =   dilbert @devteam
    -   refs/tags/v[0-9]    =   dilbert @devteam
    RW+ dev/                =   dilbert @devteam
    RW                      =   dilbert @devteam
    R                       =   @managers

  • alice and the team leads can do whatever they want (i.e., push, rewind, or delete any branch or tag).

  • dilbert and the dev team has these restrictions
    1. they can do anything to branches whose names start with “dev/”
    2. they can create or fast-forward push, but not rewind or delete, any branch except master
    3. they can create (but not update/delete) any tag except tags starting with “v” followed by a digit.
  • managers can read the repo but they can’t push anything.

基本语法

  • 通常来说，所有的元素都是用空格隔开的；没有逗号，分号，以及其他的东西。
  • 注释通常用shell的样式，#
  • 用户名和repo名字一样，它们都以字母开始，但是可以用点，下划线，减号连接
  • 用户名可以选择用@符号后面跟一个至少包含一个点号的域名
  • 组名与用户名类似，以@开头
  • repo的名字里可以包含/符号
  • 默认没有续行的功能，你不需要它们。

权限规则说明

  • R, to allow read operations only
  • RW, to allow fast-forward push of a branch, or create new branch/tag
  • RW+, to allow pretty much anything – fast-forward, rewind or delete branches or tags
  • ”-“ (the minus sign), to deny access.
返回首页 04 November 2014

Projects by heyi can be found on GitHub