最近一个客户聘请了一个网络开发团队来帮助他的工作过度的网管。他们要求我安装一个版本控制系统，这个系统能够保证团队中的任何成员避免无意中修改别人的文件，并且能够给予管理员恢复文件到任何版本的机制。

我的第一个想法就是Subversion。因为它是我写BSD Hacks 时和编辑器一起用的版本控制系统。在Ports Collection中搜索一下之后发现，Subversion需要好几个相关的port。比如，esvn看起来相当适合客户端，因为它的GUI终端能够运行在Unix,Mac OS X以及Windows中。对于一个对Unix技术掌握不深的网络开发团队而言，当他们需要把数据存贮在FreeBSD服务器上而从非FreeBSD系统读取时，esvn是非常好的选择。

前期准备

在我的想法中，只允许开发团队的成员具有权限访问仓库是非常重要的。同时，我们把仓库放在和目前的web服务器分开的操作系统上，当web管理员看到适合的文件时，由他负责把文件从仓库复制到web服务器上。

为了实现这个目的，先对已存在的你想放到版本控制系统下的目录结构做一个备份，然后把它安全发送到仓库服务器。在我的例子中，我把web服务器上www目录的数据备份到一台内网服务器 192.168.2.2上。

# tar czvf - /usr/local/etc/www/data | ssh dru@192.168.2.2 "cat > www.tar.gz"

下一步是在仓库服务器上建立一个svn组，并把已存在的需要访问仓库的用户加到这个组中。比如，当我创建svn组后，我在/etc/group加入这句话把已存在的web管理员用户加进去：

# vi /etc/group
svn:*:3690:webadmin

