Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 15 additions & 15 deletions book/04-git-server/sections/generating-ssh-key.asc
Original file line number Diff line number Diff line change
@@ -1,13 +1,13 @@
[[_generate_ssh_key]]
=== Generating Your SSH Public Key
=== 生成你的 SSH 公钥

(((SSH keys)))
That being said, many Git servers authenticate using SSH public keys.
In order to provide a public key, each user in your system must generate one if they don't already have one.
This process is similar across all operating systems.
First, you should check to make sure you don't already have a key.
By default, a user's SSH keys are stored in that user's `~/.ssh` directory.
You can easily check to see if you have a key already by going to that directory and listing the contents:
如前所述,许多 Git 服务器使用 SSH 密钥的验证方式。
为提供密钥验证,你服务器上的每一个用户需要生成一个自己的密钥,如果他们还没有的话。
这个过程在所有操作系统上都差不多类似。
首先你要检查系统,确保你还没有一个密钥。
默认的情况下,一个用户的 SSH 密钥对应该存储在该用户的 `~/.ssh` 目录。
你可以非常容易地查看是不是已经有一个密钥对,只需进入该目录,然后列出所有文件:

[source,console]
----
Expand All @@ -17,9 +17,9 @@ authorized_keys2 id_dsa known_hosts
config id_dsa.pub
----

You're looking for a pair of files named something like `id_dsa` or `id_rsa` and a matching file with a `.pub` extension.
The `.pub` file is your public key, and the other file is your private key.
If you don't have these files (or you don't even have a `.ssh` directory), you can create them by running a program called `ssh-keygen`, which is provided with the SSH package on Linux/Mac systems and comes with the MSysGit package on Windows:
注意看这个目录中是不是有一对文件的文件名类似于 `id_dsa` `id_rsa` 以及另一个相应的 `.pub` 后缀文件。
`.pub` 文件是该用户的公钥,另外一个不带后缀的文件是对应的私钥。
如果没有这些文件(甚至干脆连 `.ssh` 目录都没有),可以通过运行 `ssh-keygen` 来生成它们。这个工具在 Linux/Mac 系统上是随 SSH 包一起提供的,Windows 系统上则是随着 MSysGit 包提供。

[source,console]
----
Expand All @@ -35,11 +35,11 @@ The key fingerprint is:
d0:82:24:8e:d7:f1:bb:9b:33:53:96:93:49:da:9b:e3 [email protected]
----

First it confirms where you want to save the key (`.ssh/id_rsa`), and then it asks twice for a passphrase, which you can leave empty if you don't want to type a password when you use the key.
最开始它会跟你确认保存密钥的位置(`.ssh/id_rsa`),之后需要输入两次密码。如果不想在之后使用密钥的时候输入密码,你也可以在这留空。

