Subversion был разработан с использованием абстрактного сетевого уровня. Это означает, что на программном уровне для доступа к хранилищу может быть использован любой тип сервера, а «клиентский API для доступа к хранилищу» дает программистам возможность создавать плагины, которые будут взаимодействовать с соответствующим сетевым протоколом. Теоретически, Subversion может использовать неограниченное количество сетевых реализаций. Практически же, на данный момент есть только два сервера.
Apache — наиболее популярный web-сервер; при использовании модуля mod_dav_svn Apache получает возможность доступа к хранилищу, а так же делает его доступным для клиентов, используя протокол WebDAV/DeltaV, который является расширением HTTP. В другом углу ринга — svnserve — небольшой, самостоятельный сервер, использующий для связи с клиентами собственный протокол. В Таблица 6.1, «Сравнение серверов» дано сравнение этих двух серверов.
Таблица 6.1. Сравнение серверов
| Возможность | Apache + mod_dav_svn | svnserve |
|---|---|---|
| Настройки установления личности | стандартное установление личности средствами HTTP(S), сертификаты X.509, LDAP, NTLM, а также другие механизмы, доступные для использования в Apache | CRAM-MD5 или SSH |
| Настройки пользовательских учетных записей | внутренний файл 'users' | внутренний файл 'users' или использование существующих системных (SSH) учетных записей |
| Настройки прав доступа | доступ на чтение/запись устанавливается сразу на всё хранилище, или настраивается по-каталогово | доступ на чтение/запись устанавливается сразу на всё хранилище, или настраивается по-каталогово |
| Шифрование | через SSL (опционально) | через SSH-туннель (опционально) |
| Ведение журнала | полноценный журнал Apache с записями о каждом HTTP запросе, с возможностью «высокоуровневого» учета любых операций клиента | нет журнала |
| Интероперабельность | частично, используя другие WevDAV-клиенты | только для svn клиентов |
| Просмотр через веб | ограниченная встроенная поддержка, или использование программ сторонних разработчиков, таких, как ViewVS | только при помощи программ сторонних разработчиков, таких, как ViewVS |
| Скорость | более низкая | более высокая |
| Начальная установка | несколько сложная | достаточно простая |
Установите и настройте сервер Apache 2.0, затем активируйте модуль сервера subversion. Клиенты будут обращаться к серверу через HTTP или HTTPS, используя протокол WebDAV.
Subversion может использовать любой из механизмов аутентификации, интегрированный в Apache.
Нет нужды создавать учётные записи на сервере.
Ведение логов средствами Apache.
Возможность шифровать трафик с помощью SSL.
Если компьютер или сеть защищены брандмауэром, порты HTTP(S) обычно открыты.
Встроенный просмотр хранилища через веб-обозреватель.
Хранилище может быть смонтировано как сетевой диск. (Смотрите «Autoversioning».)
Скорость заметно ниже, чем при использовании svnserve.
Первичная настройка более комплексная.
"Лёгкий" процесс, который может работать как самостоятельно, так и "по вызову" inetd. Аутентификация происходит по алгоритму CRAM-MD5. Используется свой протокол.
Быстрая и лёгкая установка.
Сетевой протокол более продвинутый и работает ощутимо быстрее, чем WebDAV.
Нет необходимости создавать на сервере дополнительные учётные записи.
Пароль не передаётся по сети.
Протокол не поддерживает шифрование.
Доступен только один метод аутентификации.
Пароль хранится на сервере открытым текстом.
Логи не ведутся, даже лог ошибок.
Клиент подключается к серверу с помощью SSH, используя системную учётную запись. При этом на сервере запускается временный процесс svnserve. Он работает с хранилищем, обменивается данными с клиентом через SSH-туннель, после чего, при закрытии SSH-сессии, завершается. (При этом методе в системе не будет постоянно запущенных процессов svnserve).
Используемый stateful-протокол значительно быстрее, чем WebDAV.
Удобство использования существующих учётных записей и пользовательской инфраструктуры.
Весь сетевой траффик шифруется.
Выбор одного метода идентификации
Журнал не ведется вообще, даже записи об ошибках.
Требует от пользователей принадлежности к одной группе или использования общего ключа ssh.
Может привести к проблемам с правами.
Итак, какой сервер лучше использовать? Какой из них лучше?
Конечно, на этот вопрос нет точного ответа. Каждая команда имеет свои потребности, и каждый сервер предоставляет свой набор возможностей. Сам проект Subversion не предпочитает какой-то один сервер и не представляет один из них как более «официальный».
Для небольшой команды, которая хочет начать использовать сервер Subversion, авторы этой книги рекомендуют простую установку svnserve; он прост в настройке и требует минимальных усилий на поддержку. Помните, что вы всегда можете перейти на более комплексное решение, когда ваши потребности вырастут.
Вот несколько общих рекомендаций, основанных на многолетнем опыте поддержки пользователей:
If you're trying to set up the simplest possible server for your group, then a vanilla svnserve installation is the easiest, fastest route. Note, however, that your repository data will be transmitted in the clear over the network. If your deployment is entirely within your company's LAN or VPN, this isn't an issue. If the repository is exposed to the wide-open internet, then you might want to make sure the repository's contents aren't sensitive (e.g. it contains only open-source code.)
If you need to integrate with existing identity systems (LDAP, Active Directory, NTLM, X.509, etc.), then an Apache-based server is your only real option. Similarly, if you absolutely need server-side logs of either server errors or client activities, then an Apache-based server is required.
If you've decided to use either Apache or stock
svnserve, create a
single svn user on your system, and
run either Apache or svnserve as that user. Be sure to
make the repository directory wholly owned by
the svn user as well. These keeps the
repository data nicely siloed and protected by operating
system filesystem permissions, changeable by only the
Subverion server process itself.
If you have an existing infrastructure heavily based on SSH accounts, and if your users already have system accounts on your server machine, then it makes sense to deploy an svnserve-over-ssh solution. Otherwise, we don't recommend this option to the general public. It's generally considered safer to have your users access the repository via (imaginary) accounts managed by svnserve or Apache, rather than by full-blown system accounts. If your deep desire for encrypted communication still draws you to this option, we recommend using Apache with SSL instead.
Do not be seduced by the simple
idea of having all of your users access a repository
directly via file:/// URLs. Even if
the repository is readily available to everyone via
network share, this is a bad idea. It removes any layers
of protection between the users and the repository: users
can accidentally (or intentionally) corrupt the repository
database, it becomes hard to take the repository 'offline'
for inspection or upgrade, and it can lead to a mess of
file-permissions problems (see
«Supporting Multiple Repository Access Methods».) Note
that this is also one of the reasons we warn against
accessing repositories via svn+ssh://
URLs — from a security standpoint, it's effectively
the same as local users accessing
via file:///, and can entail all the
same problems if the administrator isn't careful.)