然后，新建一个用户svn。如果有必要，你还需创建所有要访问仓库系统的用户帐号(如果他们还没有创建）。要保证每个用户是svn的成员并且有密码和可用的shell。我使用sysinstall为新的网络工程师建立用户帐号。完成以后，我双击svn组的成员。大概就象这样：

# grep svn /etc/group
svn:*:3690:webadmin,devel1,devel2

处理 umask

在安装Subversion之前，我们先看看svn用户的umask。在我的FreeBSD系统上，它是这样的：

# su -l svn
% umask
022

在UNIX中，用户umask值决定了新建目录或文件的默认权限。这是通过关闭某些权限达到的。如果你记得：

r = 4
w = 2
x = 1

你应该看得出这个umask没有对用户(svn)关闭任何权限(0);它对组(svn)关闭了写权限(2);它对其他组用户关闭了写权限(2)。

因为svn组的成员必须能够写入仓库，所以把umask中关于组的 2 改为 0。甚至如果你不想让其他组成员知道这个仓库的存在，你可以把关于其他组成员的 2 改为 7。

修改用户svn的shell配置比较简单。如果用户使用 csh:

% vi ~svn/.cshrc

，那么找到umask那行并把它改为 002 或 007。如果你的svn用户不用csh，修改你的shell配置文件。如果你把你的修改保存在 ~svn/.cshrc (或别的地方),别忘了告诉shell:

% source ~svn/.cshrc

再敲一次 umask 命令，以保证你的修改有效。

安装Subversion ，并让它拥有正确的umask

如果你选择一个002的umask,那么当你从ports collection生成Subversion的时候，你能把一个wrapper编译进去。如果你选择一个007的umask或安装已预编译好的Subversion，那就要创建一个wrapper脚本来保证你的Subversion二进制文件使用你的umask值。

使用wrapper编译，使其umask值为002：

# cd /usr/ports/devel/subversion
# make -DWITH_SVNSERVE_WRAPPER install clean

或者，你可以安装已预编译的二进制代码包

# pkg_add -r subversion

注意：无论使用何种方法，安装之前都应该把这篇文章看完！因为你可以发现一些额外的让你感兴趣的编译选项！

如果你不在wrapper中编译，请移动你的代码到相应的位置，并创建你自己的wrapper脚本：

# mv /usr/local/bin/svn /usr/local/bin/svn.orig
# vi /usr/local/bin/svn
#!/bin/sh
#wrapper script to set umask to 007 on subversion binaries
umask 007
/usr/local/bin/svn.orig "$@"

设置你的umask值为002或007，使它和syn用户的umask值一样。别忘了设置你的wrapper脚本为可执行的：

# chmod +x /usr/local/bin/svn

创建仓库

既然环境搭好了，那你就可以创建仓库了。用svn用户登录以保证svn用户和svn组拥有你在仓库中创建的文件。在 /usr/home/svn/目录中,键入：

% svnadmin create repository

在这个例子中，我的仓库名为repository。你可以选择任何对你有帮助的名字。svnadmin create 仅仅创建了Subversion工具所需要的目录结构。

% ls -F repository
README.txt dav/ format locks/
conf/  db/ hooks/

注意目录db是默认生成的。因为Subversion使用数据库跟踪仓库中文件的变化，所以你必须把你的数据放到数据库中。然后，我把备份文件解压缩，这样就有的一些可以放进去的数据。但是要注意这么做的时候，不要把备份文件直接恢复到~svn/repository目录下。(记得否，它是个数据库)。相反，我新建了个目录结构：

% pwd
/usr/home/svn

% mkdir www && cd www
% mkdir branches tags trunk
% cd trunk
% tar xzvf /full/path/to/www.tar.gz .
% cd

这样，svn用户的主目录结构像这样:

% ls -F ~svn
repository/ www/

导入数据

下一步，应该把~svn/www/的数据导入到Subversion服务器了。为了实现这个目的，可以使用 svn import 命令：

% svn import www file:///usr/home/svn/repository/www -m "initial import"

svn import 是svn的许多命令中用户可以使用的一条。键入 svn help 可以看到所有可以使用的命令的名字。如果你在svn和help中插入命令，比如 svn import help,你就可以看到那条命令的语法帮助。在svn import后面的是包含要导入数据的目录的名字(www)。你的数据不一定非得在相同的目录下，它仅仅是定义了到数据的完整路径，但必须保证你的svn组用户拥有访问导入数据的权限。注意：如果你已经导入的数据，原始数据就没有必要留在硬盘上了。在我的例子中，我使用了这条命令：

rm -Rf www。

接下来，请注意当我定义仓库的完整路径时所使用的语法。Subversion支持多URL模式或者RA(repository access)模块。检验你的Subversion支持哪种模式：

#svn --version
svn, version 1.1.3 (r12730)
   compiled Mar 20 2005, 11:04:16

Copyright (C) 2000-2004 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
  - handles 'http' schema
  - handles 'https' schema
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' schema
* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles svn schema

因为我想要在本地路径访问仓库，所以我使用了file:/// 模式。我还可以在这URL后面加上www，因为我想访问仓库中名为www的目录。当然，你能在同一个仓库中导入多个目录结构，并且用容易记住的名字命名。

最后，我使用了 -m 消息开关把注释："initial import"加入仓库日志中。如果我不包括这个参数，svn将使用默认编辑器(vi)打开日志并要求我填入注释，否则无法进入下一步。

这是非常关键的一个地方。安装一个版本控制系统的全部原因是为了允许许多用户修改文件，并且有可能是并发的。每一个用户都应该负责任的记录清楚他们对哪些文件作了哪些改动。你的工作就是让他们明白为什么svn命令总是提示他们加入注释。

确定如何访问仓库

恭喜你！你现在拥有了一个可以工作的仓库！现在到了仔细比较各种不同的URL模式并选出最适合你需求的访问方法的最好的时间。

免费电子文档Version Control with Subversion第六章详细介绍了各种可能的配置。你可以在编译FreeBSD port的时候,在 make 命令后添加参数 -DWITH_BOOK，把书安装上。

如果你的用户通过本地或ssh登录系统，可以使用 file:/// 访问。因为用户对于仓库时本地(local)的，所以这种情况下，系统不会打开一个 TCP/IP端口监听Subversion连接。然而，它却要求每个用户有一个活动的shell帐号并且假定你的用户可以登录Unix服务器。和别的shell帐户一样，其安全性能由这几方面决定：用户密码的健壮性；仓库权限以及组成员的正确配置。让用户通过ssh登录系统并不保证session已被加密。

另一种方案是把Subversion整合进apache服务器。默认情况下，Subversion 的FrssBSD port支持SSL编译，这意味着你的用户可以在浏览器中使用 https:// 模式访问仓库。然而，如果你的apache版本是2.X而不是1.X，要记得在编译的时候把参数-DWITH_MOD_DAV_SVN 加入到 make后面。

如果你考虑让用户通过浏览器访问，要先仔细阅读Subversion文档关于apahce httpd配置部分，然后你要配置不少东西。幸运的是，文档很完整！

第三种方案时使用 svnserve 监听网络连接。文档建议采用这种模式，无论是通过inetd还是独立进程。这
种模式允许匿名访问或者已授权的用户访问，任何方式都通过CRAM-MD5加密。客户通过svn:// 访问svnserve。

我认为匿名访问是不恰当的，所以我依照配置选项使用CRAM-MD5。然而，我很快发现我的系统上没有安装CRAM-MD5。在Google上搜索关于把CRAM-MD5整合进Subversion服务器的资料，但是没有找到。我就决定尝试最后一种方法。

那就是在“隧道模式(tunnel mode)”中调用svnserve,这种模式可以让你的用户除了受你在/etc/ssh/sshd_config中的配置约束外，还可以通过正常的SSH机制认证。比如，我可以使用AllowUsers关键字控制哪些用户授权访问系统。注意，这种模式使用svn+ssh://访问仓库。

这种方法的好处是我可以使用已有的认证体制而不需要用户必须是仓库系统帐户。然而，这种模式中的网络连接是没有加密的；使用SSH只是为了授权。如果你的数据是敏感的，那么你应该让你的用户通过ssh登录后使用file:// 访问，或者使用https:// 访问，不过必须正确配置好Apache。

如果你决定使用svnserve服务器并且在wrapper中编译，它将生成一个名为svnserve.bin的二进制文件。你必须这么做用户才能访问仓库：

# cp /usr/local/bin/svnserve.bin /usr/local/bin/svnserve

因为它是Subversion服务器的一部分。在下一期专栏中，我将介绍如何客户端如何访问仓库。

Dru Lavigne 是渥太华Marketbridge Technologies 的讲师和Open Protocol Resource的维护人员。

Recently a client hired a team of web developers to assist his overworked web administrator. They asked me to set up a revision-control system to ensure that no one on the team inadvertently overwrote another member's work and to give the administrator the flexibility of rolling back to any version of a file.

My first thought was Subversion, as it is the revisioning system used with my editor when writing BSD Hacks A search for subversion in the Ports Collection indicated that there are also several related ports. For example, esvn looked like an excellent match for the client, as this GUI front end works from Unix, Mac OS X, and Windows. That's perfect for a web development team short on Unix skills who would be accessing data stored on a FreeBSD server from non-FreeBSD operating systems.

This week's article demonstrates how to create a secure repository using Subversion. The next installment will show how to train your users to access the repository using a GUI client.

Preparing the System

In my scenario, it was important that only the members of the development team have access to the repository. We also chose to have the repository on a system separate from the actual web server and left it up to the web administrator to copy over files from the repository to the web server as he saw fit.

To accomplish this, start by creating a backup of the existing directory structure you wish to put under revision control, and send it securely to the repository server. In my case, I backed up the www data on the web server to an internal server at 192.168.2.2.

# tar czvf - /usr/local/etc/www/data | ssh dru@192.168.2.2 "cat > www.tar.gz"

Next, on the repository system, create a new group called svn and add to it any existing user accounts that need access to the repository. For example, I added my existing web administrator as I created the group by adding this line to /etc/group:

# vi /etc/group
svn:*:3690:webadmin

Then, create a new user called svn and, if necessary, any missing user accounts that need access to the repository. Make sure each account is a member of the svn group and has a password and a valid shell. I used sysinstall to create user accounts for the new web developers. When I finished, I double-checked the membership of the svn group. It looked something like this:

# grep svn /etc/group
svn:*:3690:webadmin,devel1,devel2

Dealing with umask

Before installing Subversion, take a close look at the existing umask for the svn user. On my FreeBSD system it was:

# su -l svn
% umask
022

In Unix, the umask value determines the default permissions of a newly created directory or file. It does this by defining which permissions to disable. If you remember:

r = 4
w = 2
x = 1

you'll see that this umask doesn't turn off any (0) permissions for the user (svn); it turns off write (2) for the group (svn); and it turns off write (2) for world.

Because the members of the svn group should be able to write to the repository, change that group 2 to a 0. If you don't want nongroup members even to be aware of the existence of the repository, also change the world 2 to a 7.

The easy part is changing the umask for the svn user's shell. If it uses csh:

% vi ~svn/.cshrc

then find the existing umask line and change it to either 002 or 007.

If your svn user has a shell other than csh, make your edit in your chosen shell's configuration file.

Once you've saved your changes to ~svn/.cshrc (or wherever), don't forget to tell the shell:

% source ~svn/.cshrc

Repeat the umask command to verify that your changes have taken place.

Installing Subversion with the correct umask

If you chose a umask of 002, you can compile a wrapper into Subversion when you build it from the ports collection. If you chose a umask of 007 or prefer to install the precompiled version of Subversion, create a wrapper script to ensure that the Subversion binaries use your umask value.

To compile in a wrapper that sets a umask of 002:

# cd /usr/ports/devel/subversion
# make -DWITH_SVNSERVE_WRAPPER install clean

Alternatively, to install the precompiled binary:

# pkg_add -r subversion

Note: before installing by either method, finish reading the article. You may find some additional compile options that interest you.

If you didn't compile in your wrapper, move your existing binary and create your own wrapper script:

# mv /usr/local/bin/svn /usr/local/bin/svn.orig

# vi /usr/local/bin/svn
#!/bin/sh
#wrapper script to set umask to 007 on subversion binaries
umask 007
/usr/local/bin/svn.orig "$@"

Set your umask to either 002 or 007 so that it is the same as the umask for your svn user.

Don't forget to make your wrapper script executable:

# chmod +x /usr/local/bin/svn

Creating the Repository

Now that your environment is set up properly, you're ready to create the repository itself. Log in as the user svn to ensure that both the svn user and the svn group own the files you create in the repository. From /usr/home/svn/, type:

% svnadmin create repository

In this example, I've called my repository repository. You can choose any name that is useful to you.

svnadmin create simply creates the directory infrastructure required by the Subversion tools:

% ls -F repository
README.txt	dav/	format	locks/
conf/		db/	hooks/

Notice that db directory? By default, Subversion uses databases to track changes to the files that you place under revision control. This means that you must import your data into those databases.

At that point, I untarred my backup so that I had some data to import. If you do this, don't restore directly into the ~svn/repository directory. (It's a database, remember?) Instead, I first made a new directory structure:

