coLinux как альтернатива Денверу

Главные вкладки

Аватар пользователя v1adimir v1adimir 6 июня 2009 в 20:55

Хочется поделиться успешных опытом воссоздания настоящей Linux-среды для веб-разрабоки под Windows.

По историческим причинам сервера, apache, mysql.., у нас работают только под линукс, а именно, под дебианом и все вроде устраивает, однако постепенно нарисовалась проблема – для нормальной веб-разработки, неизбежно приходится предоставлять программисту root'овые права, перезапустить апач, включить/отключить модуль апача, посмотреть логи, завести нового пользователя в базе... Пока в конторе работает один разработчик, это еще как-то возможно, но как только их становится двое, то все, они начинают мешать друг-другу. Да еще плюс к тому, что на этом же сервере крутится самба, почта, subversion... Короче страшновато.

Самое правильное решение – пересадить программистов под линукс и пусть, что хотят на своих компах, то и делают. Однако, разработчики хорошо знакомые с линуксовым десктопом, вещь пока еще редкая, а заниматься обучением вместо работы совсем неохото.

Один из сотрудников с восторгом принялся пиарить Денвер. Тут сразу вспомнились давние, но болезненные эксперименты по настройке серверов под windows – в одном конфиге нужно писать "C:\Program Files\программа1", в другом "C:\\Program\ Files\\программа2", в третьем "/cygdrive/c/Program\ Files/программа1". В общем, АД!

