Здравствуйте, itslave, Вы писали:
I>Вот подумываю свалить обратно на SVN(в первую очередь из-за полного произвола в авторстве ченджсетов). Неделя приседаний коту под хвост. У git-а говорят все еще печальней с точки зрения настройки-интеграции. Про bazaar даже не вспоминаю.
TFS? Благо на "попробовать" много времени не надо. В связи с http://tfs.visualstudio.com/ пробовать стало еще проще — все серверные проблемы перенял МС.
Здравствуйте, jazzer, Вы писали:
A>>Большая часть ваших проблем от того что вы решили всё прикрутить к IIS. J>Странный подход... А если IIS — корпоративный стандарт и нельзя больше ничего, кроме него? J>У IIS не такая маленькая доля на рынке, особенно в корпоративном сегменте, чтоб называющийся серьезным софт мог на него забивать
Блин, ребят, ну вы даёте. Apache vs IIS против hgweb.cgi который, извинияюсь *** хотел ложить и на первого и второго.
На IIS ставится hg вообще без проблем. При том, я использую такую некузявую конфигурацию — разрешен basic и windows auth, браузером — пожалуйста виндовс ауф, — хг — видимо басик. Я давно не переконфигурял. Из дома я вот с битбаткетом работают через ssh. Это клёво. Только это хрень собачья, потому что это тоже самое должно работать за прокси, а оно не работает, ибо SSH!
IIS vs Apache из всего этого — наименьшая проблема.
Здравствуйте, itslave, Вы писали:
I>Да. Это может потребоваться один раз в 20 лет, но тогда это действительно понадобится. На моей практике был капитальный один разбор по сорцам годичной давности, с твердым намерением "уволить виноватого". Но виноватый этого разбора не дождался и свалил за несколько месяцев до него.
Так это саботаж был или нет? Мне почему-то кажется, что год назад этот парень никак не думал комитить эти исходники под чужим именем.
Обычно для таких случаев достаточно хранить логи, кто и с какого компьютера засунул изменения в основной репо и если человек утверждает, что комит с его именем делал не он — просто поднять их.
Здравствуйте, rm822, Вы писали:
R>Большая часть этого безобразия есть в перфорсе
R>-возможность работать в оффлайне R>только для галочки, реально полный отстой R>они считают это идеологически неверным ходом для _коммерческой_ разработки (и я с ними согласен)
Вот я занимаюсь вполне себе коммерческой разработкой и при этом не вижу никакой реальной причины на каждый чих связываться с сервером.
Если я разрабатываю какую-то фичу, я могу её коммитить хоть сидя на даче без интернета месяц по строке, потом перегруппировать локальные коммиты, сделать rebase на свежий код и потом наконец отправить на review (где мы сейчас на gerrit'е), или просто запушить, если простой центральный. Нафига мне при этом в процессе именно разработки связь с центром?
Объясните, пожалуйста.
Здравствуйте, jazzer, Вы писали:
J>>>Это, конечно, тоже вариант, но я бы лично его не разрешил, учитывая, что апач может шариться несколькими подобными инсталляциями (например, какая-нть вики тоже потребует своего апача — и чего?) и рассматривал бы отдельно апач и отдельно меркуриал. Не говоря уже о том, что апач на 80 порте должен работать из-под рута. A>>Из под рута только bind+listen+accept делается, реальная обработка запроса (recv/send) происходит в контексте www-data J>Тем не менее сервер надо стартовать под рутом, не?
Вообще-то это уже с надцать лет не так, и не только в Linux. Все расширенные системы безопасности (а в любом современном дистрибутиве есть какая-то из них, чаще всего) позволяют произвольный доступ. Например, вот базовые описания для SELinux (см. субкоманду port) и grsec базовое описание, как разрешать доступ конкретной программе без рута. В BSD, включая MacOS, есть MAC инфраструктура для того же. То, что установки "из коробки" по умолчанию не делают этого, не значит, что его нет.
А ещё никто не мешает, например, ввести в локальный iptables правило вида -t nat -p tcp --dport 80 -j REDIRECT --to-ports 8000, и все входящие TCP на порт 80 пойдут (в данном примере) на порт 8000.
Так что прошу не делать сейчас выводы из знания матчасти на 20 лет назад.
J>А одно это — уже большая головная боль для любого безопасника, а уж плагинная система апача — это вообще одна большая дыра.
Плагинная система апача инициализируется ещё до принятия конкретных запросов, а принимает запросы после сокращения прав. Так что здесь она не в состоянии ничего испортить. Если стартовые конфиги не испорчены, то максимум вреда от неё всё равно ограничен пользователем, под которым идёт работа.
Если что-то тут и вредит, то политика suexec'ов (например, в Debian он ужесточён в совершенно бессмысленную сторону).
A>>Тот же кто SVN/TFS поменяет на HG. Я реально не поменяю почему замена VCS это меньшая проблема, чем добавление веб-сервера. J>Очень просто. VCS обычно идет по графе Developer tools, вместе со всякими библиотеками и прочими решарперами, и рулится это обычно только отделом разработки с гораздо более мягкой политикой. А вот веб-сервер — это глобальная вещь, которая, в принципе, может смотреть наружу и дает доступ внутрь сети извне, и должна огораживаться с соответствующий строгостью.
Если developer tool, а конкретно, VCS требует доступа снаружи (а часто это так и есть), то у неё возникают такие же проблемы.
A>>Это IIS говорит — хрен вам, а не гибкая авторизация. И уже отсюда возникает вопрос об Apache. А Mercurial просто не дублирует то что Apache и так делает хорошо. J>Да я ж не спорю, что Апач лучше ИИСа. Я говорю только о том, что в корпоративном сегменте обычно не разрешают ставить что попало, и поэтому любой софт, который хочет в корпоративный сегмент пробиться, должен поддерживать то, что там чаще всего используется, и ИИС в этот список, разумеется, входит. А без этого это будет инструментов опенсорсников, о чем, в принципе, и говорят приведенные комменты его разработчиков.
Тогда тот же IIS должен, кроме формального выполнения под ним, обеспечивать ограничения исполняемого. А это уже далеко не всегда возможно. По современному состоянию проще запустить виртуалку, ограничив ей доступ даже в локалку только безусловно необходимым.
Здравствуйте, itslave, Вы писали:
RO>>Ты подходишь к Mercurial с мерками централизованных систем контроля версий. А она так не работает. Типичный процесс: Вася реализовал какую-то функциональность, Петя взял Васины коммиты напрямую у него и на их основе сделал что-то еще, после чего произвел push в общий репозиторий. Получается, аутентифицировался Петя, но отправил в числе прочего Васины коммиты. I>Да неважно откуда Петя взял данные: с гугля, у Васи, из головы. Важно то что именно Вася запостил их не проверив в центральный репозитарий. Значит в случае чего он должен огрести.
Нет, Вася не отправлял их туда, в том-то и дело!
1. Вася реализует нечто, как proof-of-concept. Коммитит в свой локальный репозиторий, и, возможно, в отдельную особо отмеченную ветку центрального репозитория.
2. Петя видит, что Васина работа поможет ему решить стоящую перед ним задачу. Он берет Васины коммиты (полностью или частично) и на их основе делает что-то свое.
3. Петина работа готова. Он прогоняет тесты, вешает тег о том, что такой-то тикет закрыт, подписывает и то ли сам коммитит в основную ветку центрального репозитория, то ли посылает pull request специально обученному человеку.
Вдруг что пошло не так — Вася никогда не обещал, что его код на 100% готов и работоспособен. А вот Петя берет на себя такую ответственность.
И еще, если система безопасности смотрит только на автора коммита, то можно провести replay attack — взять какой-нибудь промежуточный недоделанный коммит, вносящий уязвимость, и закоммитить в основную ветку от имени автора.
A>>>>В Линуксе все сервера слушающие порт с номером меньше 1024 стартуют под рутом. Нет только веб,вообще все. Так там сокеты работают. J>>>Да, а еще 2+2=4. К чему этот ликбез для первоклассников, да еще и повторенный дважды? J>>>К любой программе, стартующей под рутом, должны применяться повышенные требования безопасности. Точка. C>>Ну поставь lighttpd и сделай проксирование на порт, скажем, 1080. Под которым и запускай Апач. Какие проблемы-то?
Я наверное сейчас очень глупый вопрос задам, но что мешает запустить этот многострадальный апач на порту выше 1024 не под рутом? И не страдать с безопасностью?
I>Т.е. люди не понимают что ревью ченджсетов(регулярное или из-за факапа) — ет таки отвественная процедура, по результатам которой нахомутавший может огрести по самое не могу, вплоть до увольнений в особо запущенных случаях. И кодревьюеру надо просто и ясно видеть, кто запушил чейнджсет в репозитарий. I>Но мое мнение о hg осталось неизменно: для корпоративной бизнес разработке в среде windows он не годится.
В subversion "имя пользователя", который сделал коммит — это revision property, изменения которого не трекаются. Да, по умолчанию оно отключено — но если речь идет о саботаже и увольнении, то поменять задним числом не так трудно.
Тут вы, на мой взгляд, столкнулись с архитектурным вопросом. Subversion — централизованный репозиторий. Коммитера можно поменять задним числом, если есть доступ к репозиторию. Mercurial — у каждого репозиторий. Коммитера можно поменять... ну вы поняли . Поэтому с точки зрения безопасности в subversion от диверсий защищаются, блокируя репозиторий от нежелательных модификаций (и это ключено по умолчанию). В mercurial защищаются точно также — блакируют центральный репозиторий от нежелательных модификаций. Так как какой репозиторий "центральный" назначаете вы — то и хук на проверку стаить вам. Плата за гибкость .
Здравствуйте, Eye of Hell, Вы писали:
EH> I>Т.е. люди не понимают что ревью ченджсетов(регулярное или из-за факапа) — ет таки отвественная процедура, по результатам которой нахомутавший может огрести по самое не могу, вплоть до увольнений в особо запущенных случаях. И кодревьюеру надо просто и ясно видеть, кто запушил чейнджсет в репозитарий. EH> I>Но мое мнение о hg осталось неизменно: для корпоративной бизнес разработке в среде windows он не годится. EH> В subversion "имя пользователя", который сделал коммит — это revision property, изменения которого не трекаются. Да, по умолчанию оно отключено — но если речь идет о саботаже и увольнении, то поменять задним числом не так трудно.
Кстати да, от саботажа hg/git защищены гораздо лучше. В случае svn достаточно получить доступ к центральному репозиторию, чтобы всё нахакать как нравится — комар носу не подточит. А в случае hg/git незаметно историю поменять задним числом невозможно — поменяются все sha1 идентификаторы всех коммитов после, что вызовет полный ах во всех клонах, в логах билд серверов, в версиях артефактов, и т.п. А sha1 криптоустойчивый хеш, кстати говоря. А ещё pgp-подписи тегов есть...
Здравствуйте, jazzer, Вы писали:
j> A>Большая часть ваших проблем от того что вы решили всё прикрутить к IIS. j> Странный подход... А если IIS — корпоративный стандарт и нельзя больше ничего, кроме него?
Тогда количество приемлемых вариантов резко сужается до продуктов MS.
j> У IIS не такая маленькая доля на рынке, особенно в корпоративном сегменте, чтоб называющийся серьезным софт мог на него забивать
Попробуй посмотреть на это с другой стороны: "У mercurial не такая маленькая доля на рынке, чтобы называющийся серьезным веб-сервер мог на него забивать" — сказка о курице и яйце. mercurial прекрасно работает в корпоративном сегменте, если этот корпоративный сегмент готов его принять. Вы пока не можете — ну чтож, это не фатально — используйте TFS или любой другой продукт, к которому вы пока готовы — в этом и вся прелесть свободы выбора.
Apache vs IIS против hgweb.cgi который, извинияюсь *** хотел ложить и на первого и второго. 
.