% pwd
/usr/home/svn

% mkdir www && cd www
% mkdir branches tags trunk
% cd trunk
% tar xzvf /full/path/to/www.tar.gz .
% cd

That made the svn user's home directory look like:

% ls -F ~svn
repository/	www/

Importing the Data

Next, it's time to import the information from ~svn/www/ into the Subversion databases. To do so, use the svn import command:

% svn import www file:///usr/home/svn/repository/www -m "initial import"

svn import is one of many svn commands available to users. Type svn help to see the names of all the available commands. If you insert one of those commands between svn and help, as in svn import help, you'll receive help on the syntax for that specified command.

After svn import, specify the name of the directory containing the data to import (www). Your data doesn't have to be in the same directory; simply specify the full path to the data, but ensure that your svn user has permission to access the data you wish to import. Note: once you've successfully imported your data, you don't have to keep an original copy on disk. In my case, I issued the command rm -Rf www.

Next, notice the syntax I used when specifying the full path to the repository. Subversion supports multiple URL schemas or "repository access" RA modules. Verify which schemas your svn supports with:

% svn --version
svn, version 1.1.3 (r12730)
   compiled Mar 20 2005, 11:04:16

Copyright (C) 2000-2004 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
  - handles 'http' schema
  - handles 'https' schema
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' schema
* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles svn schema

