LDAP + Gerrit搭建code review系统（一） --- 简介

Gerrit是针对git的一款基于web的code review工具。最早在google的android项目上提出，现在已应用于绝大多数开源开发系统，它的特点是提交前review，也就是说只有经过review的可靠代码才会被自动merge到正式的代码库中。

在下面的两幅图中，左边的图演示通常情况下git用户的使用流程：不管是开发人员还是CI机器，都是以用户的身份从git server上fetch最新代码或者向git server push本地的最新更新。右边的图演示使用了Gerrit的工作流程：Gerrit中控制着两部分数据，一部分是Authoritative Repository，代表正式的代码库，另一部分Pending Changes代表所有用户提交上来但是还未经review通过的代码。这时有了一个新的角色reviewer，通常是某个developer，也可以是架构师或专家，他从gerrit上fetch这些change，并进行review，一旦review通过，这些change就会自动submit到正式的代码库中。相对于左图而言，git用户从gerrit上获取代码时取的是可靠的，经过review的正式版本库，但是向server上推送本地的更新时，必须要在change list上排队等待review。

做为一个code review工具，在gerrit上进行的所有操作的基础就是身份辨识，也就是说gerrit可以确认当前的登录用户是张三而不是李四，这样才能知道该用户属于哪个项目组，能不能review别人的代码等等。可是，gerrit自己没有这样的认证模块，必须要依赖于第三方的认证结果。目前gerrit可接受的认证源有六种：openid, http, http_ldap, ldap, ldap_bind, 和development_become_any_account。下面逐一介绍这些认证源：

1. Openid：指的是公共账号，比如你在Google或者Yahoo上建立的账号。用户通过OpenID认证源的认证后，gerrit会自动从认证源获取相关属性如用户全名和邮件地址等信息创建账号。当然，任何人都可以为自己创建一个Google或者Yahoo账号，因此OpenID模式支持用户自建账号，适用于开源项目，不适用与相对封闭的公司使用。
2. http：Gerrit可以配置成运行在一个第三方的web server后面，比如最常用的apache。用户登录apache时输入用户名和密码，一旦验证成功，系统重定向到gerrit进行后面的操作。
3. http_ldap: 从第三方web server里登录，但是用户名和密码的验证是通过LDAP Server。这和下面的ldap认证有什么区别呢？为什么会有人多此一举要从web server登录，直接在gerrit里做ldap认证不是更方便？这是因为有些系统会需要这样的架构。比如说SSO（Single Sign-On），也就是用户只需要登录验证身份一次就可以访问多个应用程序（包括gerrit），在apache里可以做SSO，但是gerrit不提供这个功能。
4. ldap: 通过LDAP server进行身份认证，后面会做详细介绍。
5. ldap_bind: 类似ldap，不同的是登录的用户名必须使用完整的ldap账户名称，而在ldap方式中，会先以匿名或者config文件里[ldap.username]的身份查找匹配的用户，并进一步获取完整的用户名信息。
6. development_become_any_account: 故名思意，就是不需要身份认证，每个登录者都是匿名登录，用在gerrit的开发或者演示的时候。

面对如此多的认证方式，应该采用哪种呢？网上讨论最多的是http的方式。这种方式听上去很好实现，只要搭个apache server就行了，而且很多服务器上本身就有apache server在执行其他的网页访问服务，多整合一个gerrit不是很好么？做为一个在apache反向代理方式上挣扎了两周最后以失败告终的过来人，我要说这种配置方式其实很复杂，必须深入了解各个配置参数的含义，而且http认证方式登录之后很难退出也是众所周知的问题。如果你已经成功配置好了http的认证方式，你也不需要再看我这篇搭配ldap server配置的文章了。

下面来看LDAP，全称Lightweight Directory Access Protocol，在网络上获取和维护distributed directory information service的协议。在功能上和关系数据库比较类似，用于组织和存储任意类型的信息，通常用于集中式地身份认证。这里的directory不是操作系统上的目录，而是信息的目录。比如，一个telephone directory就是一个用户名和地址电话的列表，再比如DNS directory就是域名和对应的IP地址的列表。Directory在这里的意思更接近于某种类型的数据列表。该协议提供这样的一个接口模型：一个entry由一组属性（attribute）组成；每个attribute都有一个name和若干个value，所有的attribute都定义在一个schema中；每个entry都有一个唯一的DN(Distinguished Name)。看下面的例子：

dn: cn=John Doe,dc=example,dc=comcn: John DoegivenName: Johnsn: DoetelephoneNumber: [phone]telephoneNumber: [phone]mail: [e-mail]: cn=Barbara Doe,dc=example,dc=comobjectClass: inetOrgPersonobjectClass: organizationalPersonobjectClass: personobjectClass: top

“dn”是这条directory entry的辨识名（distinguished name）。“cn=John Doe”是RDN(Relative DN)，“dc=example, dc=com”是parent entry的DN，“dc”代表Domain Component。其它行显示的是本条entry的属性(attribute)值。