И тут решил попробывать поставить ему на машину Cooperative Linux (http://www.colinux.org). Это не эммулятор и не виртуальная машина – это ядро операционной системы Linux скомпилированное в обычную виндовую программу. То есть линукс запускается под windows как обычная виндовая программа! Все обращения к железу выполняются, естественно, средствами windows, через, специальным образом подшаманенные, модули ядра coLinux. Неслабое извращение. )

Недавно на drupal.ru поднималась тема качества опенсоурс решений, так вот, автор данной разработки утверждает, что ему удалось скомпилировать первую рабочеспособную версию всего за несколько часов.

При этом coLinux считает, что он работает в одиночку и имеет доступ ко всем ресурсам, которые ему транслируются через его модули.

Зачем это нужно?

Мы получаем настоящую *nix среду, аналогичную той, что использует большинство хостеров. Следовательно, будет легче перенести сайт на рабочую площадку. Возникнет меньше проблем со сменой среды исполнения. Одно то, что файлы типа "logo.png" и "LOGO.PNG" начинают различаться снимает регулярно возникающие проблемы.

И windows explorer до сих пор не умеет создавать файлы вида .htaccess!

Что мы получаем?

Сразу оговорюсь, как многолетнего пользователя Debian Linux, меня быстро заносит на торжественные оды в его честь. Постараюсь сдерживаться. Wink

Получает настоящий UTF8. От имен файлов до консоли. И никаких BOM после редактирования.

Получаем *nix со всем его инструментарием – bash, ssh, grep, find, rsync, iconv, tcpdump... Анализаторы логов и производительности...

Почти для всего этого сейчас есть аналоги под win32, но отсутствие в виндоус нормальной консоли превращает их использование в мучение.

Можно пользоваться аналогами с GUI, например grepWin. Проблема с GUI-ми программами, в том, что результат их работы нельзя использовать непосредственно. Если я через grepWin ищу строчку в файле – мне этот файл нужно открыть в редакторе. Вот и получается, что в одной GUI программе файл нужно отыскать, а в другой отдельно открывать.

В linux консоли для этого достаточно результат работы grep передать редактору.

$ vim `grep -lR 'строка для поиска' *`

Или, одной командой, сделать дамп mysql, через ssh законектиться на хостинг и залить этот дапм на рабочую базу.

Кроме того, у нас есть возможность модифицироать систему любым нам нужным образом, например, компилировать дополнительные расширения для php. У нас вот добавлены eAccelerator и xdebug.

Можно даже организовать такую конфигурацию, где гостевой linux будет служить полноценным роутером/файерволом для соединения хозяйского windows с интернетом.

Можно запустить под win32 X-сервер, например xming (http://www.straightrunning.com/XmingNotes/) и работать с гостевым linux через графическую оболочку.

Или можно искуственно организовать среде выполнения недостаток памяти или процессорного времени или ужать скорость сети и посмотреть как она будет себя при этом вести.

Совместный доступ к файлам

Для прямого доступа из под windows к файлам на coLinux мы используем самый прямолинейный подход – запус в linux Samba сервера, реализующего SMB/CIFS протокол, и расшариваем нужные файлы через обычный Microsoft Windows Network.

Доступ к гостевому linux

После инсталяции достум возможен только через специальную программу консоль, что совсем неудобно. Первым делом инсталируем в colinux SSH-сервер и далее конектимся через ssh-протокол. В качестве клиента используем PuTTY. Чтобы не тратить время на логин, настроили автоматическую аутентификацию по rsa-ключам. Кодировка для соединения utf8.

"Диски" в coLinux

Для нормальной работы советую выделять не менее 4ГБ под дисковую систему.

Файл как диск

Самый простой способ – выделить для coLinux специальный файл, который он будет воспринимать как жесткий диск. Это файл можно отформатировать, например, в ext3 – «официальную» файловую систему линукса. Собственно сайт coLinux предлагает, на выбор, несколько уже готовых подобных файлов. Каждый из которых содержит свой дистрибутив линукса.

Важное замечание! формально Линукс это только ядро операционной системы совершенно без каких либо программ, графической оболочки и, даже, без текстовой коммандной консоли. И именно разработчики дистрибутивов формируют набор пакетов, стартовые скрипты и все такое прочее. Так как мы традиционно использовали Debian, то дальнейший рассказ будет идти имено про него, а точнее про версию 4.0 stable (Etch) и WindowsXP.

Минус данного метода — скорость чтения-записи. По идее, должна быть медленее, чем непосредственная запись а файл, так как здесь присутствует трансляция одной файловой системы, ext3, в другую, NTFS.

Плюсы. Серьезных проблем со скоростью обращения не замечал. Зато очень удобно бэкапить и восстанавливать данные или переносить на другой комп. Ужал этот файл в архив, вот и готов бэкап.

Настоящий диск

Если в системе есть свободный дисковый раздел, то можно (хотя я не пробывал) использовать его. Это должен быть самый быстрый метод.

Использование виндовой файловой системы

Можно подмонтировать обычную виндовую директорию как рутовую для coLinux. Не советую! Сразу вылезли проблемы с несовместимостью прав доступа.

Сеть

Реализованный в Debian Etch подход по выделению новых девайсов конфликтует с сетевыми драйверами coLinux! Пока это понял и обнаружил решение, чуть умом не тронулся.

Подцепляемся к родительской windows сети

Самый простой способ выйти в Инет. Ядро coLinux использует сетевые настройки хозяйской системы как любое другое приложение. Как тот же firefox. Основная проблема что мы не не имеем возможности зайти в coLinux извне. Так как он в этом случае не имеет отдельного сетевого интерфейса и отдельного IP.

Туннелирование

Инсталируем идущий вместе с дистрибутивом VPN драйвер, который создает виртуальный сетевой интерфейс и локальную сеть, состоящую из хозяйской и гостевой системы.

Самое быстродействующее соединение, но! по-умолчанию эта сеть не видна из других компов в локальной сети и не имеет выхода в мир.

Для организации выхода в мировой интернет нужно или настраивать в винде bridge между сетевыми интерфейсами или использовать дополнительное сетевое соединение описанное в предыдущем параграфе.

bridge pcap

Мы пользуемся именно этим решением.

Инсталлируем в виндоус специальный драйвер WinPcap, http://www.winpcap.org/ Он может перехватывать и на лету модифицировать сетевые пакеты.

coLinux подключается к этому драйверу и чудо – наша сетевая карта начинает вести себя так, как будто это 2 различные сетевые карты, со своими собствеными MAC и IP-аддресами. Гостевая линукс система становится видна в локальной сети как совершенно отдельный комп. Соответствено он имеет абсолютно все те же самые права что и любой другой комп в сети.

Минус – если ваш комп подключен непосредственно к интернет провайдеру, то придется получать дополнительнй IP-адрес. Что не всегда возможно.

Производительность

Ядро coLinux выполняется как родное приложение windows (мы его вообще запускаем как win32 service при старте) и никаких потерь производительности на эмуляцию или виртуализацию не происходит. Но выполняться оно может только на одном ядре на многоядерных процессорах или в одном потоке при multithreding'e. Полученое coLinux'ом процессорное время и память он уже сам делит между своими приложениями. На современных компах производительности хватает на всех.

Максимальный объем доступной coLinux оперативной памяти можно указать в конфигурационном файле. Если памяти не хватает – процесс скорее всего умирает. Чтобы избежать истощения памяти можно добавить для swap-диск. У нас это еще один файл отформатированный как swapfs.

И, по-моему, память он использует только по мере необходимости, то есть не отъедает сразу всё выделенную.

Стабильность

Удивительная для подобного решения. Падения системы наблюдалось лишь в двух случаях – закончилось место на диске и использование X-сервера.

Первая из проблем порождается установной дефолтной конфигурации MySQL, где включен бинарный лог, то есть запись на диск всех SQL-запросов! Съедает примерно 300 МБ в день при работе с drupal'ом. И при этом еще создает проблемы с производительностью.

Падение программ запущенных из под X-сервера нередкое явление и для полностью родной среды.

Минусы

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

Без опыта работы в *nix среде, покажется, что попал в ад. Чтобы понять преимущество коммандной консоли, нужно быть хоть самую малость с ней знакомым. Знать хотя бы тот факт, что имена директорий и файлов автоматически дополняются по нажатию на Tab и не нужно их вбивать вручную.

Типа заключение

Для разработки, в смысле редактирования файлов и проверки в браузере, мы до сих пор используем WindowsXP. Пока так удобнее.

Среда выполнения apache + mysql + php должна быть *nix'овой. CoLinux, как решение, проверенно и полностью нас устраивает.

Понятно, что приведенного здесь описания недостаточно для счастья и при попытке использовать будут проблемы. Я, насколько смогу, готов подсказывать. Может выложу архив – рабочеспособную систему и конфиги если хватит сил выкосить из него все пароли и прочие критичные данные.

В общем, успехов!

Комментарии

Аватар пользователя Demimurych Demimurych 7 июня 2009 в 2:42

создается впечатление что проблема высосана из пальца.
Вам нужно наделить пользователя ограниченными правами администратора? sudo вам в руки

Аватар пользователя v1adimir v1adimir 7 июня 2009 в 3:46

Demimurych wrote:
создается впечатление что проблема высосана из пальца.
Вам нужно наделить пользователя ограниченными правами администратора? sudo вам в руки

subversion работает, как вы знаете, через apache. и вот дизайнер делает commit, а программист в этот момент решил "мягко" перегрузить апач. но вот незадача, накосячил с параметрами и апач умер. имеем в результате битый svn-репозиторий. работа встала.

чему здесь sudo поможет?

Аватар пользователя axel axel 7 июня 2009 в 3:07

Colinux - интересный проект и ему можно придумать множество применений. Но когда проблема только в разграничении прав, то всё решается утилитами вроде sudo и раздачей прав через acl - благо в линуксе уже практически все ф.с. поддерживают acl.

Аватар пользователя beerman beerman 7 июня 2009 в 3:41

vmware + ubuntu server + у меня еще под вмварью крутится MS Server 2008

Все довольно шустро и не надо ничего шарить по сети. SSH или FTP доступ настраивается в несколько нажатий кнопок.

Аватар пользователя v1adimir v1adimir 7 июня 2009 в 4:05

beerman wrote:
vmware + ubuntu server + у меня еще под вмварью крутится MS Server 2008

Все довольно шустро и не надо ничего шарить по сети. SSH или FTP доступ настраивается в несколько нажатий кнопок.

Ага, можно и так. Но для данной конкретной задачи, посчитал, что coLinux более оптимальное решение. И vmware вроде же как платное?

Настройка ssh и ftp в несколько нажатий кнопок... сдается, что это утопия. ) Невозможно для всего предусмотреть кнопки – для samba, для postfix, для виртуальных хостов.

Аватар пользователя wazzup wazzup 7 июня 2009 в 23:12

wmware server очень хороший вариант Smile
и про несколько нажатий кнопок касательно фтп и ssh тоже все верно
для установки ssh достаточто всего лишь галочку при установке поставить так же и для самбы и постфикса
с базовми настройками

Аватар пользователя v1adimir v1adimir 8 июня 2009 в 9:56

wazzup wrote:
wmware server очень хороший вариант Smile
и про несколько нажатий кнопок касательно фтп и ssh тоже все верно
для установки ssh достаточто всего лишь галочку при установке поставить так же и для самбы и постфикса
с базовми настройками

Для веб-разработки необходимо, чтобы root директория apache была доступна из под самбы с правами пользователя apache. Врядли в vmware есть для этого галочка по-умолчанию. Wink

Но это не отменяет того, что vmware проект более чем достойный.

Аватар пользователя PVasili PVasili 7 июня 2009 в 10:30

Странный подход. *nix ради *nixа? Ставим FAR и Денвер и 99,9999% надуманных тут псевдо проблем решены :). Тем более:
«...редактирования файлов и проверки в браузере, мы до сих пор используем WindowsXP. Пока так удобнее...» Зачем использовать 2 прокладки, если все нормально и так.
Меня умиляет такой подход, так же как и использование утилиты для использования 1С 8.х под *nix, при этом её цена сопоставима со стоимостью лицензии на win....

