PavelSergeev пишет:

> По состоянию на сегодня(12.02.05) желание оплатить это дело выразили:
> Александр Лубягин
> Влад Тушевский
> Станислав Круподёров
> Екатерина Пестова
>
> Да, пятерых не набралось :-/, может кто ещё хочет присодиниться?
Я пятый! Просто письмо написать написал, а отправить забыл :(

Очередное сборище linuxового народа состоится на Театральной площади у
остатков сцены в ПЯТНИЦУ (18 февраля) в 18.00. Приглашаются все желающие.

P.S. Кто может опоздать - предупредите заранее - на сколько, чтобы мы
вас подождали.

Кто просил уточнить где будет linuxовка - я еще не знаю...
Ваня, что скажешь?

Настройка системы контроля версий Subversion

полная версия на http://kirov.lug.ru/wiki/UstanovkaSubversion

Первичная настройка

Для начала создадим пользователя "subversion", от имени
которого и будет происходить работа с репозиторием. Конечно,
для работы с репозиторием будут допущены и другие пользователи
- их идентификация будет просиходить через сервер Subversion
или Apache. А пользователь "subversion" будет владельцем
каталога с репозиторием.

# /usr/sbin/groupadd -r -f subversion
# /usr/sbin/useradd -r -g subversion -d /var/www/subversion \
-s /dev/null -c 'Subversion' subversion

Теперь создадим непосредственно сам каталог, в котором будет
находится репозитарий.

# mkdir /var/www/subversion

Сгенерируем репозиторий:

# svnadmin create /var/www/subversion

Т.к. мы работали от пользователя "root", то сменим владельца
каталога с репозитрием на "subversion":

# chown -R subversion:subversion /var/www/subversion

На этом первичную настройку можно, считать завершенной -
приступим к настройке работы сервера.

Собственный Subversion сервер - svnserve

Если нет желания возиться с настройкой связки Apache
и Subversion, которую я считаю более правильной для работы
с данной системой контроля версий, то можно воспользоваться
собственным сервером - svnserve. Он в использовании
не настолько удобнен и гибкок, но вполне достаточен
для выполнения обычных для разработика задач.

svnserve можно запустить как обычный демон, тогда он будет
находиться постоянно в памяти и ждать запростов
от пользователей. Постоянно занимать память - не совсем
удобно, учитывая, что большая часть разработки все же будет
происходить на компьютере пользователя (написание нового кода
и исправление ошибок), поэтому воспользуемся возможностью
запускать svnserve через демон xinetd - он слушает порт,
на который могут прийти запросы к svnserve и <<поднимает>>
его для обработки пришедших запросов. Чем же тогда xinetd
лучше svnserve? Тем что через этот демон может работать
не только svnserve, но и другие сервисы на компьютере:
FTP-сервер, POP3-сервер и др.

Итак, нужно убедиться, что в /etc/services есть строки,
описывающие <<обычный>> порт, на котором слушает svnserve.
Если их нет, то добавим:

svn 3690/tcp # Subversion
svn 3690/udp # Subversion
Сейчас создадим в каталоге /etc/xinet.d/ файл svn - файл
описания сервиса.

svn # default: off
# description: Server for the 'svn' repository access method. \
# Subversion is a free/open-source version control system.
service svn
{
disable = no
socket_type = stream
wait = no
user = subversion
group = subversion
server = /usr/bin/svnserve
server_args = -i -r /var/www/subversion
log_on_failure += USERID
nice = 10
}
и перезапустим сам сервис xinetd, чтобы настройки вступили
в силу.

# /sbin/service xinetd restart

Не надо забывать также про файервол - на нем необходимо
открыть 3690 порт для доступа.

-- * * * * * * * * * * Примечание: Если все-таки нужно запускать svnserve в режиме
демона

Тогда, будем следовать правилам, которые диктует политика
организации скриптов загрузки System V.

В каталоге /etc/rc.d/init.d/ создадим файл, отвечающий
за запуск сервиса svnserve:

svnserve #!/bin/sh
# svnserve A Subversion standalone server
#
# chkconfig: 2345 70 30
# description: \
# The goal of the Subversion project is to build a revision
system that \
# is a compelling replacement for CVS in the open community. The
software \
# is released under an Apache/BSD-style source license. See the
status \
# page for current progress.
# processname: svnserve
# config: /etc/sysconfig/svnserve

LOCKFILE=/var/lock/subsys/svnserve

# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0

[ -r /etc/sysconfig/svnserve ] && . /etc/sysconfig/svnserve

SVN_USER=${SVN_USER-subversion}

SVNSERVE=/usr/bin/svnserve
SVN_OPTS="-d"

[ -z "$SVN_ROOT" ] || SVN_OPTS="$SVN_OPTS -r \"$SVN_ROOT\""
[ -z "$SVN_PORT" ] || SVN_OPTS="$SVN_OPTS --listen-port $SVN_PORT"

RETVAL=0

[ -x "$SVNSERVE" ] || exit 0

start() {
echo -n $"Starting svnserve"
daemon --user "$SVN_USER" $SVNSERVE $SVN_OPTS
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch "$LOCKFILE"
return $RETVAL
}

stop() {
echo -n $"Stopping svnserve"
killproc svnserve
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && rm -f "$LOCKFILE"
return $RETVAL
}

restart() {
stop
start
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart|reload)
restart
;;
status)
status $SVNSERVE
;;
*)
echo "Usage: $0 {start|stop|status|restart|reload}"
exit 1
;;
esac
exit 0
Как видно из этого файла строка запуска сервера svnserve
формируется на основе файла /etc/sysconfig/svnserve:

/etc/sysconfig/svnserve # Subversion user. Subversion server will be started on behalfon
# specified user. Note, that user should have access to SVN_ROOT
# if the last one is used.
# Default value is "subversion"
SVN_USER=subversion
# Virtual root for repositories served by svnserve. The pathname in
# URLs provided by the client will be interpreted relative tothis
# root, and will not be allowed to escape this root.
# If not set, the client will have access to whole filesystem.
SVN_ROOT=/var/www/subversion
# Listened port. The IANA has reserved port 3690 for the Subversion
# protocol.
# Default value is 3690
SVN_PORT=3690
Осталось добавить сервис в <<таблицы запуска>>
/etc/rc.d/rcX.d/:

# /sbin/chkconfig --add svnserve

И запустить сервис:

# /sbin/service svnserve start
-- * * * * * * * * * * Дальше необходимо создать правила доступа к репозиторию -
они устанавливаются в файле conf/svnserve.conf, который
находится в каталоге репозитория. В нем задается файл
с пользователями ихи паролями, имя области репозитория,
а также правила доступа пользователей.

conf/svnserve.conf [general]
password-db = passwd
realm = KOSC's Repository
anon-access = read
auth-access = write
Последние две строчки сообщают, что анонимным пользователям
разрешено только чтение, а идентифицированным пользоватеям
четние/запись.

passwd - файл со списком пользователей - имена и пароли
задются в нем в открытом виде (при его создании у пользователя
"subversion" обязательно должны быть права как минимум
на чтение)

passwd [users]
koal = 1234
old_bibigon = 4321
Теперь, в качестве проверки, попробуем создать новый проект
в репозитории. Для чистоты эксперимента будем создавать
его по сети. Поэтому дальнейшая работа будет происходить
на другой машине от обычного пользователя.

Сперва, создадим тело проекта. Как сказано в документации
желательно сразу же предусмотреть структуру каталогов: создать
каталоги branches, tags и trunk, - в последний сложить файлы
проекта. Итак, совершим данное <<шаманство>> над проектом
lindocs (GUI для базы ссылок):

