Создаем свой SVN сервер: 3$ и 30 минут

    Многих хабрачитателей иногда волнует вопрос хостинга SVN. В интернете полно вариантов захостить SVN репозиторий, с ценой порядка 10-15уе в месяц, но смущает одно: хостинг репозитория — намного более ответственное дело, нежели хостинг сайта. В коде — ваши «сверхценные идеи», от аптайма сервера и надежности бэкапов напрямую зависит работа вашего бизнеса. Некоторые выбирают все же хостить SVN в серьёзных компаниях. Хорошее сравнение по параметрам тут: http://www.svnhostingcomparison.com/, open-source кстати можно захостить в неплохом месте на букву G ;-).

    Другие же, как и я, решают хостить SVN на своём VDS / Dedicated сервере. На этом вопросе я и остановлюсь, рассказав заодно немного о вариантах запуска/настройки svn сервера (в том числе относительно новых — шифрование/аутентификация SASL и хранение в FS). Выльеться все это вам в 3-4$/месяц, в полный контроль за бэкапами и доступом к серверу. Пожертвовать придется 30 минут драгоценного времени на настройку.

    Целевая аудитория: начальный — средний уровень опыта работы с Linux.
    PS. Я в курсе что FreeBSD is not Linux ;-)

    Варианты работы сервера SVN



    По серверу:
    • Apache+SVN. Пока самый популярный.
    • svnserve. Самый быстрый, но нужен минимум VPS сервер.


    По шифрованию:
    • Без шифрования. Только в корпоративных сетях.
    • SSL: Шифрование уже «по старинке» — только в связке с Apache.
    • SASL: Новый способ, включенный в svnserve. Для работы нужен клиент версии 1.5.3 и выше. За последней фразой скрывается 4 часа отчаяния :-)


    По аутентификации:
    • Список пользователей с открытыми паролями в passwd(самый простой способ).
    • Защищенная проверка через SASL: DIGEST-MD5(пароли в открытом виде не идут).
    • Туннель svn+ssh: пользователи логиняться под своими Linux аккаунтами.
    • Можно прикручивать любые другие способы, в том числе и обычную БД.


    По хранению данных:
    • Berkley DB — старый(проверенный временем) и надежный способ.
    • FileSystem — новый, можно делать бэкапы «на лету»


    Для своего сервера я выбрал вариант
    • svnserve (за малый расход памяти и скорость)
    • SASL (симетричное шифрование которое работает хоть как-то, от говно-сертификата(самоподписанного) SSL толку 0, да и люди склонны принимать любые сертификаты).
    • Проверка паролей через SASL
    • Хранение на FileSystem
    • Хостится решено на firstvds.ru FreeBSD, 1 гигабайт места, легко расширяться, полный контроль за бэкапами и доступом, 64 метра памяти (забегая вперед, скажу что используется всего 6.5, c апачем так не получилось бы ;-) ). Это счастье стоит 4у.е(3 со скидкой 25% ;-)) в месяц). Бесловно, вы можете выбирать любой VDS тут.


    Настраиваем систему


    • Собираем/ставим svnserve. Нужно включить поддержку SASL, все остальное не нужно.
      cd /usr/ports/devel/subversion
      make install clean

    • Создаем юзера svn, и под ним дальше все делаем. Вырубаем у него удаленный логин, ну или в крайнем случае ставим ну очень сложный пароль.
    • Создаем репозиторий: svnadmin create ~/name
    • Идем в ~/name/conf, и в svnserve.conf пишем
      [general]
      anon-access = none
      auth-access = write
      realm your_server_realm
      [sasl]
      use-sasl = true
      min-encryption = 128
      max-encryption = 256


      Обращаем внимание на конец файла — включается шифрованная проверка пароля (min-encryption>0) и обязательное шифрование минимум 128 бит. Выше 128 мой клиент (пока) не держит :-)
    • Дальше добавляем юзеров в базу SASL:
      saslpasswd2 -c -f sasldb -u your_server_realm new_user_name

      Наблюдаем за создавшимся файликом sasldb.db и запоминаем к нему путь.
    • Дальше самое сложное, настройка SASL. Нужно узнать где лежат либы SASL. Например с помощью locate libsasldb
      В случае firstvds с FreeBSD это /usr/local/lib/sasl2
    • Создаем тут файл svn.conf такого вида:
      pwcheck_method: auxprop
      auxprop_plugin: sasldb
      sasldb_path: /your_path_to/sasldb
      mech_list: DIGEST-MD5

      Обращаю внимание что расширения .db тут не нужно писать.
    • Изменяем скрипт запуска:(/usr/local/etc/rc.d/svnserve)
      svnserve_flags=${svnserve_flags:-"-T -d --listen-port=3690 --listen-host 0.0.0.0"}
      svnserve_data=${svnserve_data:-"/your_path_to_repository"}
      --listen-host 0.0.0.0 нужен т.к. во FreeBsd svnserve начинает слушать по дефолту IP6 а не древний IP4 :-)
      -T — использовать threads. -d — запуск демоном.
      Теперь делаем svnserve start и можно смотреть, заработало или нет :-)
      Если svnserve уже запущен, запуск апача может вывалить варнинги, но все работает все равно :-)
    • Настраиваем скрипт на автозапуск в ISPManager:
      Добавляем новый сервис
      Name: SVN
      Mode: Standalone
      Process name: svnserve.bin
      Start command: /usr/local/etc/rc.d/svnserve start
      Stop command: /usr/local/etc/rc.d/svnserve start
      System name: svn
      Type: Unknown service
      Autostart: Yes
      Minotoring: No
    • Все остальные сервисы убираем из автозапуска(прибъете апач — ISPManager станет недоступным, запустить снова можно с консоли apachectl start или apache2ctl start). Одновременно апач и svnserve не работают.
    • Перезапускаем VDS через VDSManager и если вы все сделали правильно — сможете начинать работать со своим собственным SVN сервером. При активной работе нагрузку практически не заметно, все очень быстро.


    Загрузка сервера выглядит примерно так:
    image

    Бэкапы


    Есть смысл либо заказать услугу «Ежедневные бэкапы» либо самому по крону делать и заливать бэкап репозитория на ваш другой хостинг или к вам на компьютер.

    Заключение


    Надеюсь, мои потраченные 8 часов на разбивание лба обо все незаметные камушки на этом пути помогут хабралюдям получить ценный опыт администрирования SVN сервера :-). Удачных вам бэкапов и коммитов без конфликтов:-)

    PS. Есть замечания, ошибки? — буду рад услышать :-)
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 78
    • +2
      верьте или нет но неплохое место на букву G у меня теперь, в контексте систем управления версиями, ассоциируется только с GitHub'ом: Р
    • +6
      наверняка заминусуют, но я все-равно спрошу. Подскажите, как называется софт, который умеет делать такие графики (по загрузке системы).
      • 0
        apt-get install bootchart
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            И правда, я судя по всему не так понял вопрос))
            • 0
              еще можно посмотреть в сторону cacti и nagios
          • 0
            В данном случае это скриншот из VDSManager :-)
          • 0
            А что насчет надежности такого решения?
            Лично я бы предпочел платить на 7-9$ больше, но хостится у проверенных компаний в данном направлении.
            • 0
              А кому платят 7-9$?
              А надежность этого — надежность firstvds * на надежность решения.
              • 0
                Ну, пока проблем небыло, что-то с сервером случилось — гарантированно можно поднять новый инстанс за 20 минут.
                • 0
                  Не хочу развязать холи вар, но среди VPS firstvds.ru далеко не самое худшее место.
                  Цены тут низкие из-за платного саппорта, и я считаю это правильно :-)

                  Более надежные варианты — это 25 и выше $/месяц.
                  Ну и конечно ничто не мешает вам в случае необходимости быстро поднять ваш свн из бэкапа где-нить на Amazon или дедике :-)
                  • +2
                    Пользуюсь разгоном от firstvds больше года — никаких проблем не было.
                    А про платную поддержу — это если гнать начинаешь, если реально технические проблемы и нужно решение, помогут без проблем.
                  • 0
                    Можно пользоваться гугловым. Функционал там достаточный и плюс бесплатно.
                    • 0
                      Угу, но только для опен сорс.
                    • +1
                      Не делаю рекламу, а просто доношу до хабраобщества.
                      Еще очень хороший бесплатный svn — xp-dev.com.
                      В отличии от других, дают 1.5 гига места. Но нету багтрака.
                      • +1
                        Проблема с бесплатным SVN хостингом в том, что однажды они говорят «А теперь платите, месяц на размышления». Такое было уже не раз :-)
                        • 0
                          В смысле: платите или мы выложим исходники на всеобщее обозрение?!
                          • 0
                            Именно так. Да и саппорт/аптайм ожидать от фрихостинга не приходится.
                            • 0
                              А в суд на них за это?
                              • 0
                                Когда работа стоит а дедлайн поджимает, суд вам мало поможет :-)
                                Да и обычно при регистрации вы соглашаетесь с условиями типа «Если что случиться — мы ни за что не отвечаем» ;-)
                                • 0
                                  взяли tailor и переехали в другое место. перенос django (~9000ревизий) — 4 часа всего. Вряд ли у вас проект крупнее.
                                  • 0
                                    но это только если опенсорс. А опенсорс есть бесплатный и на гите, и на сабвершене.

                                    а если код закрытый — то аффтары хостинга смогут шантажировать вас открытием исходников.
                                    • 0
                                      лично я бы не смог спать спокойно, зная что есть какой-то объём относительно важных данных без «бекапа»). Другими словами — в следующем проекте взяли tailor и делаем зеркало от греха подальше)

                                      а вообще бесплатные сервисы — как правило as is, какие к ним претензии-то? Это уже не шантаж, это клоунада)

                                      я вообще не понимаю — это коммерческий проект? И нет денег на платный/свой svn? Или это некоммерческий проект, но с такими секретными технологиями которые никак нельзя показать миру?
                                      • 0
                                        «я вообще не понимаю — это коммерческий проект? И нет денег на платный/свой svn?»

                                        Мне вот недавно люди сайт заказывали, для тренинговой конторы. Так им даже на хостинг денег жалко, религия не позволяет, — пришлось хостить на Google AppEngine и юзать сроду до этого не пользованные сервисы веб-форвардинга на ру-центре.
                                        Копейка к копеечке… :)

                                        «Или это некоммерческий проект, но с такими секретными технологиями которые никак нельзя показать миру?»

                                        Почему обязательно секретными? Может быть, человеку просто не хочется открывать свой код. Например, чтобы при случае («если дело пойдёт») можно было всегда сделать его коммерческим. Или напихать каких-нибудь закаладок и/или рекламы в гуй.
                                        Ну или просто, как у Квипа, чтобы не делали несовместимых форков.
                                        • 0
                                          Если абсолютно бесплатный Гуголь кому-нибудь выложит на обозрение мою потчу — я обижусь вплоть до решительных действий.
                          • 0
                            Ну не помню что бы кто то говорил что выставят исходники на всеобщее обозрение.
                            А вообще, лично для меня свн это довольно больная тема. Он то нужен, но нужды в своем сервере нету. А платить по 10 долларов в месяц за кучу не нужных вещей не хочется.
                            Вот и кочую по различным фришным свнам. Раньше была ассембла, теперь иксппи-дев. Дальше — посмотрим :)
                            • 0
                              На xpdev хозяин обещает его оставить бесплатным навсегда.
                              • 0
                                roopindersingh.com/2008/11/01/free-subversion-hosting/
                                тут написано почему
                                • 0
                                  Да вижу. Но к сожалению, не могу доверять такому молодому серверу.

                                  Товарисч может еще не знает как грустно может вести себя СВН под большой нагрузкой. 100 юзеров которые делают одновременно апдейт утром в разных проектах — не каждый сервер переживет такое :-)
                          • 0
                            Спасибо за статью. В меморис…
                            • 0
                              Спасибо за статью, на самом деле интересно.

                              >Одновременно апач и svnserve не работают.
                              Вот эту фразу поясните, пожалуйста.
                              что им мешает работать вместе? надо всего-лишь указать для прослушки разные ip/ports
                              • 0
                                Использовать DAV. В интернетах много способов описано.
                                Добавляются пару модулей и конфигурируется апач.
                                • 0
                                  Порты у них и так разные.

                                  Апач пишет:
                                  [Fri Feb 13 11:52:12 2009] [warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter
                                  [Fri Feb 13 11:52:12 2009] [warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter

                                  Опс, я почему-то думал что это ошибка :-)
                                  Все работает вместе, исправляю статью :-)
                              • 0
                                Да, этот способ я считаю не очень удобным. Или совсем не удобным, поскольку нужно выключать Апач, что муторно очень.
                                Когда я настраивал свой репозиторий, то все делал через WebDAV. Это намного удобнее и гибче, при том же функционале. Подробные инструкции можно спросить у Гугла.
                                Особенно хорошо эта схема работала вместе с Trac. Да, там нет мультипроектности, но для малых проектов можно и майлстоуны юзать. Да и конфиги можно править прям из Trac, что тоже очень удобно. Этот способ я считаю самым оптимальным сейчас.
                                На своей практике, я столкнулся с тем, что модули для WebDav были не совместимы с самыми новыми версиями апача (не знаю как сейчас), но эта проблема решилась откатом на более старую версию апача. Да и невозможность использовать в старых версиях SubVersion мультипроектности (тогда 1.3 + CentOS 4) но на более свежих версиях это уже доступно. Других проблем не было.
                                • +1
                                  Только есть одно но, svnserve быстрее на 30-400% ;-)

                                  stackoverflow.com/questions/502585/svnserve-vs-moddavsvn
                                  seems to be less known that the choice of the server variant used — the Apache Subversion mod_dav_svn module or the standalone svnserve server — have a great impact to measured and perceived subversion performance. Usually svnserve is significantly faster than Apache mod_dav_svn

                                  In a synthetic, non-representative benchmark test I performed using Subversion 1.4.5, Subversion 1.1.1 and Apache 2.0, mod_dav_svn's performance was 30% to 400% slower than svnserve's. svnserve's performance was close to local direct accesses to the repository using the svn command line tools.
                                  • 0
                                    Только при ширине канала в среднем 1 Mbit это вообще значения не имеет :). Проверено.
                                    Конечно если дома делать или в локалке, то да.
                                  • +1
                                    Ну и apache+WebDav+svn уже в 64 метра памяти лезут с трудом.
                                    • 0
                                      64 метра памяти вообще особо ни на что не хватит. ;)
                                      а если и так, можно и расширить, стоит это будет не особо дорого.
                                      • 0
                                        Как это «ни на что не хватит» :-)
                                        С svnserve у меня 6.5Мб памяти используется, 10% от лимита :-)
                                        • 0
                                          Смешно, да :)
                                          Вот Вы прицепились к этой памяти, которая сейчас вообще копейки стоит. Право.
                                          Зачем вводить в заблуждение?!
                                          Я писал о полноценной системе для разработчика.
                                          А лазить отключать-включать сервисы — это неудобно. Ведь в большенстве случаев это еще и тестовый сервер, где проверяются приложения в боевых условиях.
                                          Ну в общем ясно, кроме производительности (когда ширина канала ее просто нивелирует) больше аргументов нет, тема Вами не исследована. Я же написал о реальном опыте использования, когда апач отжирает свои стандартные 30-40 метров и в общем особо не мешает.
                                          • 0
                                            Значит мы писали о разных вещах. Если бы статья была о полноценной среде разработки, я бы никогда её на 64 метра не поставил :-)
                                            А у svnserve — меньше памяти — больше дискового кеша :-)

                                            То что у нас доступно много ресурсов не значит что их нужно расходовать неэффективно.
                                            Если стоит задача просто поднять svn — то это решение наиболее эффективно.

                                            Если условия другие- то и решение может быть другим.
                                  • 0
                                    www.assembla.com/ — и SVN последней версии, и Trac, и веб-интерфейсы…
                                    • 0
                                      $2.00 per user per space, per month
                                      $3.00 per gigabyte of disk space per month

                                      Ммм, маленькая команда в 5-6 человек выесть 15у.е в месяц :-)
                                      Я конечно не говорю что это дорого :-)
                                      • 0
                                        Так это ж всё можно настроить за считаные часы.
                                        А на собственный VDS — это всё-таки полноценный сервер. Можно, например, Trac переколбасить так как надо (а не пользоваться стандартным шаблоном).
                                        • 0
                                          Верно ) Но если всем лень заниматься настройкой/не хватает ровности рук — конечно лучше на svn хостинг :-)
                                      • 0
                                        Спасибо, хорошая статья.
                                        По тексту не очень понял, какие именно варианты подходят для клиентов на windows.
                                        • 0
                                          Все.
                                          • 0
                                            спасибо. прибиваю в избранное как руководство к действию
                                        • 0
                                          Спасибо. В ближайшее время перееду на дедик. Как-раз собирался разбираться с svn.
                                          • 0
                                            Хорошая статья, спасибо автору, в избранное, и тп и тд..=)
                                            У меня возник такой вопрос, если нужен и веб-сервер и свн-сервер, то что будет выгоднее по производительности? apache+mod_dav_svn или apache+svnserve? По логике если апач и так нужен, то пусть он будет работать один хоть и с дополнительными модулями, и незачем запускать новые процессы (svnserve). Или я не прав?
                                            • +1
                                              Чуть выше была ссылка на тест скорости. Один svnserve ест намного меньше ресурсов чем Apache+модуль, и работает на 30-400% быстрее.
                                              Если нужен и апач на том же сервере, может и есть смысл делать все на апаче (но скорость будет ниже все равно).
                                            • 0
                                              А насколько медленне может оказаться использование svnserve не в режиме демона, а через inetd/xinetd?
                                            • +1
                                              svn+ssh + command=/usr/bin/ssh в authorized_keys + ssh_keys :) + posix acl =

                                              1) нет более безопасного варианта
                                              2) только если не быть полным идиотом и делать ssh ключи без пароля
                                              3) при posix acl — права можно настраивать как угодно
                                              4) если вы нихрена в этом не понимаете — то более сложного варианта все настроить для вас не будет. Но знание сие крайне полезно бывает)
                                              5) можно написать свой входной скрипт (а-ля bzr_access), проверять права уже там, при этом достигается сумасшедшая гибкость — хоть в бд права юзеров смотрите.

                                              Сейчас повально сервера (github, launchpad и почти все остальные) начали просить паблик ssh ключ и организовывать доступ к ресурсам сервера именно описанным образом, под протоколом ssh. Ну наконец-то до всех дошло, насколько мощным и быстрым это может быть =).
                                              • 0
                                                Хостится решено на firstvds.ru @FreeBSD, 1 гигабайт места,
                                                +1 так же сделал. для полных чайников типа меня писал тут:
                                                developer.habrahabr.ru/blog/49496/
                                                • 0
                                                  Статья понравилась, но считаю была бы более полной если бы автор описал бы каждый шаг установки SVN, к примеру:
                                                  — Собираем/ставим svnserve. Нужно включить поддержку SASL, все остальное не нужно. Для новичков было бы полезно.
                                                  • 0
                                                    Проблема в том, что этот первый шаг разный на разных системах :-)
                                                    • 0
                                                      В данной статье как я понял расматривается случай с FreeBSD, вот почему бы его и полностью не описать.
                                                      • 0
                                                        Поправил статью :-)
                                                        • 0
                                                          Сейчас все проверял аналогично инструкции, нашел опечатку:
                                                          realm your_server_realm
                                                          ругается, требуется указать как
                                                          realm = your_server_realm
                                                  • 0
                                                    А откуда связка svnserve+sasl знает что настройки sasl нужно брать из файла svn.conf?
                                                    Что-то у меня под debian не получается повторить.
                                                    Клиент пишет: Error while updating filelist (Could not obtain the list of SASL mechanisms)
                                                    • 0
                                                      Да, это самое кривое место во всем процессе.
                                                      Либа берет svn.conf в том каталоге где лежит, и поиск нужного каталога занял у меня часа 2 :-)
                                                      В крайнем случае можете попробовать пересобрать либы SASL, с поддержкой MD5.
                                                      • 0
                                                        Спасибо за подсказку — получилось.

                                                        Для дебиана рецепт такой:
                                                        apt-get install sasl2-bin libsasl2-2 libsasl2-modules (моя ошибка вылезала без modules).
                                                        subversion как в посте, только я решил запускать через inetd:
                                                        svn stream tcp nowait svn /usr/bin/svnserve svnserve -i -r /home/svn, соответственно создал пользователя svn с shell и home /dev/null

                                                        Файлик svn.conf я сделал в /home/svn/ и сделал символическую ссылку: ln -s /home/svn/svn.conf /usr/lib/sasl2/svn.conf

                                                        Кстати, имя snv.conf видимо берётся по типу `grep svn /etc/services`.conf
                                                    • 0
                                                      У меня вопрос. Файлик sasldb если открыть на просмотр (например less -ом) содержит в явном виде логины и пароли. Точнее не в явном, но среди крякозябр есть место где вся эта информация в куче. Как этого избежать?
                                                      • 0
                                                        Да, вы правы, но никак :-)

                                                        Для того чтобы пользоваться DIGEST-MD5 сервер иметь возможность хранить пароль в открытом виде.
                                                        Т.е. тут всегда дилема, передавать хэш который можно перехватить и хранить хэш, или передавать хеш который нельзя перехватить и хранить открытый пароль.
                                                      • 0
                                                        А хранение и передача хэшей это использование простого списка пользователей с открытыми паролями в passwd?
                                                        • 0
                                                          Я про теорию говорю) Для MD5-DIGEST нужны открытые пароли на сервере.
                                                          Если авторизоваться только по простому хэшу — тогда и хранить можно хешь, но безопасности это не добавляет, т.к. перехваченный хеш позволит кому угодно авторизоваться.
                                                        • 0
                                                          Нам собственно, перехват -то и не страшен. А что касается оперирования только хэшами — не подскажете реализацию? :)
                                                          • 0
                                                            Тут SASL похоже не поможет(), и можно перейти на SSH+SVN, тогда пароли будут захешированы по-юниксовски.
                                                            Но такой вариант я не настраивал :-)
                                                          • 0
                                                            Да для ssh придётся и клиентов перенастраивать и скорость упадёт. Вообщем спасибо за прояснение :)
                                                            • 0
                                                              Создаем юзера svn, и под ним дальше все делаем

                                                              Из за пропуска второй части предложения пришлось потратить лишнее время на понимание «почему не работает» и затем на переопределение прав с root на svn.

                                                              Зато сейчас всё заработало, хотя и на эмулируемом VirtualBox сервере.
                                                              • 0
                                                                Может у кого есть опыт SASL + GSSAPI?
                                                                Пробую настроить аутентификацию через Kerberos.
                                                                Пока успехов нет:

                                                                cat /usr/lib/sasl2/svn.conf
                                                                

                                                                ## Password check method, default to the SASL AUTH daemon
                                                                pwcheck_method: saslauthd
                                                                ## Mechanism list, MS AD requires you to send credentials in plain text
                                                                mech_list: GSSAPI DIGEST-MD5
                                                                keytab: /etc/krb5.keytab
                                                                ## Saslauthd socket path
                                                                saslauthd_path: /var/run/saslauthd/mux
                                                                log_level: 7
                                                                

                                                                testsaslauthd -u vdoina -p ********** -s svn
                                                                

                                                                0: OK "Success."
                                                                

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