Аватар пользователя v1adimir v1adimir 7 июня 2009 в 11:40

2 PVasili

Апач под денвером уже научился различать регистр в именах файлов? И это не единственная причина. Прочитай, пожалуйста, статью внимательно.

Я же не кричу, window$-suxx, линух-rulez! Я всего лишь рассказал об альтернативном решении, предполагая, что еще кому-то оно может оказаться полезным. Не можешь понять зачем оно нужно, ну значит оно тебе, на самом деле, не нужно. Не пользуйся, делов-то. )

И к чему-то 1с вспомнил... это что новая CMS такая?

Аватар пользователя inc inc 7 июня 2009 в 11:57

Спасибо за интересную статью.
Наверняка вы рассматривали другие подходы к решению проблемы.

Какие подводные камни есть у связки QEMU с готовым дистрибутивом(напр. dsl+xampp+svnserve)?

Аватар пользователя v1adimir v1adimir 7 июня 2009 в 12:21

Увы, серьезные эксперименты еще были только с VMWare, да и то уже достаточно давно. Но похоже, что сейчас все решения по виртуализации основательно подтянулись по стабильности и производительности.

Аватар пользователя Master of Tragedy Master of Tragedy 7 июня 2009 в 12:32

По-моему, все это страшное извращение. Надо определиться, для чего комп нужен. Я вот отлично живу под линуксом, а в качестве сервера использую XAMPP. Все в несколько строчек в консоли делается. Человеку, который не знаком с Юниксами это решение ничуть не облегчит работу, а скорее усложнит. Зачем вот это все наворачивать?