$ ls -1 ~/tmp/lindocs/*
/home/koal/tmp/lindocs/branches:
/home/koal/tmp/lindocs/tags:
/home/koal/tmp/lindocs/trunk:
bases.py
bd
contrib
lindocs2html.py
lindocs.py
lindocs.xml
pixmaps.py
sets.py

Теперь импортируем проект в репозиторий:

$ svn import ~/tmp/lindocs svn://bridge/lindocs/ \
--message "Initial import"
Authentication realm: <svn://bridge:3690> KOSC's Repository
Username: koal
Password for 'koal':
Adding /home/koal/tmp/lindocs/trunk
Adding /home/koal/tmp/lindocs/trunk/contrib
Adding /home/koal/tmp/lindocs/trunk/contrib/db_lindocs_i.py
Adding /home/koal/tmp/lindocs/trunk/contrib/old_to_new.py
Adding /home/koal/tmp/lindocs/trunk/contrib/parse_html.pl
Adding /home/koal/tmp/lindocs/trunk/contrib/db_lindocs_c.py
Adding /home/koal/tmp/lindocs/trunk/lindocs.py
Adding /home/koal/tmp/lindocs/trunk/bases.py
Adding /home/koal/tmp/lindocs/trunk/bd
Adding (bin) /home/koal/tmp/lindocs/trunk/bd/lindocs.sqlt.bz2
Adding /home/koal/tmp/lindocs/trunk/sets.py
Adding /home/koal/tmp/lindocs/trunk/pixmaps.py
Adding /home/koal/tmp/lindocs/trunk/lindocs2html.py
Adding /home/koal/tmp/lindocs/trunk/lindocs.xml
Adding /home/koal/tmp/lindocs/branches
Adding /home/koal/tmp/lindocs/tags
Committed revision 1.

Попробуем посмотреть содержимое репозитория:

$ svn list -R svn://bridge/lindocs/
branches/
tags/
trunk/
trunk/bases.py
trunk/bd/
trunk/bd/lindocs.sqlt.bz2
trunk/contrib/
trunk/contrib/db_lindocs_c.py
trunk/contrib/db_lindocs_i.py
trunk/contrib/old_to_new.py
trunk/contrib/parse_html.pl
trunk/lindocs.py
trunk/lindocs.xml
trunk/lindocs2html.py
trunk/pixmaps.py
trunk/sets.py

А также журнал изменений:

$ svn log svn://bridge/lindocs
r1 | koal | 2005-02-15 17:16:43 +0300 (Tue, 15 Feb 2005) | 1 line
Initial import
Видно, что пароль у нас спросили только первый раз. После чего
он запомнился - найти его можно в каталоге
/.subversion/auth/svn.simple.

Настройка доступа к репозиторию через Apache

Чем выгодно использование Subversion вместе с Apache?
Во-первых, не нужно открывать на файерволе дополнительный
порт, если конечно не нужно обратного. Во-вторых для общения
с сервером используется протокол WebDAV/DeltaV, который
является расширением HTTP 1.1, а это значит возможно
просматривать текущее состояние репозитория в обычном
браузере. В-третьих, идентификацию и авторизацию пользователей
можно проводить средствами Apache. А еще настройка происходит,
через уже знакомый многим конфигурационный файл httpd.conf (и
conf.d/*), что тоже является плюсом.

Итак, после установки пакта с Subversion в каталоге
/usr/lib/httpd/modules появились файлы mod_dav_svn.so
и mod_authz_svn.so, а в каталоге /etc/httpd/conf.d/ -
subversion.conf. Первый файл является <<прослойкой>> между
модулем mod_dav (он реализует расширение WebDAV/DeltaV)
и библиотеками работы с Subversion репозиторием. Второй нужен
для управления правилами авторизации. Третий - один
из конфигурационных файлов Apache. Настройки укзанные в нем
подключаются к основной конфигурации через директиву Include
в httpd.conf. Сейчас, /etc/httpd/conf.d/subversion.conf
содрежит следующие строки:

/etc/httpd/conf.d/subversion.conf LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
Здесь происходит загрузка упомянутых выше модулей. Однако,
следует заметить, что в конфигурационном файле сервера Apache
httpd.conf необходимо секцию Include conf.d/*.conf поставить
после секции LoadModule, там где загружаются DSO (Dynamic
Shared Object), иначе при перезапуске Apache, выдастся ошибка
(в более новых дистрибутивах, эта проблема уже может быть
решена):

/etc/httpd/modules/mod_dav_svn.so: undefined symbol: dav_xml_get_cdata
Это связано с тем, что при неизменненом файле кнофигурации
mod_dav_svn.so пытается загрузиться перед mod_dav.so, который
отвечает за работу первого (информацию об этом можно
почерпнуть в bugzilla.redhat.com и архиве рассылки
fedora-test-list.

Теперь, необходимо создать секцию, в которой будет происходить
настройка работы с репозиторием. Эту секцию можно будет
создать прямо в файле subversion.conf, тогда работа
с репозиторием будет происходить через использование имени
сервера, которое задано в директиве ServerName в httpd.conf.
Ну а если существует вирутальный хостинг и необходимо, чтобы
репозиторий был доступен чере него, то тогда все изменения
будут происходить
в файле virtual.conf, находящемся в томже каталоге,
что и subversion.conf. В нашем случае именно с ним мы и
продолжим работать.

Для начала необходмо вспомнить, что сервер Apache работает
от имени пользователя "apache" и группы "apache" (это задается
в директивах User и Group), а доступ к репозиторию выставлен
для пользователя "subversion" и группы "subversion". Поэтому
необходимо добавить пользователя "apache" к группе
"subversion" и назначить каталогу с репозиторием такие права,
при которых вновь создаваеме файлы и каталоги имели бы такого
же владельца, что и родительский каталог:

# /usr/sbin/usermod -G subversion apache
# find /var/www/subversion -type d -print \
-exec chmod ug+s "{}" ";"

Приступим к правке virtual.conf. Пусть с репозиторием мы будем
работать через имя сервера - lug. Cоотвественно, изменения
коснуться именно этой секции <VirtualHost>. Внутри нее добавим
секцию <Location>:

<Location /repos>
DAV svn
SVNPath /var/www/subversion
</Location>
Т.е. если теперь набрать в адресной строке браузера:
http://lug/repos/, то бразуер отобразить проекты репозитория
(конечно, надо предварительно перезапустить httpd).

На данном этапе репозиторий открыт для внесения изменений
каждому. Это совсем не безопасно. Поэтому надо каким-то
образом разграничить доступ. Для начала пользоватлей нужно
идентифицировать, а только потом в зависимости от рузльтатов
идентификации производить их авторизацию - определять какого
уровня доступ возможен тем или иным пользователям.

Будем использовать обычную схему идентификации:

<Location /repos>
DAV svn
SVNPath /var/www/subversion

AuthType Basic
AuthName "KOSC's repository"
AuthUserFile /var/www/subversion/conf/auth-file
Require valid-user
</Location>
С помощью стандартной для Apache утилиты htpasswd создадим
файл со списком пользователей, в нем же содержатся шифрованные
пользовательские пароли:

# htpasswd -cm /var/www/subversion/conf/auth-file koal
New password: **
Re-type new password: **
Adding password for user koal
# htpasswd -m /var/www/subversion/conf/auth-file old_bibigon
New password: ***
Re-type new password: ***
Adding password for user old_bibigon

Теперь, перед тем как вывести содержимое репозитория браузер
выдаст окно с просьбой идентифицировать себя.

В таком состоянии получается, что каждый пользователь должен
иметь запись в /var/www/subversion/conf/auth-file, даже
для того чтобы просто просмотреть содержимое репозитория.
То есть не анонимного доступа. А хотелось бы, чтоб такой
доступ был. Поэтому укажем, что деректива Require valid-user
должна выполняться не все время, а только при определенных
типах запросов. Нет, даже не так: укажем, чтобы
она НЕ выполнялась при запросах, которые не вносят изменений
в репозиторий.

<Location /repos>
DAV svn
SVNPath /var/www/subversion

AuthType Basic
AuthName "KOSC's repository"
AuthUserFile /var/www/subversion/conf/auth-file
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
Казалось бы все. Но для того, чтобы полнее рассмотреть
возможности связки Subversion и Apache, рассмотрим еще один
сопособ авторизации, с использованием возможностей модуля
mod_authz_svn. Ег использование дает возможность создать файл
авторизации, в котором указывать кто из пользоватлей
репозитория имеет доступ к определенным директориям
репозитория и каков уровнеь этого доступа. Как это будет
выглядеть:

<Location /repos>
DAV svn
SVNPath /var/www/subversion
AuthzSVNAccessFile /var/www/subversion/conf/access-file

Satisfy Any
Require valid-user
AuthType Basic
AuthName "KOSC's repository"
AuthUserFile /var/www/subversion/conf/auth-file
</Location>
Видно, что нужно создать еще один файл:
/var/www/subversion/conf/access-file

/var/www/subversion/conf/access-file [groups]
commiters = koal, old_bibigon
lindocs-developers = koal, old_bibigon

[/]
* = r
commiters = rw

[/lindocs]
* =
@lindocs-developers = rw

[/lindocs/trunk]
* = r

[/lindocs/tags]
* = r

[/lindocs/branches/koal]
old_bibigon = r
[/lindocs/branches/old_bibigon]
koal = r
Что же в нем происходит? Разберем синтаксис. Хотя наперед
необходимо сказать, что права обладают свойством наследования,
то есть вложенным каталогам передаются права родительского
каталога, и если их нужно перекрыть, то об этом нужно сказать
явно. Итак,
* после объявления секции [groups], создаем группы
пользователей (этого можно и не делать, но тогда в правах
на каталоги придется указывать пользователей Subversion
<<по-человечно>>.
* [/] - говорим, что в корневой каталог репозитория доступ
для неидентифицированных пользователей, или пользователей,
не входящих в группу commiters, только на чтение, зато
commiters могут создавать в нем новые проекты.
* [/lindocs] - обычным пользователям, не входящим в группу
lindocs-developers не обязательно видеть внутренную
структуру проекта, поэтому они даже не имеют прав
на чтение
* [/lindocs/trunk] и [/lindocs/tags] - предыдущее правило
перекрывается этими для вложенных каталогов tags и trunk,
из которых обычные пользователи могут получать информацию
указав их адрес целиком: http://lug/lindocs/tags/
или http://lug/lindocs/trunk/. А пользователи из группы
@lindocs-developers все-еще могут нормально производить
любые операции с этим каталогами.
* [/lindocs/branches/koal] и [/lindocs/branches/old_bibigon]
- так как правила наследовались, то производить изменения
в каталоге branches могли только пользователи из группы
@lindocs-developers, а в подкаталогах koal и old_bibigon
это правило переопределяется - дробится: в каталог может
вносить изменения только его создатель, другой же имеет
право только наблюдать за этими изменениями. Заметьте,
что обычные пользователи вообще не имеют никакого доступа.

Вот на этом, пожалуй, можно остановиться.