Because I wished to access the repository on the local disk, I used the file:/// schema. I also appended www at the very end of the URL, as I wish that particular part of the repository to be available by that name. Yes, you can import multiple directory structures into the same Subversion repository, so give each one a name that is easy for you and your users to remember.

Finally, I used the -m message switch to append the comment "initial import" to the repository log. If I hadn't included this switch, svn would have opened the log for me in the user's default editor (vi) and asked me to add a comment before continuing.

This is a very important point. The whole reason to install a revision control system is to allow multiple users to modify files, possibly even simultaneously. It's up to each user to log clearly which changes they made to which files. It's your job to make your users aware of the importance of adding useful comments whenever an svn command prompts them to do so.

Deciding Upon a URL Schema

Congratulations! You now have a working repository. Now's the best time to take a closer look at the various URL schemas and choose the access method that best suits your needs.

Chapter 6 of the freely available e-book Version Control with Subversion gives details about the possible configurations. You can choose to install the book when you compile the FreeBSD port by adding -DWITH_BOOK to your make command.

If all of your users log in to the system either locally or through ssh, use the file:/// schema. Because users are "local" to the repository, this scenario doesn't open a TCP/IP port to listen for Subversion connections. However, it does require an active shell account for each user and assumes that your users are comfortable logging in to a Unix server. As with any shell account, your security depends upon your users choosing good passwords and you setting up repository permissions and group memberships correctly. Having users ssh to the system does ensure that they have encrypted sessions.