Аватар пользователя Azerot Azerot 7 июня 2009 в 13:09

Хотя бы затем, что Denwer не даёт полноценной среды разработки, когда дело касается использования сторонних программ, которые будут впоследствие на UNIX-хостинге. Примеры? ImageMagick, memcached и т.д. Про регистр букв уже писали - довольно частая проблема, когда приносят сайты на хостинг с локального компа и наступают на эти грабли.

Quote:
создается впечатление что проблема высосана из пальца.
Вам нужно наделить пользователя ограниченными правами администратора? sudo вам в руки

Ну вот, пожалуйста, пример. В MySQL 5.0.x для создания хранимых процедур (или триггеров - я уже забыл) в базе нужны права супера MySQL. Давать такие права через sudo? Тогда пользователь получает доступ ко всем базам данного MySQL и может там нагадить.

Denwer - это хорошее решение, но хорошее именно в силу простоты установки и запуска, но не полноты. Даже MySQL там без части весьма нужных утилит. Я не против Denwer'а - это было бы глупо, просто в зависимости от уровня люди могут выбирать разные решения. Кому надо начать - берёт Denwer, кто уже чувствует себя довольно уверенно - берёт Linux и копает уже вглубь.

Аватар пользователя v1adimir v1adimir 7 июня 2009 в 13:13

Master of Tragedy wrote:
По-моему, все это страшное извращение. Надо определиться, для чего комп нужен. Я вот отлично живу под линуксом, а в качестве сервера использую XAMPP. Все в несколько строчек в консоли делается. Человеку, который не знаком с Юниксами это решение ничуть не облегчит работу, а скорее усложнит. Зачем вот это все наворачивать?

Повторюсь. ) Не все разработчики знают линукс настолько, что бы в нем работать. Поэтому, да, приходится извращаться.

Аватар пользователя PVasili PVasili 7 июня 2009 в 13:52

"v1adimir" wrote:
И к чему-то 1с вспомнил... это что новая CMS такая?
к тому, что фанаты *nix так же пытаются пользоваться извращениями ;). Тут же согласен с Master of Tragedy , это все интересно только как опыт и не более.

