Pull to refresh

Comments 78

верьте или нет но неплохое место на букву G у меня теперь, в контексте систем управления версиями, ассоциируется только с GitHub'ом: Р
наверняка заминусуют, но я все-равно спрошу. Подскажите, как называется софт, который умеет делать такие графики (по загрузке системы).
Я думаю он имел ввиду не загрузку ОС, а загруженность системы =)

Я через mrtg смотрю, для сети есть bandwidth, ntop (но этот очень прожорлив, зато рисует мама не горюй), тот же sams к сквиду отчеты умеет создавать с графиками. Тут все зависит от конкретных потребностей. Если тупо мониторить загрузку сети и процессор с памятью, я б mrtg выбрал.
И правда, я судя по всему не так понял вопрос))
еще можно посмотреть в сторону cacti и nagios
В данном случае это скриншот из VDSManager :-)
А что насчет надежности такого решения?
Лично я бы предпочел платить на 7-9$ больше, но хостится у проверенных компаний в данном направлении.
А кому платят 7-9$?
А надежность этого — надежность firstvds * на надежность решения.
Ну, пока проблем небыло, что-то с сервером случилось — гарантированно можно поднять новый инстанс за 20 минут.
Не хочу развязать холи вар, но среди VPS firstvds.ru далеко не самое худшее место.
Цены тут низкие из-за платного саппорта, и я считаю это правильно :-)

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

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

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

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

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

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

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

Товарисч может еще не знает как грустно может вести себя СВН под большой нагрузкой. 100 юзеров которые делают одновременно апдейт утром в разных проектах — не каждый сервер переживет такое :-)
UFO just landed and posted this here
Спасибо за статью, на самом деле интересно.

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

Апач пишет:
[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

Опс, я почему-то думал что это ошибка :-)
Все работает вместе, исправляю статью :-)
Да, этот способ я считаю не очень удобным. Или совсем не удобным, поскольку нужно выключать Апач, что муторно очень.
Когда я настраивал свой репозиторий, то все делал через WebDAV. Это намного удобнее и гибче, при том же функционале. Подробные инструкции можно спросить у Гугла.
Особенно хорошо эта схема работала вместе с Trac. Да, там нет мультипроектности, но для малых проектов можно и майлстоуны юзать. Да и конфиги можно править прям из Trac, что тоже очень удобно. Этот способ я считаю самым оптимальным сейчас.
На своей практике, я столкнулся с тем, что модули для WebDav были не совместимы с самыми новыми версиями апача (не знаю как сейчас), но эта проблема решилась откатом на более старую версию апача. Да и невозможность использовать в старых версиях SubVersion мультипроектности (тогда 1.3 + CentOS 4) но на более свежих версиях это уже доступно. Других проблем не было.
Только есть одно но, 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.
Только при ширине канала в среднем 1 Mbit это вообще значения не имеет :). Проверено.
Конечно если дома делать или в локалке, то да.
Ну и apache+WebDav+svn уже в 64 метра памяти лезут с трудом.
64 метра памяти вообще особо ни на что не хватит. ;)
а если и так, можно и расширить, стоит это будет не особо дорого.
Как это «ни на что не хватит» :-)
С svnserve у меня 6.5Мб памяти используется, 10% от лимита :-)
Смешно, да :)
Вот Вы прицепились к этой памяти, которая сейчас вообще копейки стоит. Право.
Зачем вводить в заблуждение?!
Я писал о полноценной системе для разработчика.
А лазить отключать-включать сервисы — это неудобно. Ведь в большенстве случаев это еще и тестовый сервер, где проверяются приложения в боевых условиях.
Ну в общем ясно, кроме производительности (когда ширина канала ее просто нивелирует) больше аргументов нет, тема Вами не исследована. Я же написал о реальном опыте использования, когда апач отжирает свои стандартные 30-40 метров и в общем особо не мешает.
Значит мы писали о разных вещах. Если бы статья была о полноценной среде разработки, я бы никогда её на 64 метра не поставил :-)
А у svnserve — меньше памяти — больше дискового кеша :-)

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

Если условия другие- то и решение может быть другим.
$2.00 per user per space, per month
$3.00 per gigabyte of disk space per month

Ммм, маленькая команда в 5-6 человек выесть 15у.е в месяц :-)
Я конечно не говорю что это дорого :-)
Так это ж всё можно настроить за считаные часы.
А на собственный VDS — это всё-таки полноценный сервер. Можно, например, Trac переколбасить так как надо (а не пользоваться стандартным шаблоном).
Верно ) Но если всем лень заниматься настройкой/не хватает ровности рук — конечно лучше на svn хостинг :-)
Спасибо, хорошая статья.
По тексту не очень понял, какие именно варианты подходят для клиентов на windows.
спасибо. прибиваю в избранное как руководство к действию
Спасибо. В ближайшее время перееду на дедик. Как-раз собирался разбираться с svn.
Хорошая статья, спасибо автору, в избранное, и тп и тд..=)
У меня возник такой вопрос, если нужен и веб-сервер и свн-сервер, то что будет выгоднее по производительности? apache+mod_dav_svn или apache+svnserve? По логике если апач и так нужен, то пусть он будет работать один хоть и с дополнительными модулями, и незачем запускать новые процессы (svnserve). Или я не прав?
Чуть выше была ссылка на тест скорости. Один svnserve ест намного меньше ресурсов чем Apache+модуль, и работает на 30-400% быстрее.
Если нужен и апач на том же сервере, может и есть смысл делать все на апаче (но скорость будет ниже все равно).
А насколько медленне может оказаться использование svnserve не в режиме демона, а через inetd/xinetd?
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. Ну наконец-то до всех дошло, насколько мощным и быстрым это может быть =).
Статья понравилась, но считаю была бы более полной если бы автор описал бы каждый шаг установки SVN, к примеру:
— Собираем/ставим svnserve. Нужно включить поддержку SASL, все остальное не нужно. Для новичков было бы полезно.
Проблема в том, что этот первый шаг разный на разных системах :-)
В данной статье как я понял расматривается случай с FreeBSD, вот почему бы его и полностью не описать.
Сейчас все проверял аналогично инструкции, нашел опечатку:
realm your_server_realm
ругается, требуется указать как
realm = your_server_realm
А откуда связка svnserve+sasl знает что настройки sasl нужно брать из файла svn.conf?
Что-то у меня под debian не получается повторить.
Клиент пишет: Error while updating filelist (Could not obtain the list of SASL mechanisms)
Да, это самое кривое место во всем процессе.
Либа берет svn.conf в том каталоге где лежит, и поиск нужного каталога занял у меня часа 2 :-)
В крайнем случае можете попробовать пересобрать либы SASL, с поддержкой MD5.
Спасибо за подсказку — получилось.

Для дебиана рецепт такой:
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
У меня вопрос. Файлик sasldb если открыть на просмотр (например less -ом) содержит в явном виде логины и пароли. Точнее не в явном, но среди крякозябр есть место где вся эта информация в куче. Как этого избежать?
Да, вы правы, но никак :-)

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

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

Зато сейчас всё заработало, хотя и на эмулируемом VirtualBox сервере.
Может у кого есть опыт 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."
Sign up to leave a comment.

Articles