Another possibility is to integrate Subversion into an existing Apache server. By default, the FreeBSD port of Subversion compiles in SSL support, meaning your users can have the ability to access your repository securely from their browsers using the https:// schema. However, if you're running Apache 2.x instead of Apache 1.x, remember to pass the -DWITH_MOD_DAV_SVN option to make when you compile your FreeBSD port.

If you're considering giving browser access to your users, read carefully through the Apache httpd configuration section of the Subversion book first. You'll have to go through a fair bit of configuration; fortunately, the documentation is complete.

A third approach is to use svnserve to listen for network connections. The book suggests running this process either through inetd or as a stand-alone daemon. Both of these approaches allow either anonymous access or access once the system has authorized a user using CRAM-MD5. Clients connect to svnserve using the svn:// schema.

Anonymous access wasn't appropriate in my scenario, so I followed the configuration options for CRAM-MD5. However, I quickly discovered that CRAM-MD5 wasn't on my FreeBSD system. When a Google search failed to find a technique for integrating CRAM-MD5 with my Subversion binary, I decided to try the last option.

This was to invoke svnserve in tunnel mode, which allows user authentication through the normal SSH mechanism as well as any restrictions you have placed in your /etc/ssh/sshd_config file. For example, I could use the AllowUsers keyword to control which users can authenticate to the system. Note that this schema uses svn+ssh://.

The appeal of this method is that I could use an existing authentication scheme without forcing the user to actually be "on" the repository system. However, this network connection is unencrypted; the use of SSH is only to authenticate. If your data is sensitive, either have your users use file:// after sshing in or use https:// after you've properly configured Apache.

If you decide to use the svnserve server and you compiled in the wrapper, it created a binary called svnserve.bin. Users won't be able to access the repository until:

# cp /usr/local/bin/svnserve.bin /usr/local/bin/svnserve

That's it for this installment. In the next column, I'll show how to start accessing the repository as a client.

Dru Lavigne is an instructor at Marketbridge Technologies in Ottawa and the maintainer of the Open Protocol Resource.