С чем возникли проблемы у вашего сотрудника - сложно понять (возможно руки), все пути Денвер строит автоматом при старте/перезапуске если что-то нужно добавить из расширений - правьте ini.

Чем консоль не устраивает в win тоже не понятно ;). Через неё можно полностью управлять системой (опять же скорее всего от не знания).

Если я использую платформу win (по многим причинам [основная - отсутствие софта]) - то никогда не буду заниматься подобными извратами, а уж тем более толпы начинающих.

Насколько я понял, регистр в имени файла это единственная причина изобретения данного велика. FAR(как файловый менеджер) и Денвер ставятся автоматом ОК,ОК,ОК, а Caps Lock у меня нет привычки наживать, тем более FAR прекрасно различает регистр имен файлов.

"Azerot" wrote:
ImageMagick, memcached
кто вам сказал что нет аналогов в win? Wink Был бы интересен список, чего не хватает еще... PHP можете установить полный, на сайте Денвера лежит необходимый дистрибутив.

Аватар пользователя Azerot Azerot 7 июня 2009 в 14:13

В win аналоги возможно и есть, а вот если ли они в Denwer'е? Smile
А если это потом надо собирать и ставить отдельно, то это опошляет саму идею Denwer'а, такую как "поставил и работай". В этом случае, сложность и затратность по времени установки всех прибамбасов вполне сопоставимы с разворачиванием полноценного Linux.

Аватар пользователя Demimurych Demimurych 7 июня 2009 в 14:37

"v1adimir" wrote:
subversion работает, как вы знаете, через apache

ЭЭЭЭЭЭЭЭЭ
вашему системному администратору нужно маны покурить,

у тех кто делает по уму он работает используя свой собственный сервер.
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.html
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.choosing.html#sv...

Аватар пользователя v1adimir v1adimir 8 июня 2009 в 9:56

Demimurych wrote:
"v1adimir" wrote:
subversion работает, как вы знаете, через apache

ЭЭЭЭЭЭЭЭЭ
вашему системному администратору нужно маны покурить,

у тех кто делает по уму он работает используя свой собственный сервер.
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.html
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.choosing.html#sv...

Пытаешься отсылками к частностям скрыть более глобальную проблему – это же естествено, что на корпоративном рабочем сервере недопустимы зависы апача, php, mysql... Если тебе это не очевидно, то давай обсудим,... только в другой теме.

Заодно можно будет обсудить и преимущества/недостатки работы с SVN репозиторием через apache на основании многолетнего опыта и причины побудившие нас использовать именно эту «непацанскую» схему. )

Аватар пользователя Master of Tragedy Master of Tragedy 7 июня 2009 в 15:37

"v1adimir" wrote:
Повторюсь. ) Не все разработчики знают линукс настолько, что бы в нем работать. Поэтому, да, приходится извращаться.

Я тоже повторюсь. Каким образом разработчик будет использовать возможности предлагаемого вами решения не зная основ работы с юникс-системами?

Аватар пользователя v1adimir v1adimir 8 июня 2009 в 7:14

Master of Tragedy wrote:
"v1adimir" wrote:
Повторюсь. ) Не все разработчики знают линукс настолько, что бы в нем работать. Поэтому, да, приходится извращаться.

Я тоже повторюсь. Каким образом разработчик будет использовать возможности предлагаемого вами решения не зная основ работы с юникс-системами?

Сложно научить полноценной работе под линуксовым десктопом. Там все незнакомое и «неправильное». Запомнить для начала /etc/init.d/apache force-reload, плюс еще десяток комманд, можно за один день.

Аватар пользователя Fanny@drupal.org Fanny@drupal.org 7 июня 2009 в 22:47

Если говорим про vwware - то упомянем еще virtualbox

Бесплатно. И работает, надо сказать. Использую обычно в качестве отдельного стола под ubuntu с полноэкранной xp. Очень удобно.

Аватар пользователя Azerot Azerot 7 июня 2009 в 23:13

vmware хороший вариант, однако очень даже небесплатный.
А цена лицензии на vmware сервер позволяет тупо купить отдельную железку под нужны разработки.

Аватар пользователя v1adimir v1adimir 8 июня 2009 в 6:57

2 PVasili