Now, each user that does this has to send their public key to you or whoever is administrating the Git server (assuming you're using an SSH server setup that requires public keys).
All they have to do is copy the contents of the `.pub` file and e-mail it.
The public keys look something like this:
现在,每一个完成这个操作的用户需要把他的公钥发送给你或者 Git 服务器的管理员(假设你使用的 SSH 服务器要求公钥)。
他们只需将 `.pub` 文件里的内容复制到邮件中发送。
公钥的形式应该如下:

[source,console]
----
Expand All @@ -52,4 +52,4 @@ mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== [email protected]
----

For a more in-depth tutorial on creating an SSH key on multiple operating systems, see the GitHub guide on SSH keys at https://help.github.com/articles/generating-ssh-keys[].
关于怎么在更多操作系统上生成 SSH 密钥的详细教程,请参见 GitHub 指南中 SSH 密钥的介绍:https://help.github.com/articles/generating-ssh-keys[]
38 changes: 19 additions & 19 deletions book/04-git-server/sections/git-daemon.asc
Original file line number Diff line number Diff line change
@@ -1,32 +1,32 @@
=== Git Daemon
=== Git 守护进程

(((serving repositories, git protocol)))
Next we'll set up a daemon serving repositories over the ``Git'' protocol. This is common choice for fast, unauthenticated access to your Git data. Remember that since it's not an authenticated service, anything you serve over this protocol is public within it's network.
接下来我们要配置一个守护进程来提供基于 ``Git'' 协议的仓库服务。这是快速、非授权地访问 Git 数据的普遍方式。记住,因为它无需授权,所以你以这种协议提供的所有数据都公开暴露在它所处的网络中。

If you're running this on a server outside your firewall, it should only be used for projects that are publicly visible to the world.
If the server you're running it on is inside your firewall, you might use it for projects that a large number of people or computers (continuous integration or build servers) have read-only access to, when you don't want to have to add an SSH key for each.
如果提供此项服务的服务器在防火墙之外,它应该只用于一些全世界范围公开的项目。
如果提供此项服务的服务器在防火墙之内,它可以用于一些被数量众多的用户或计算机(持续集成或构建服务器)只读访问的项目,这样就无需为用户逐一添加 SSH 公钥。

In any case, the Git protocol is relatively easy to set up.
Basically, you need to run this command in a daemonized manner:(((git commands, daemon)))
在任何情况下,Git 协议都是相对比较容易配置的。
基本上,只要以守护进程的形式运行该命令即可:(((git commands, daemon)))

[source,console]
----
git daemon --reuseaddr --base-path=/opt/git/ /opt/git/
----

`--reuseaddr` allows the server to restart without waiting for old connections to time out, the `--base-path` option allows people to clone projects without specifying the entire path, and the path at the end tells the Git daemon where to look for repositories to export.
If you're running a firewall, you'll also need to punch a hole in it at port 9418 on the box you're setting this up on.
这里的 `--reuseadd` 选项表示在重启服务前,不等之前的连接超时就立即重启。而 `--base-path` 选项则允许克隆项目时不必给出完整路径。最后面的路径告诉 Git 守护进程允许开放给用户访问的仓库目录。
假如有防火墙,则需要为该主机的 9418 端口设置为允许通信。

You can daemonize this process a number of ways, depending on the operating system you're running.
On an Ubuntu machine, you can use an Upstart script.
So, in the following file
以守护进程的形式运行该进程的方法有许多,具体方法取决操作系统。
Ubuntu 主机上,可以使用 Upstart 脚本完成。
因而,在下列文件中:

[source,console]
----
/etc/event.d/local-git-daemon
----

you put this script:
加入下列内容:

[source,console]
----
Expand All @@ -40,25 +40,25 @@ exec /usr/bin/git daemon \
respawn
----

For security reasons, it is strongly encouraged to have this daemon run as a user with read-only permissions to the repositories – you can easily do this by creating a new user 'git-ro' and running the daemon as them.
For the sake of simplicity we'll simply run it as the same 'git' user that Gitosis is running as.
出于安全考虑,强烈建议使用一个对仓库仅有只读权限的用户来运行该守护进程——只需新建一个 'git-ro' 用户,并用它的身份来启动进程。
这里为了简化,我们还是直接使用之前 Gitosis 运行的用户 'git'

When you restart your machine, your Git daemon will start automatically and respawn if it goes down.
To get it running without having to reboot, you can run this:
当服务器重启,Git 守护进程会自动启动;万一进程意外退出,它也会自动重启。
设置完成之后,可以通过运行下列命令来启动守护进程,无需重启:

[source,console]
----
initctl start local-git-daemon
----

On other systems, you may want to use `xinetd`, a script in your `sysvinit` system, or something else – as long as you get that command daemonized and watched somehow.
在其它操作系统上,可以使用 `xinetd` , 或一个 `sysvinit` 系统中的脚本,或其它别的什么——只要能让那个进程以守护进程运行并可监控。

Next, you have to tell Git which repositories to allow unauthenticated Git server-based access to. You can do this in each repository by creating a file name `git-daemon-export-ok`.
接下来,我们要告诉 Git 哪些仓库是可以允许通过 Git 协议进行无需授权地访问。只需在每一个仓库中逐一创建 `git-daemon-export-ok` 文件。

[source,console]
----
$ cd /path/to/project.git
$ touch git-daemon-export-ok
----

The presence of that file tells Git that it's OK to serve this project without authentication.
该文件的存在告诉 Git 可以提供对该项目的访问,而无需授权。
86 changes: 43 additions & 43 deletions book/04-git-server/sections/git-on-a-server.asc
Original file line number Diff line number Diff line change
@@ -1,18 +1,18 @@
[[_git_on_the_server]]
=== Getting Git on a Server
=== 在服务器上部署 Git

Now we'll cover setting up a Git service running these protocols on your own server.
现在我们来讲讲怎么在你自己的服务器上部署Git服务运行在之前谈到的协议之上。

[NOTE]
====
Here we'll be demonstrating the commands and steps needed to do basic, simplified installations on a Linux based server, though it's also possible to run these services on Mac or Windows servers too.
Actually setting up a production server within your infrastructure will certainly entail differences in security measures or operating system tools, but hopefully this will give you the general idea of what's involved.
接下来我们会演示一些命令和步骤。这些命令和步骤可以在 Linux 服务器上完成一个基本的简化的安装。当然这些服务也可以运行在 Mac Windows 服务器上。
事实上,在你的 IT 基础架构上搭建一个生产服务器肯定会存在一些安全措施或系统工具的不一样。但是希望本节可以给你一个笼统的概念,了解会涉及些什么。
====

In order to initially set up any Git server, you have to export an existing repository into a new bare repository – a repository that doesn't contain a working directory.
This is generally straightforward to do.
In order to clone your repository to create a new bare repository, you run the clone command with the `--bare` option.(((git commands, clone, bare)))
By convention, bare repository directories end in `.git`, like so:
为了开始搭建任何的 Git 服务器,需要导出一个已有的仓库为一个新的裸仓库——一个不包含工作目录的仓库。
步骤大体上是简单明了的。
克隆你的仓库来创建一个裸仓库,你可以运行加上 `--bare` 选项的克隆命令。(((git commands, clone, bare)))
按照惯例, 裸仓库的文件目录名以 `.git` 结束,如下:

[source,console]
----
Expand All @@ -21,40 +21,40 @@ Cloning into bare repository 'my_project.git'...
done.
----

You should now have a copy of the Git directory data in your `my_project.git` directory.
现在 `my_project.git` 目录中已经有了一份 Git 目录中数据的副本。

This is roughly equivalent to something like
上面的命令大致相当于下面的命令:

[source,console]
----
$ cp -Rf my_project/.git my_project.git
----

There are a couple of minor differences in the configuration file; but for your purpose, this is close to the same thing.
It takes the Git repository by itself, without a working directory, and creates a directory specifically for it alone.
但在配置文件中有若干小改动,不过对用户来讲,效果都差不多。
它会把 Git 仓库单独拿出来,不包括工作目录,之后再为它创建一个单独的目录存放。

[[_bare_repo]]
==== Putting the Bare Repository on a Server
==== 把裸仓库移到服务器上

Now that you have a bare copy of your repository, all you need to do is put it on a server and set up your protocols.
Let's say you've set up a server called `git.example.com` that you have SSH access to, and you want to store all your Git repositories under the `/opt/git` directory.
Assuming that `/opt/git` exists on that server, you can set up your new repository by copying your bare repository over:
既然已经有了该仓库的裸副本,你所需要做的就是把它放在服务器上,再配置好协议。
假设说,你已经搭建好了一台叫 `git.example.com` 的服务器,而且也可以 SSH 连接上去,现在想将所有的 Git 仓库存放在 `/opt/git` 目录下。
如果说 `/opt/git` 已经在那台服务器上了,你可以通过直接复制裸仓库来建立你的新仓库:

[source,console]
----
$ scp -r my_project.git [email protected]:/opt/git
----

At this point, other users who have SSH access to the same server which has read-access to the `/opt/git` directory can clone your repository by running
到这一阶段,其它可以通过 SSH 访问的用户如果也同时对 `/opt/git` 有读取权限的话,那么可以用下面的命令克隆你的仓库:

[source,console]
----
$ git clone [email protected]:/opt/git/my_project.git
----

If a user SSHs into a server and has write access to the `/opt/git/my_project.git` directory, they will also automatically have push access.
如果一个用户 SSH 登录到那台服务器,而且同时具有对 `/opt/git/my_project.git` 写入的权限,他自然也就有了推送的权限。

Git will automatically add group write permissions to a repository properly if you run the `git init` command with the `--shared` option.(((git commands, init, bare)))
如果你运行 `git init` 时加上 `--shared` 选项,Git 会自动正确地添加用户组的写入权限到该仓库。(((git commands, init, bare)))

[source,console]
----
Expand All @@ -63,38 +63,38 @@ $ cd /opt/git/my_project.git
$ git init --bare --shared
----

You see how easy it is to take a Git repository, create a bare version, and place it on a server to which you and your collaborators have SSH access.
Now you're ready to collaborate on the same project.
我们已经看到这是多么简单,只需要取出 Git 仓库,用它创建一个裸仓库,再把这个裸仓库放到你和你的合作者们有 SSH 权限的服务器上。
现在你可以开始在这项目上合作了。

It's important to note that this is literally all you need to do to run a useful Git server to which several people have access – just add SSH-able accounts on a server, and stick a bare repository somewhere that all those users have read and write access to.
You're ready to go – nothing else needed.
要着重说明一下,下面就是为了运行一个可供若干人使用的 Git 服务器所需要的全部工作——在服务器上添加 SSH 账号,把一个裸仓库放在一个所有合作者有读写权限的地方。
搞定——别的什么都不需要了。

In the next few sections, you'll see how to expand to more sophisticated setups.
This discussion will include not having to create user accounts for each user, adding public read access to repositories, setting up web UIs, using the Gitosis tool, and more.
However, keep in mind that to collaborate with a couple of people on a private project, all you _need_ is an SSH server and a bare repository.
在接下来的几节当中,你会了解到怎么样去扩展至更精细的配置。
这些讨论会包括如何避免为用户逐一建立账号,开放仓库的读取权限,配置网页交互界面,使用 Gitosis 工具等等。
然而请记住,如果是与几个人去协作一个私有项目,你所 _需要_ 的仅仅是一个 SSH 服务器和一个裸仓库。

==== Small Setups
==== 小型配置

If you're a small outfit or are just trying out Git in your organization and have only a few developers, things can be simple for you.
One of the most complicated aspects of setting up a Git server is user management.
If you want some repositories to be read-only to certain users and read/write to others, access and permissions can be a bit more difficult to arrange.
如果是一个小型机构或者只是在你的组织里尝试 Git,开发人员也不是很多,那么事情对你来说可以变得简单。
配置一个 Git 服务器最复杂的方面之一是用户管理。
如果你想实现一个仓库对特定用户只读,而对别的用户可以读写,那么设置访问方式和权限可能会有点麻烦。

===== SSH Access
===== SSH 访问

(((serving repositories, SSH)))
If you have a server to which all your developers already have SSH access, it's generally easiest to set up your first repository there, because you have to do almost no work (as we covered in the last section).
If you want more complex access control type permissions on your repositories, you can handle them with the normal filesystem permissions of the operating system your server runs.
如果已经有一个服务器,而且所有开发人员都对它有 SSH 访问权限,那么通常来说把你的第一个仓库放置在那里是最简单的。因为你几乎不用做什么 (就像我们上一节谈到的一样)。
如果想对仓库实施更复杂的访问控制类型权限,你可以通过服务器运行的操作系统的正常文件系统权限控制来处理。

If you want to place your repositories on a server that doesn't have accounts for everyone on your team whom you want to have write access, then you must set up SSH access for them.
We assume that if you have a server with which to do this, you already have an SSH server installed, and that's how you're accessing the server.
如果你想把仓库放到一个服务器上,而你的团队并不是所有人都对它有写入权限,那么你需要为没有权限的添加 SSH 权限。
我们假设你有一个服务器来做这件事,你也已经安装了 SSH 服务,而且 SSH 就是你访问服务器的方式。

There are a few ways you can give access to everyone on your team.
The first is to set up accounts for everybody, which is straightforward but can be cumbersome.
You may not want to run `adduser` and set temporary passwords for every user.
有下面几种方法来实现给你团队所有成员分配权限。
第一种就是为所有成员逐一设置账号,虽然操作很简单但是很繁重。
你可不想为每位用户都运行一遍 `adduser` 命令再设置临时密码。

A second method is to create a single 'git' user on the machine, ask every user who is to have write access to send you an SSH public key, and add that key to the `~/.ssh/authorized_keys` file of your new 'git' user.
At that point, everyone will be able to access that machine via the 'git' user.
This doesn't affect the commit data in any way – the SSH user you connect as doesn't affect the commits you've recorded.
第二种方式就是在服务器上创建一个 'git' 用户,再要求每一个需要写入权限的用户将他的 SSH 公钥发送给你,你再将公钥添加到新创建的 'git' 用户的 `~/.ssh/authorized_keys` 文件。
到这一步,所有人都可以通过 'git' 用户访问那台服务器了。
但这完全不影响提交数据——你连接的 SSH 用户不影响你的提交记录。

Another way to do it is to have your SSH server authenticate from an LDAP server or some other centralized authentication source that you may already have set up.
As long as each user can get shell access on the machine, any SSH authentication mechanism you can think of should work.
另外一种方式是让你的 SSH 服务器通过你已经部署好了的 LDAP 服务器或其它集中式的验证来源来验证。
只要每个用户都能得到服务器上 shell 的访问权限,任何你能想到的认证机制都应该能用。
Loading