Когда в друпале мне нужно указать путь до exe-шника ImageMagick, какой из придложенных ниже вариантов будет/не будет работать? Только ответь, плз, не ставя экспериментов и не подглядывая в руководство. )

  1. C:\Program Files\ImageMagick-6.3.8-Q16\convert.exe
  2. C:\\Program\ Files\\ImageMagick-6.3.8-Q16\\convert.exe
  3. C:\IMAGEM~1.8-Q\IMAGEM~1.8-Q\CONVERT.EXE
  4. что-то еще...

Использование различных систем, это возможность выбора для каждой задачи оптимального инструментария. Если мы можем себе это позволить, то почему бы и нет. )

А насчет виндовой консоли... да можно пользоваться и ей, но после bash очень тяжело.

Аватар пользователя PVasili PVasili 8 июня 2009 в 10:28

"Ilya1st" wrote:
было время сидел под виндой и ни разу не ставил этот пакет. не знал что это :)
- вероятно, это было очень давно, когда пакет был в одной из первых альфа версий :).
Сейчас же, ни кто под win, не будет городить предлагаемый велосипед.
В крайнем случае, если уж совсем припрёт, в чём я сомневаюсь(ибо нет ни одного примера успеха), поставит *nix как 2 OS.

Аватар пользователя v1adimir v1adimir 8 июня 2009 в 10:45

Прежде чем рассуждать про велосипеды, ответь на задачку из моего предыдущего поста. Я серьезно!

И вообще, откуда такое инфернальное неприятие *nix'ов? Последствия общения с тех.поддержкой хостинга?

Аватар пользователя Azerot Azerot 8 июня 2009 в 11:23

Парадокс использования Denwer'а в том, что люди разрабатывают сайты на локальном хосте, используя Denwer, а потом один леший несут свои сайты на хостинг с UNIX/Linux.

Аватар пользователя Demimurych Demimurych 8 июня 2009 в 18:33

"v1adimir" wrote:
Пытаешься отсылками к частностям скрыть более глобальную проблему – это же естествено, что на корпоративном рабочем сервере недопустимы зависы апача, php, mysql... Если тебе это не очевидно, то давай обсудим,... только в другой теме.
Заодно можно будет обсудить и преимущества/недостатки работы с SVN репозиторием через apache на основании многолетнего опыта и причины побудившие нас использовать именно эту «непацанскую» схему. )

Для меня нет.
В любой мало мальски уважающей конторе корпоративная среда не пересекается со средой разработки. Мне одному кажется очевдным что сервер у которого аптайм должен быть 99% времени не может выступать и платформой для разработчиков. Неговря уже о том, что к такому серверу никаких вебмастеров в приципе подпусктаь нельзя.

И это не говоря еще о том, что у тебя вебмастер должен владеть навыками системного администратора.

На твоем месте я бы все таки сходил по ссылкам. И прочел. ЗАЧЕМ был сделан специальный свн сервер.

In the other corner is svnserve: a small, lightweight server program that speaks a custom protocol with clients. Because its protocol is explicitly designed for Subversion and is stateful (unlike HTTP), it provides significantly faster network operations—but at the cost of some features as well. While it can use SASL to provide a variety of authentication and encryption options, it has no logging or built-in web browsing. It is, however, extremely easy to set up and is often the best option for small teams just starting out with Subversion.
A third option is to use svnserve tunneled over an SSH connection. Even though this scenario still uses svnserve, it differs quite a bit in features from a traditional svnserve deployment. SSH is used to encrypt all communication. SSH is also used exclusively to authenticate, so real system accounts are required on the server host (unlike vanilla svnserve, which has its own private user accounts). Finally, because this setup requires that each user spawn a private, temporary svnserve process, it's equivalent (from a permissions point of view) to allowing a group of local users to all access the repository via file:// URLs. Path-based access control has no meaning, since each user is accessing the repository database files directly.

Так вот, причны твоей непацанской схемы в том, что работа черзе http сконфигурирована по умолчанию. Как наболее простая. Для того чтобы в кратчайший срок поднять работающий subversion. видимо у кого то вебмастера совместители с должностью системных админисраторов и у них просто физически нет времени, разобраться в том как это ДОЛЖНО работать.

Аватар пользователя v1adimir v1adimir 9 июня 2009 в 9:02

Demimurych wrote:
...В любой мало мальски уважающей конторе корпоративная среда не пересекается со средой разработки. Мне одному кажется очевдным что сервер у которого аптайм должен быть 99% времени не может выступать и платформой для разработчиков. Неговря уже о том, что к такому серверу никаких вебмастеров в приципе подпусктаь нельзя...

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

Насчет subversion... в процитированном тобой отрывке ключевые слова "...svnserve: ...— but at the cost of some features..." Во время запуска системы контроля версий для нас были критичны именно эти "features", точка!

Думаю, что аналогичными соображениями руководствовались, в частности, googlecode и sourceforge выбирая в качестве протокола для subversion http и https.

Аватар пользователя ihappy ihappy 4 сентября 2009 в 6:35

"Химический Али" wrote:
Крутые мыжики собрались, словами ругаются всякими. Послушаю.

я тут рядом присяду.. послушаю мужиков.. тоже интересно слова всякие послушать..

Аватар пользователя v1adimir v1adimir 4 сентября 2009 в 14:14

если наблюдать молча, то ничего интересного не услышишь, нужно обязательно что-нибудь задвинуть. )
предлагаю темы:

  • linux нужен только извращенцам;
  • denwer – cool!
  • и ваще винда в 100 тыс.раз приятнее для работы;
  • subversion – не нужен;
  • во всем виноват Чубайс!
Аватар пользователя ihappy ihappy 5 сентября 2009 в 9:50

"v1adimir" wrote:
linux нужен только извращенцам;
"v1adimir" wrote:

А МакОс только для школьников.

"v1adimir" wrote:
denwer – cool!

Денвер таки кууул!

"v1adimir" wrote:
и ваще винда в 100 тыс.раз приятнее для работы;

я лично всегда думал что ОС это прокладка... она должна быть вообще не заметной.
так что затрудняюсь ответить на это утверждение. ибо работаю с софтом а не с Ос)

"v1adimir" wrote:
subversion – не нужен;

так я про что? нафиг нафиг. жили без него и будем жить.. придумают блин...

"v1adimir" wrote:
во всем виноват Чубайс!

и святая нога чакнориса покарает его...

да прибудет сила!

Аватар пользователя Nick.Tereh Nick.Tereh 13 сентября 2009 в 5:23

"v1adimir" wrote:
Среда выполнения apache + mysql + php должна быть *nix'овой. CoLinux, как решение, проверенно и полностью нас устраивает.

Спасибо большое!
Очень удобно. Правда я использую клон - andLinux.
Особенно порадовали ярлыки для программ в быстром запуске. Не ожидал, такой интеграции. Порой не знаешь, где windows-программа, а где Linux.
Вспоминаю негативный опыт использования денвера. Вместо разработки сайта, вся работа сводилась к решению необъяснимых проблем и глюков. Тогда это воспринималась как норма. Ещё тогда успел посоветовать денвер одному опытному фрилансеру, которого на работе отлучили от интернета. Так он за два дня чуть не поседел. То одно не работает, то другое. В конце концов поставил Linux на ноутбук и все проблемы сами разрешились.
Возможно сейчас дела с Денвером гораздо лучше. Но осадок остался. Да и разница между Linux и Windows такая же большая как между чаем и кофе. Вылазят совершенно разные баги. Какой смысл прокачивать себя в использовании apache под windows, если в жизни такая связка редко используется? Даже при трудоустройстве опыт использования Денвера попросту не котируется в отличии от опыта администрирования Linux.

CoLinux - один из лучших способов для изучения Linux. Он очень дружелюбный для пользователя, программы в том числе и друпал устанавливаются из панели управления нажатием пары кнопок. Для новичков CoLinux - отличная среда для изучения Linux, не отрываясь от windows и без необходимости установки операционной системы. То есть вы получаете домашний VDS (VPS). Всё как на хостинге.

Если Вас полностью устраивает Денвер, оставайтесь с ним. Мой первый сайт проработал на нём почти 2 года. Правда пару раз пришлось базу восстанавливать. Возможно это было связано с используемой CMS.
Если Вы планируете покупать VDS и самостоятельно его настраивать, то потренируйтесь сначала на кошках. Даже программисты со знаниями командной строки Linux и SSH ощутимо выигрывают по скорости работы и эффективности, когда нужно перенести сайт, сделать бэкап или обновить drupal.

Это моё скромное мнение. Ни с кем не спорю и не опровергаю. Просто рассказал о другой стороне, с которой приходилось сталкиваться.