Комментарии 909
распечатать & сжечь — а-ля культ Вуду? ;)
У нас свои методы :-)
Это ппц, авации, браво.
Новость года, однозначно.
Новость года, однозначно.
колитесь, кто получил еще уведомление? )
Да, только года-то 2008.
www.scottbarnham.com/blog/2008/04/22/serving-websites-from-svn-checkout-considered-harmful/
www.scottbarnham.com/blog/2008/04/22/serving-websites-from-svn-checkout-considered-harmful/
Дайте-ка посмотреть, — Воланд протянул руку ладонью кверху.
— Я, к сожалению, не могу этого сделать, — ответил мастер, — потому что я сжег его в печке.
— Простите, не поверю, — ответил Воланд, — этого быть не может. Рукописи не горят. — Он повернулся к Бегемоту и сказал: — Ну-ка, Бегемот, дай сюда роман.
Кот моментально вскочил со стула, и все увидели, что он сидел на толстой пачке рукописей. Верхний экземпляр кот с поклоном подал Воланду
М.А.Булгаков, «Мастер и Маргарита»
Нужно было скурить)
Это ш пипец!
Я думаю, вы не понимаете всей звиздецовости ситуации.
> Были подняты прокси-сервера, написан парсер и получена свежая база доменов в зоне ru.
Они сканировали только зону .RU, а есть еще .COM, .NET, .ORG и больше сотни национальных TLD…
> Были подняты прокси-сервера, написан парсер и получена свежая база доменов в зоне ru.
Они сканировали только зону .RU, а есть еще .COM, .NET, .ORG и больше сотни национальных TLD…
Да, вы правы. Но предупредить ВСЕХ физически невозможно. Поэтому было решено придать делу максимальную огласку, чтобы потенциально уязвимые в прочих зонах смогли оперативно все закрыть.
На каких англоязычных ресурсах разместили инфу?
НЛО прилетело и опубликовало эту надпись здесь
Сайты, сделанные грамотными разработчиками и обслуживаемые опытными администраторами — в безопасности, а то что поломают 10-долларовый сайт на 5-долларовом хостинге, никому не грозит, не разводите панику.
Угу. yandex тому примером.
Типичный пример «10-долларовый сайт на 5-долларовом хостинге»:
apache.org/.svn/entries
apache.org/.svn/entries
Apache это же OpenSource, что там украдешь? Мануал по апачу что ли?? Ну вы смешной, как можно украсть то, что и так открыто ))
p.s. И вообще, я думаю опенсурсу к взломам не привыкать, в открытых движках постоянно находят уязвимости
p.p.s И вообще, ломать опенсоурс сайты или вредить их деятельности — бесчеловечно и низко, я считаю.
p.s. И вообще, я думаю опенсурсу к взломам не привыкать, в открытых движках постоянно находят уязвимости
p.p.s И вообще, ломать опенсоурс сайты или вредить их деятельности — бесчеловечно и низко, я считаю.
classmates.com, bolero.ru? Примеры взяты из комментариям к этой же записи, думаю вы при желании и еще примеров почерпнуть сможете.
Я конечно не видел западные classmates, но если это то же, что и наши «одноклассники», пусть их ломают. это позор рунета, я считаю.
И кстати, с чего вы взяли что крупные сайты делаются квалифицированными разработчиками? Может clssmates индусы делают (это к слову о 10-долларовых сайтах, не надо понимать что он и в самом деле столько стоит)?
И кстати, с чего вы взяли что крупные сайты делаются квалифицированными разработчиками? Может clssmates индусы делают (это к слову о 10-долларовых сайтах, не надо понимать что он и в самом деле столько стоит)?
ну этим-то точно можно не запариваться:)
До сих пор лог не закрыт…
НЛО прилетело и опубликовало эту надпись здесь
Уязвимы все, вот только степень уязвимости неодинакова.
Так, ребята юзающие git! Мы тоже уязвимы в случае, если корень репозитория доступен из веба.
Причем исходники сливаются очень красиво, не надо писать никаких парсеров:
git clone example.com/.git/
К счастью, в большинстве случаев корень репа, а значит и папка .git закрыты извне.
ПС: Кто-нибудь, переведите эту статью на английский!
Причем исходники сливаются очень красиво, не надо писать никаких парсеров:
git clone example.com/.git/
К счастью, в большинстве случаев корень репа, а значит и папка .git закрыты извне.
ПС: Кто-нибудь, переведите эту статью на английский!
Для git предлагаю вот такие сниппеты экспорта:
1. Если репозитарий на продакшн сервере. Из корня репозитария:
git checkout-index -a -f --prefix=<destination e.g. /var/www>
2. Если репозитарий на удаленном сервере. Из корня вебсервера:
git-archive --format=tar --remote=ssh://:/<repo_path> master | tar -xf -
1. Если репозитарий на продакшн сервере. Из корня репозитария:
git checkout-index -a -f --prefix=<destination e.g. /var/www>
2. Если репозитарий на удаленном сервере. Из корня вебсервера:
git-archive --format=tar --remote=ssh://:/<repo_path> master | tar -xf -
Значит, все-таки, не так бесполезна предложенная мной чуть более чем полтора года назад система защиты ini-фалйов на веб-серверах!
bolzamo.org.ru/82/
bolzamo.org.ru/82/
Бесполезна, есть 3 способа проще: 1) хранить ini файлы в отдельной закрытой извне папке 2) хранить код вне корня сайта (т е вообще недоступным извне) 3) прописать в htaccess/конфиг сервера запрет на доступ к *.ini, ваше решение — детский сад.
ну да, в целом все верно… За исключением того момента, что хостеры порой бывают настолько суровы, что закрывают клиентам возможность настраивать сервер через .htaccess. Явление редкое, но в природе все-таки встречающееся. Кроме того, закрывать возможность скачивать ini-файлы — бред, так как возникнут сложности с публикацией каких-нибудь конфигов для it-шных сайтов.
А расположение же настроек вне корня сайтов… Ну скажем так, пользователь продукта врядли поймет благородные мотивы разработчика, который в описание процесса установки впишет размещение каталога вне корня сайта. Скорее всего такой разработчик будет сначала трижды проклят, а потом уже, возможно, понят.
Некоторые разработчики суеверны, и не любят, когда их проклинают.
А расположение же настроек вне корня сайтов… Ну скажем так, пользователь продукта врядли поймет благородные мотивы разработчика, который в описание процесса установки впишет размещение каталога вне корня сайта. Скорее всего такой разработчик будет сначала трижды проклят, а потом уже, возможно, понят.
Некоторые разработчики суеверны, и не любят, когда их проклинают.
Суровых хостеров — в топку. На моем « элитном» бесплаьном хостинге хтаккесс разрешен.
> Ну скажем так, пользователь продукта врядли поймет благородные мотивы разработчика, который в описание процесса установки впишет размещение каталога вне корня сайта.
Можно напистаь установщик, кроме того нормальныен сайты устанавливает разработчик а не заказчик.
> Ну скажем так, пользователь продукта врядли поймет благородные мотивы разработчика, который в описание процесса установки впишет размещение каталога вне корня сайта.
Можно напистаь установщик, кроме того нормальныен сайты устанавливает разработчик а не заказчик.
А нормальный сферический конь в вакууме ростом один метр и весом один килограмм должен двигаться со скоростью 1м/ч без ускорения.
Не придумывайте, если у вас даже нет возможности править htaccess, это ваши проблемы, и решение с комментированием — изврат и муть. А еслив .ini встретится последвательность '*/', a?
ы! А об этом я как-то в свое время не подумал… Ну тогда php-парсер умрет с ошибкой, но секретных данных не выдаст. Что же до отсутствие возможности править .htaccess — реально бывали такие случаи, и «это ваши проблемы» сказать можно, а можно подсказать решение для тех, чьи это проблемы, что я собсна и сделал. Моя проблема как разработчика — заставить свое творение работать с наименьшими запросами к среде окружения, и без капризов по поводу мелких серверных настроек.
Но насчет последовательности — улыбнуло, плюсанул :)
Но насчет последовательности — улыбнуло, плюсанул :)
Оу, можно смело сказать:
Галактеко опасносте!
*Поставил наблюдение за тостером. Кто их занет
Галактеко опасносте!
*Поставил наблюдение за тостером. Кто их занет
Аплодисменты.
Проблема в отсутствии/квалификации CSO, и банальная лень админов написать инсталятор для выкатки кода на продакшн. Любой сканер уязвимостей находит такие директории.
В Яндексе и Опере ленивые админы? Но уж точно не параноики :-) «как страшно жить» (с)
А вообще — да, болезнь на удивление детская.
А вообще — да, болезнь на удивление детская.
они бы еще где нибудь рядом архив с исходниками положили и думали, а мало ли не найдут! Причем тут SVN? Проблема, ИМХО, в лени.
Видимо проблема в том что разработкой занимаются одни люди, а настройкой установкой и обслуживанием серверов — другие, отсюда и бестолковость и дыры в безопасности. Я, когда ставил SNV, первым делом подумал, что это дыра в безопасности (вторым подумал — надо проверить, нет ли этой дыры на Хабре ;) ). Уверен, что любые ответственные разработчики делают также.
Это дыра из серии, «положу install.php в корень, никто же не знает что он тут лежит». Детский сад, ей богу.
Раскрытие исходных кодов не должно приводить к уязвимостям.
Это дыра из серии, «положу install.php в корень, никто же не знает что он тут лежит». Детский сад, ей богу.
Раскрытие исходных кодов не должно приводить к уязвимостям.
плюс миллиард.
это просто тупо лень и низкая квалификация. Эта новость скорее повергла меня в гнев и обида за тех разработчиков, которые не поняли очевидного «левак в паблике, да ещё и не собственноручно генерируемый — потенциальная опасность в любом случае». И не важно какой это левак. .svn это канеш совсем верх совершенства, но даже .htaccess это УЖЕ идиотизм. И это не паранойа, это совсем другой подход «программа — слева, код — справа».
это просто тупо лень и низкая квалификация. Эта новость скорее повергла меня в гнев и обида за тех разработчиков, которые не поняли очевидного «левак в паблике, да ещё и не собственноручно генерируемый — потенциальная опасность в любом случае». И не важно какой это левак. .svn это канеш совсем верх совершенства, но даже .htaccess это УЖЕ идиотизм. И это не паранойа, это совсем другой подход «программа — слева, код — справа».
Мало того, есть люди, которые прочитали эту новость на хабре и ничего не сделали у себя на проекте. Притом, что .svn имеется и некоторую инфу от туда вытащить можно.
Вот это действительно лень… притом, в мне известных случаях, программистов…
Или отложили действия на время прихода музы подобных действий…
Вот это действительно лень… притом, в мне известных случаях, программистов…
Или отложили действия на время прихода музы подобных действий…
Seriously?
Офигеть.
Статья очень похожа на «Продам исходные коды яндекса и других гигантов».
Но тем не менее страшно интересно:
1. чем все закончится с гигантами.
2. ещё десяток интересных фактов о сайтах.
3. чем защищались остальные 2253388-3320 порталов, если у них есть директория svn
Но тем не менее страшно интересно:
1. чем все закончится с гигантами.
2. ещё десяток интересных фактов о сайтах.
3. чем защищались остальные 2253388-3320 порталов, если у них есть директория svn
>3. чем защищались остальные 2253388-3320 порталов, если у них есть директория svn
там просто не работали по SVN, либо уже были защищены.
там просто не работали по SVN, либо уже были защищены.
1. Мы дождались пока все гиганты закрыли уязвимость, только затем опубликовали топик.
2. Возможно будет апдейт или новый пост, как наберем достаточно интересного.
3. Под раздачу попали крупные сайты именно потому что в них ведется командная разработка. Остальные сайты разрабатываются либо одним человеком, либо без использования SVN.
2. Возможно будет апдейт или новый пост, как наберем достаточно интересного.
3. Под раздачу попали крупные сайты именно потому что в них ведется командная разработка. Остальные сайты разрабатываются либо одним человеком, либо без использования SVN.
НЛО прилетело и опубликовало эту надпись здесь
Дотком-то поставили сканить? ;)
Медленно, но верно?
Медленно, но верно?
2. ещё десяток интересных фактов о сайтах
тоже хочу это!
тоже хочу это!
по пункту — 3. Остальные сайты разрабатываются либо одним человеком, либо без использования SVN.
Разрабатываться то они могли и с SVN, вот только разработчки отбкатав тесты, не поленились сделать экспорт на «боевой» сервер, а не разрабатывать на нём.
Разрабатываться то они могли и с SVN, вот только разработчки отбкатав тесты, не поленились сделать экспорт на «боевой» сервер, а не разрабатывать на нём.
Скорее, это очень оригигнальное СV.
Хочется больше интимных подробностей :-)
1) так а если поставить аутентификацию по .htpasswd?
2) не представляю, как узнать домен, на котором у Яндекса репозиторий
2) не представляю, как узнать домен, на котором у Яндекса репозиторий
Адрес репозитория как раз и написан в .svn/entries.
я наверно тупой. У меня сайт site.ru. На нем последняя ревизия, экспортированная (папки svn нету вовсе). Репозиторий расположен где-то в совершенно другом месте. Как Вы узнаете его адрес?
НЛО прилетело и опубликовало эту надпись здесь
если вы не выносили в настройках svn папки .svn в другое место, то при чекауте из репозитория, или апдейте они создаются в каждой папке.
В таком случае вы все сделали правильно, и не страдаете данной уязвимостью. Речь о другом. Народ вон рабочие копии выкладывает.
2) Репозиторий на закрытом хосте. Так что это бесполезно. А вот список файлов засветили, это да.
Спасибо за информацию.
Пошёл закрывать дыру на своих сайтах :)
Пошёл закрывать дыру на своих сайтах :)
Если проект написан на Ruby-on-Rails, то никакой уязвимости и быть не может.
Структура не позволяет (в паблике токо рисунки и джаваскрипты)
Структура не позволяет (в паблике токо рисунки и джаваскрипты)
А рисунки и джаваскрипты вне контроля версий?
В контроле версий, но что с ними можно сделать такого, что поломает сайт?
git с hg не создают в каждой папке свои .git и .hg каталоги, только в корне. Замусоривать все своими папками — это особенность svn)
яваскрипты и картинки и так можно скачать :)
Хахаха!
Интересно, в конфиге Apache по-умолчанию будет запрет доступа к папкам .svn, как к файлам .ht*?
Мораль — юзайте git =)
У гита есть .git :-)
чтобы по одной папке в корне вытащить все содержимое?
Мораль — читайте мануал по SVN (это я про svn export)
Мораль — юзайте svn export
Юзал — неудобно нифига. Если лежит раб. копия, то видно, какие в ней версии файлов, какие локальные правки — все четко и наглядно. Да и управлять удобнее — svn up (до любой ревизии), svn revert, svn merge.
Также экспорт всей папки с проектом невозможен по причине того, что в папке могут быть неверсионированные файлы, например сессии. Одной командой обновить проект не получиться, придется писать скрипт экспорта — а это лишние телодвижения и лишние проблемы.
Вставить в конфиг апача настройку для закрытости папки .svn намного проще и лучше будет.
Также экспорт всей папки с проектом невозможен по причине того, что в папке могут быть неверсионированные файлы, например сессии. Одной командой обновить проект не получиться, придется писать скрипт экспорта — а это лишние телодвижения и лишние проблемы.
Вставить в конфиг апача настройку для закрытости папки .svn намного проще и лучше будет.
Минус поставили, а теперь, пожалуйста, контраргументы?
Я серьезно, было бы интересно, чем экспорт удобнее рабочей копии, я свои привел в пользу рабочей копии — она гораздо более информативна и управляема.
Я серьезно, было бы интересно, чем экспорт удобнее рабочей копии, я свои привел в пользу рабочей копии — она гораздо более информативна и управляема.
Зачем на production-версии смотреть, «какие в ней версии файлов, какие локальные правки»? Рабочие сырцы вообще надо трогать только один раз при каждом апдейте, всё.
Никаких «svn up (до любой ревизии), svn revert, svn merge» в production быть не должно, это всё должно делать в другом месте, а на рабочую копию исходников должен отражаться только проверенный (протестированный) результат всех этих действий.
Если вы копаетесь в коде прямо на production-сервере, то я право не знаю, что тут можно сказать.
А скрипт писать надо все равно, потому что перед обновлением исходников сайт должен быть закрыт заставкой, а после обновления — открыт.
Никаких «svn up (до любой ревизии), svn revert, svn merge» в production быть не должно, это всё должно делать в другом месте, а на рабочую копию исходников должен отражаться только проверенный (протестированный) результат всех этих действий.
Если вы копаетесь в коде прямо на production-сервере, то я право не знаю, что тут можно сказать.
А скрипт писать надо все равно, потому что перед обновлением исходников сайт должен быть закрыт заставкой, а после обновления — открыт.
Тут много красивее путь Capistrano:
current
system (лежат папки с именем timestamp, вовнутрь которых делается как раз export. Задеплоили — симлинк current указал на последний снапшот.)
shared (some user data, logs, temp, ...)
И капистрано уже делает revert и много чего другого. Конечная цель — на сервер руками перестаешь лазить.
ЗЫ: к минусующим не отношусь.
current
system (лежат папки с именем timestamp, вовнутрь которых делается как раз export. Задеплоили — симлинк current указал на последний снапшот.)
shared (some user data, logs, temp, ...)
И капистрано уже делает revert и много чего другого. Конечная цель — на сервер руками перестаешь лазить.
ЗЫ: к минусующим не отношусь.
Не нашел у вас спорных со мной моментов.
Кто сказал, что я лезу на сервак и там делаю руками svn up? Это не так, все делает скрипт через панельку деплоя. При этом в панельке можно посмотреть результаты обновления (svn diff боевой раб копии проекта с интересующей ревизией) перед обновлением, результаты собстно самого процесса обновления — этого без раб копии не посмотришь.
По поводу отделения обновляемых данных от необновляемых — у меня в раб. копии при ее создании прописывается игнор на неверсионированные папки — аналогия вашему разделению shared/system.
Ну и все-таки имеется специфика, такая, что на сервер руками все же лазят править, хотя я с этим борюсь и это неправильно, но т.к. все-таки это делают, я предпочитаю видеть измененными те файлы, которые изменили на боевом, кстати при svn up эти локальные правки не теряются.
Кто сказал, что я лезу на сервак и там делаю руками svn up? Это не так, все делает скрипт через панельку деплоя. При этом в панельке можно посмотреть результаты обновления (svn diff боевой раб копии проекта с интересующей ревизией) перед обновлением, результаты собстно самого процесса обновления — этого без раб копии не посмотришь.
По поводу отделения обновляемых данных от необновляемых — у меня в раб. копии при ее создании прописывается игнор на неверсионированные папки — аналогия вашему разделению shared/system.
Ну и все-таки имеется специфика, такая, что на сервер руками все же лазят править, хотя я с этим борюсь и это неправильно, но т.к. все-таки это делают, я предпочитаю видеть измененными те файлы, которые изменили на боевом, кстати при svn up эти локальные правки не теряются.
Ок, подробнее:
>Если лежит раб. копия, то видно, какие в ней версии файлов
я и так знаю что за ревизия у меня выкачена на боевой
>какие локальные правки
боже упаси. Зоопарк такой уже проходили, наигрались, увольте.
>svn up (до любой ревизии), svn revert, svn merge.
cap deploy [-s revision=N], cap deploy:rollback…
>в папке могут быть неверсионированные файлы, например сессии.
Опять-таки, все подобное храним вне дерева исходников. Всем от этого жить проще. Пример на пальцах: есть dev-версия и production, и периодически надо вливать живые данные в dev. БД я синхронизирую, а папки от production банально копирую в dev. А так пришлось бы куски выискивать по всему дереву.
>Одной командой обновить проект не получится, придется писать скрипт экспорта
Это делается аж единожды для проекта (а дальше копипастит в другие). Кроме того, скрипт экспорта включает в себя лишь создание правильных ссылок, остальное — на автопилоте (в самом Capistrano уже много чего написано).
Я ни в коем случае не говорю что это не true way, а путь показанный мной — единственно верный. Просто показываю что с моей точки зрения удобнее, так как раньше делал именно так как описали Вы.
>Если лежит раб. копия, то видно, какие в ней версии файлов
я и так знаю что за ревизия у меня выкачена на боевой
>какие локальные правки
боже упаси. Зоопарк такой уже проходили, наигрались, увольте.
>svn up (до любой ревизии), svn revert, svn merge.
cap deploy [-s revision=N], cap deploy:rollback…
>в папке могут быть неверсионированные файлы, например сессии.
Опять-таки, все подобное храним вне дерева исходников. Всем от этого жить проще. Пример на пальцах: есть dev-версия и production, и периодически надо вливать живые данные в dev. БД я синхронизирую, а папки от production банально копирую в dev. А так пришлось бы куски выискивать по всему дереву.
>Одной командой обновить проект не получится, придется писать скрипт экспорта
Это делается аж единожды для проекта (а дальше копипастит в другие). Кроме того, скрипт экспорта включает в себя лишь создание правильных ссылок, остальное — на автопилоте (в самом Capistrano уже много чего написано).
Я ни в коем случае не говорю что это не true way, а путь показанный мной — единственно верный. Просто показываю что с моей точки зрения удобнее, так как раньше делал именно так как описали Вы.
ок, я понял, спасибо, что поделились своим подходом, на заметку возьму софтину обязательно и организацию.
Только я пока остаюсь при своем мнении, т.к. у меня те же цели, что и у вас достигаются проще (без доп. софта и других телодвижений). Единственное, что требуется — понимание работы свн.
И я тоже не говорю, что мой подход суперпупер правильный, но я против тех, кто говорит что раб. копии не место на боевом.
Папки .svn светятся?
Так прикройте их апачем и снаружи не будет никакой разницы между экспортом и раб. копией. Мы свои .svn в корневом конфиге апача закрыли сразу, как перешли к раб. копиям (сначала, кстати экспорт использовали со скриптами).
Только я пока остаюсь при своем мнении, т.к. у меня те же цели, что и у вас достигаются проще (без доп. софта и других телодвижений). Единственное, что требуется — понимание работы свн.
И я тоже не говорю, что мой подход суперпупер правильный, но я против тех, кто говорит что раб. копии не место на боевом.
Папки .svn светятся?
Так прикройте их апачем и снаружи не будет никакой разницы между экспортом и раб. копией. Мы свои .svn в корневом конфиге апача закрыли сразу, как перешли к раб. копиям (сначала, кстати экспорт использовали со скриптами).
> Я ни в коем случае не говорю что это не true way, а путь показанный мной — единственно верный. Просто показываю что с моей точки зрения удобнее, так как раньше делал именно так как описали Вы.
Мне кажется, что ваш методе действительно хорош. Я пару месяцев, после прочтения github.com/blog/470-deployment-script-spring-cleaning, планирую всё таки использовать готовые скрипты автоматизации деплоя.
Пока использую .deb пакеты (собранные на офисном сервере), и делаю apt-get update && apt-get upgrade на каждом сервере ручками.
Раньше использовал rsync исходников с офисной машины (с локальной машины скрипт заходил на офисный сервер, делали git checkout нужной версии, а потом с боевой машины делался rsync на дерево исходников, использовали ssh-forwarding и на продакшене не хранили данные о офисной машине)
Мне кажется, что ваш методе действительно хорош. Я пару месяцев, после прочтения github.com/blog/470-deployment-script-spring-cleaning, планирую всё таки использовать готовые скрипты автоматизации деплоя.
Пока использую .deb пакеты (собранные на офисном сервере), и делаю apt-get update && apt-get upgrade на каждом сервере ручками.
Раньше использовал rsync исходников с офисной машины (с локальной машины скрипт заходил на офисный сервер, делали git checkout нужной версии, а потом с боевой машины делался rsync на дерево исходников, использовали ssh-forwarding и на продакшене не хранили данные о офисной машине)
Капистрано умеет и из локальной версии по rsync'у заливать сорсы на сервер. И с его помощью можно на ферме машин сделать одной командой набор действий, хоть тот же apt-get update && apt-get upgrade (при условии что процесс будет не интерактивным). Я, кстати, так правило для .svn на все сервера сразу разнес ;)
А не опишете процесс создания своего apt-репо и сборку деб-пакетов (с нуля) блогпостом? ;) Я пришел к необходимости создания своего репо с nginx, чтоб все сервера апдейтить как-раз не руками.
А не опишете процесс создания своего apt-репо и сборку деб-пакетов (с нуля) блогпостом? ;) Я пришел к необходимости создания своего репо с nginx, чтоб все сервера апдейтить как-раз не руками.
Обязательно попробую. А из других систем вы что-то пробовали?
Для деплоймента пробовал еще Vlad the Deployer, но он как очень урезаный Capistrano.
Для деплоймента конфигов — Puppet, но не проникся как-то.
Была еще тулза аналогичная владу на питоне — простая довольно. Но я не питонист, увы.
Основная причина выбора именно Capistrano — я программлю на Ruby & Rails. А таски для Capistrano пишутся именно на руби. Убив день-два на то чтоб сним основательно разобраться и поэкспериментировать понимаешь, что этой штуковиной можно сделать все.
Для деплоймента конфигов — Puppet, но не проникся как-то.
Была еще тулза аналогичная владу на питоне — простая довольно. Но я не питонист, увы.
Основная причина выбора именно Capistrano — я программлю на Ruby & Rails. А таски для Capistrano пишутся именно на руби. Убив день-два на то чтоб сним основательно разобраться и поэкспериментировать понимаешь, что этой штуковиной можно сделать все.
Ок, спасибо за инфу. Я с руби никогда не сталкивался, но думаю проблем возникнуть не должно.
По поводу дебиановского репозитория — я не спец в нём и сделал достаточно просто и быстро, без всяких заморочек (создание простого пакета, создание репозитория, выливка пакетов по rsync в репозиторий и обновление его структуры). Из всех функций deb-ов я использовал едва ли 5% (к примеру не использовал цифровую подпись пакетов и при апдейне надо указывать --force-yes).
Если такая информация будет интересна — могу попробовать описать блогпостом. Стоит писать?
По поводу дебиановского репозитория — я не спец в нём и сделал достаточно просто и быстро, без всяких заморочек (создание простого пакета, создание репозитория, выливка пакетов по rsync в репозиторий и обновление его структуры). Из всех функций deb-ов я использовал едва ли 5% (к примеру не использовал цифровую подпись пакетов и при апдейне надо указывать --force-yes).
Если такая информация будет интересна — могу попробовать описать блогпостом. Стоит писать?
мораль — билдите проект.
И отдайте вообще всю историю вашей разработки, а не только последние версии. Ах да, еще и пару экспериментальных веток с мега фичами.
Мда, а везде пишут, что с svn нужно export юзать. Видимо, лень побеждает? :-)
У гита есть .git :-)
Мне вот тоже странно, что большие крупные проекты зачем-то хранят svn-файлы на пордакшне.
У них же всегда тестовый(-е) сервер(-а) есть.
Зачем при этом держать всё дерево на основных серверах — решительно непонятно. Ведь даже если не задумываться о безопасности (что очень сомнительно), есть же ещё и такая вещь, как захламление сервера ненужными файлами.
Есть мнение, что работать от этого быстрее система не будет.
Всегда пользовали export и не парили себе мозг.
У них же всегда тестовый(-е) сервер(-а) есть.
Зачем при этом держать всё дерево на основных серверах — решительно непонятно. Ведь даже если не задумываться о безопасности (что очень сомнительно), есть же ещё и такая вещь, как захламление сервера ненужными файлами.
Есть мнение, что работать от этого быстрее система не будет.
Всегда пользовали export и не парили себе мозг.
а еще есть такая вещь как скорость обновления проэкта из тысяч файлов, после изменения двух
да, такая проблема есть.
поэтому обновление производится в часы «пик-аута» (короче, ночью-утром).
И замедление системы один раз в неделю (условно говоря) лучше, чем небольшое замедление системы постоянно.
к тому же, никаких проблем с файлами, которые срочно пришлось поправить на сервере (ну бывает такое иногда, хотя это нехорошо).
поэтому обновление производится в часы «пик-аута» (короче, ночью-утром).
И замедление системы один раз в неделю (условно говоря) лучше, чем небольшое замедление системы постоянно.
к тому же, никаких проблем с файлами, которые срочно пришлось поправить на сервере (ну бывает такое иногда, хотя это нехорошо).
а куда спешить при обновлении?
экспорт в соседнюю папку и затем замена ей папки с проектом.
экспорт в соседнюю папку и затем замена ей папки с проектом.
Моя интуиция подсказывает мне, что перезаливать тысячи файлов ради двух неверно. Просто нужно разработать/использовать удобный метод обновления файлов: решить эту проблему.
Трагедия! Трагедия!
Почем пепел? :)
Давно пользуюсь SVN и изначально думал, что такое возможно. У меня принцип защиты немного другой: есть скрипт, который выполняет роль build-скрипта, он чекаутит trunk в tmp фолдер, удаляет все .svn, а потом все ложит непосредственно куда надо.
Почему не используйте экспорт?
Виноват, не знал =)
Ага, у меня билд-скрипт тоже просто экспортирует на сервер. Даже представить не мог, что кто-то может использовать рабочую копию.
Ещё в FileZilla есть настройка — игнорировать директории .svn при заливке.
Ещё в FileZilla есть настройка — игнорировать директории .svn при заливке.
хм, поправьте если ошибаюсь, а экспорт разве не обновляет все файлы а не только ревизию, что для гигантов критишно?
=)
Давно написал для простого экспорта от ревизии до ревизии скрипт. Жизнь облегчает неимоверно!
Делюсь:
webiteam.ru/2009/03/eksport-iz-svn/
Давно написал для простого экспорта от ревизии до ревизии скрипт. Жизнь облегчает неимоверно!
Делюсь:
webiteam.ru/2009/03/eksport-iz-svn/
Ребятам, провернувшим все это исследование обеспеченно светлое будущее.
И внеочередные воинские звания.
На свободу с чистой совестью, ага.
Ммм… неправомерный доступ к компьютерной информации?
Ну почему «неправомерный»? Сомневаюсь, что хоть на одном сайте было написано, что в папки .svn нельзя заглядывать ;)
Потому что неправомерный, т.к. информация явяется коммерческой тайной/интеллектуальной собственностью и т.п.
Если кто-то решит всерьез судиться — они своего добьются. Надежда на этику.
Если кто-то решит всерьез судиться — они своего добьются. Надежда на этику.
Бу-бу-бу. Вон, помнится в суде какой-то компании в иске на взлом отказали из-за того, что в баннер, выдаваемый тем сервисом, через который проходил взлом они вставили строку «Welcome...», а не всяческие «посторонним вход воспрещен». Ну правда то в Америке было.
Но все равно, если 80й порт открыт и на нем стоит web-сервер отображающий изначально публичный сайт, то либо уж признавать что любые действия без использования эксплойтов и уязвимостей в программных продуктах не могут быть предметом преследования, либо каждый раз загружая логотип яндекса судорожно размышлять «а вдруг я сейчас несанкционированно его получаю!».
Хотя может это действительно уже больше к этике и здравому смыслу относитя.
Но все равно, если 80й порт открыт и на нем стоит web-сервер отображающий изначально публичный сайт, то либо уж признавать что любые действия без использования эксплойтов и уязвимостей в программных продуктах не могут быть предметом преследования, либо каждый раз загружая логотип яндекса судорожно размышлять «а вдруг я сейчас несанкционированно его получаю!».
Хотя может это действительно уже больше к этике и здравому смыслу относитя.
Большее значение имеет не способ получения информации, а сама информация.
К примеру существующая уязвимость в сервере контроля периметра небольшой компании не должна содержать на себе баннер «Посторонним вход воспрещен» для того, чтобы осудить проникнувшего в сеть. Да, информация не защищена должным образом, нет это не является безнаказанным.
Тут дело в этике. Негласно принято, что исследователи делают доброе дело и сообщают о проблемах из лучших побуждений и не следует на них идти с вилами. До тех пор пока все следуют этике и морали — все хорошо, но если кто-то решит пойти против, могут быть неприятности.
Сделать дело можно на любого.
К примеру существующая уязвимость в сервере контроля периметра небольшой компании не должна содержать на себе баннер «Посторонним вход воспрещен» для того, чтобы осудить проникнувшего в сеть. Да, информация не защищена должным образом, нет это не является безнаказанным.
Тут дело в этике. Негласно принято, что исследователи делают доброе дело и сообщают о проблемах из лучших побуждений и не следует на них идти с вилами. До тех пор пока все следуют этике и морали — все хорошо, но если кто-то решит пойти против, могут быть неприятности.
Сделать дело можно на любого.
Но если Вы свои пасортные данные выложите в открытый доступ, вряд ли Вы станете потом судиться со всеми, кто их мог видеть, а если и станете, то вряд ли сможете «своего добиться». Информация-то по теме поста была в открытом доступе, так что никакого смысла судиться нет.
Красавцы :)
Коды вконтакта и одноглазников почем? :))) За 10% подгоню покупателя )))))
Там же говнокод… зачем?
Насчет первого — врядли имхо.
То, что снаружи хорошо не всегда хорошо внутри… и наоборот.
Ну скажем так, кода никто из нас не видел, про одноклассники наверное слышали байки.
Качество кода не знаю, но задача решена хорошо потому что
а) все работает быстро. Значит код как минимум хорошо масштабируется (не все можно смасштабировать просто поставив доп. сервер и скопировав на него код с первого и пустив в режиме round-robbing
б) хороший поиск. Есть синтаксический анализатор (который как минимум разные варианты имени подбирает), поиск частично сам определяет что конкретно мы ищем даже без конкретного указания. Ну и какие-то другие плюшки, давно не заходил на сайт, уже не помню. Скорость тоже на высоте.
в) работает без глюков. Иногда конечно встречаются недоработки, но на таких масштабах это неудивительно. Значит что код хорошо тестируется и, видимо, не только живыми тестерами.
г) По проекту видно, что высокая скорость работы обеспечивается не только серверной массой, но и оптимизациями. Наверняка используются нереляционные базы в дополнение к реляционным, наверняка есть отслеживание скорости работы этих баз. Не могу судить, просто некоторые изменения что происходят в проекте мне кажутся оптимизирующими шагами.
Ну итд. Проект работает хорошо не смотря на колоссальные нагрузки и огромное количество пользователей.
А теперь скажите, с чего вы взяли что код там плохой? Ну то что сеть не нравится, это понятно, мне тоже, но ругать техническую реализацию мне не позволяет совесть…
Качество кода не знаю, но задача решена хорошо потому что
а) все работает быстро. Значит код как минимум хорошо масштабируется (не все можно смасштабировать просто поставив доп. сервер и скопировав на него код с первого и пустив в режиме round-robbing
б) хороший поиск. Есть синтаксический анализатор (который как минимум разные варианты имени подбирает), поиск частично сам определяет что конкретно мы ищем даже без конкретного указания. Ну и какие-то другие плюшки, давно не заходил на сайт, уже не помню. Скорость тоже на высоте.
в) работает без глюков. Иногда конечно встречаются недоработки, но на таких масштабах это неудивительно. Значит что код хорошо тестируется и, видимо, не только живыми тестерами.
г) По проекту видно, что высокая скорость работы обеспечивается не только серверной массой, но и оптимизациями. Наверняка используются нереляционные базы в дополнение к реляционным, наверняка есть отслеживание скорости работы этих баз. Не могу судить, просто некоторые изменения что происходят в проекте мне кажутся оптимизирующими шагами.
Ну итд. Проект работает хорошо не смотря на колоссальные нагрузки и огромное количество пользователей.
А теперь скажите, с чего вы взяли что код там плохой? Ну то что сеть не нравится, это понятно, мне тоже, но ругать техническую реализацию мне не позволяет совесть…
Всё верно. На самом деле про говнокод написано было в шутку.
Простите, а как давно у них всё стало работать быстро и хорошо? Там почти не появляюсь, но помнится, что ооочень долго у них всё там лагало, как посещаемость выросла, так и тормозить всё стало в придачу. Очень долго не было видно никакого «ускорения», думаю, что беда была как раз в том, что нельзя было просто поставить дополнительный сервер, так как система не предусматривала масштабируемость. И вот только относительно недавно тормоза вроде бы пропали, но баги всё равно остались. Может быть сейчас там код и прилизали, но бОльшую часть времени существования проекта вряд ли там был нормальный код.
Не знаю, я не частый посетить вконтакта, но проблем со скоростью не замечал ниразу. И от знакомых не слышал жалоб (т.е. может когда-то и тормозило, но недостаточно долго/сильно для того чтобы об этом говорить). Разок видел как сайт просто лежал, но это врядли связано с кривым кодом.
Если бы вконтакте тормозил, то об этом бы на каждом углу кричали, сайт то очень популярный. И со временем начали бы пользователей терять. Не помню название сети, но топовая в Штатах сеть в свое время и слила юзеров Майспейсу отчасти из-за того, что перестала справляться с нагрузкой и начала тормозить.
Если у 0.01% юзеров наблюдаются какие-то проблемы, это не говорит о том, что код плохой. Может какой-то сервер оказался перегружен, а админы не заметили…
Если бы вконтакте тормозил, то об этом бы на каждом углу кричали, сайт то очень популярный. И со временем начали бы пользователей терять. Не помню название сети, но топовая в Штатах сеть в свое время и слила юзеров Майспейсу отчасти из-за того, что перестала справляться с нагрузкой и начала тормозить.
Если у 0.01% юзеров наблюдаются какие-то проблемы, это не говорит о том, что код плохой. Может какой-то сервер оказался перегружен, а админы не заметили…
Но я отвечал на Ваш комментарий, а там Вы писали про одноклассники, а не вконтакте. На вконтакте у меня и аккаунта нет, про них ничего сказать не могу, но вроде бы у них там всё нормально и с качеством и с производительностью.
> Не помню название сети, но топовая в Штатах сеть
Вы, наверное, про facebook.
> Не помню название сети, но топовая в Штатах сеть
Вы, наверное, про facebook.
Поиск там отвратительный, хуже, чем где бы то ни было.
И периодически встречал баги «от забывчивости» — типа того, что в мобильной версии на главной странице вместо названия кнопки вылезает какое-нибудь дефолтное имя шаблона.
И периодически встречал баги «от забывчивости» — типа того, что в мобильной версии на главной странице вместо названия кнопки вылезает какое-нибудь дефолтное имя шаблона.
Говнокод, неговнокод. А вот «закрытые» страницы до сих пор можно просматривать.
Переписать всё красиво и продать обратно )
за 5% подгоню 2-х
Алло, Озборн Кокс?: )
Надеюсь полученной статистикой распорядитесь не менее грамотно: ) Ждем, ждём: )
Надеюсь полученной статистикой распорядитесь не менее грамотно: ) Ждем, ждём: )
Хорошая работа, заставит администраторов взглянуть на свои серверы по новому :)
НЛО прилетело и опубликовало эту надпись здесь
чортавы каникулы в школах…
Не сталкивался с svn и реальной веб-разработкой, видать.
НЛО прилетело и опубликовало эту надпись здесь
У «серьёзных» всё же свои сервера, на которых нет ограничений на разграничение прав. Т.е. у проекта должен быть «свой» пользователь, который может с ним делать многое, а остальные могут только посмотреть что там да как, а svn должен быть доступен только пользователю-владельцу.
Вот на виртуальных хостингах достаточно ограничений и там надо предусматривать такую «багу» и защищаться, а когда есть свой сервер, то такое можно сделать только осознанно…
Вот на виртуальных хостингах достаточно ограничений и там надо предусматривать такую «багу» и защищаться, а когда есть свой сервер, то такое можно сделать только осознанно…
Пойти ли что-ли к шефу денег больше попросить, за то что у нас не так как в опере или яндексе? :)
НЛО прилетело и опубликовало эту надпись здесь
Помоему ненормально хранить исходники(я имею в виду php и тп, не html) в пределах DOCUMENT_ROOT.
Это гораздо проще чем настраивать все что написано в статье.
Это гораздо проще чем настраивать все что написано в статье.
Этот способ является самым безопасным и очевидным, но как показала практика — не для всех.
То что представлено в статье — универсальный способ закрытия данной дырки. То что предлагаете вы, очевидно, идеальный вариант, но подходит далеко не всем.
p.s. в своих проектах в document_root только index.php, даже статика выше корня. Спасибо nginx`у!
p.s. в своих проектах в document_root только index.php, даже статика выше корня. Спасибо nginx`у!
ну, index.php полюбому в DOCUMENT_ROOT
В общем вы правы, хранить код за педелами веб-директории — это очень правильно, но видимо с этим какие-то слоэности связаны, при размещении на хостинге (например если папки создаются динамически через VirualServerName)
Такс, пойду писать парсер, кто со мной? :) Мне нужны быстрые прокси и сервер с гигабит каналом…
А это только у меня параноя или нет, хранить весь код за пределами public_html?
Щас глянул, у меня по всем проектам раскиданы папочки .svn, но всё лежит за пределами паблика.
Щас глянул, у меня по всем проектам раскиданы папочки .svn, но всё лежит за пределами паблика.
Петух не клюнет, поп не перекрестится. Это два вменяемых человека поработали. А в мире тысячи невменяемых.
с интересом жду комментарии Бобука в следующем радио-т
Чувствую нотку сарказма в твоем голосе :)
Все равно отмажется…
Скажет, что в Гугле все еще хуже и что Гугль ему не нравится…
Столько раз хотелось ткнуть его носом и в их почту и в их «народ»… Но потом понимаю — это бесполезно.
Скажет, что в Гугле все еще хуже и что Гугль ему не нравится…
Столько раз хотелось ткнуть его носом и в их почту и в их «народ»… Но потом понимаю — это бесполезно.
Ткните меня, mailto:kukutz@yandex-team.ru
Я с Вами не общался, даже не слышал Вас, хотя наслышан из Радио-Т о такой культовой личности. С удовольствием бы пообщался, но боюсь, буду не интересен, ибо у меня собственные практические впечатления от сервисов :) Спор наверное станет холиваром, если вообще начнется :)
Вот Бобука слышал, и, пожалуй, не согласен во многом, что касается «какие мы хорошие и какие они плохие». Но я могу понять, про конкурентов всегда так — либо плохо, либо ничего. :)
А слушать его интересно. Без него шоу было бы тусклым.
Вот Бобука слышал, и, пожалуй, не согласен во многом, что касается «какие мы хорошие и какие они плохие». Но я могу понять, про конкурентов всегда так — либо плохо, либо ничего. :)
А слушать его интересно. Без него шоу было бы тусклым.
Ну смотрите. Я же не ради поспорить, а ради понять, что вам не нравится и чего не хватает, чтобы улучшить наши сервисы.
Ой, а Вы правда отреагируете на мои предложения и комментарии? С удовольствием выскажусь :) Вот только файлик побольше создам — чтобы поместилось. И отправлю на почту.
Здесь просто скажу, что с удовольствием пользуюсь всем тем, что касается поиска. Для меня он привлекательнее. Но вот с почтой когда-то были проблемы — поэтому перешел на мэйл и гмэйл и ни разу не пожалел об этом. И бобуковские наезды выглядят немного странными :) Ну на Радио-Т есть кому его притормаживать. А за возможность высказать пожелания лично — спасибо :)
Здесь просто скажу, что с удовольствием пользуюсь всем тем, что касается поиска. Для меня он привлекательнее. Но вот с почтой когда-то были проблемы — поэтому перешел на мэйл и гмэйл и ни разу не пожалел об этом. И бобуковские наезды выглядят немного странными :) Ну на Радио-Т есть кому его притормаживать. А за возможность высказать пожелания лично — спасибо :)
НЛО прилетело и опубликовало эту надпись здесь
Полезно. Мне почту и что-то ещё несколько раз «чинили» по «заявке» ;)
bobuk: «Дети на Хабре обсуждают что кто-то украл „исходники яндекса“ через каталог .svn. Как говорится „I LOLd“.»
via twitter
via twitter
Охохо! Слушайте, все, что я могу сказать — «браво!». Это определенно EPIC FAIL для многих компаний:)
Боюсь устными заверениями «Мы честно всё сожгли и всех предупредили» вы не отделаетесь.
Рисково. Накопай бы я что-то эдакое, сидел молчал бы.
Рисково. Накопай бы я что-то эдакое, сидел молчал бы.
Учитывая, что полезли внутрь и начали читать, то да… можно и попараноиться.
Если бы просто нашли, не читали, но сообщили — благое дело.
Если бы просто нашли, не читали, но сообщили — благое дело.
НЛО прилетело и опубликовало эту надпись здесь
Браво.
эпически!
и это не фейк. нашел один русский поисковик, зашел по нему в .svn/entries и чуть не ослеп.
и это не фейк. нашел один русский поисковик, зашел по нему в .svn/entries и чуть не ослеп.
Я тоже нашел. Никому не скажу.
Прикрыли прямо на глазах.
поисковик был nigma.ru
Кстати, отблагодарили.
Кстати, отблагодарили.
Какова логика работы вашего кравлера?
Он понимает, что во многих местах mod_rewrite подсовывает что-то, что никак не фалы с .svn/?
Или Вы в итоге обрабатывали его результаты вручную?
Поищите еще служебные файлы CVS. Её тоже многие используют :)
И таки да, вмест совета админам закрывать доступ к файлам на уровне вебсервера, лучше рекомендовать не пускать программистов в DocumentRoot, а писать для них инсталятор. Который и файлы лишние уберет и права правильные поставит.
Он понимает, что во многих местах mod_rewrite подсовывает что-то, что никак не фалы с .svn/?
Или Вы в итоге обрабатывали его результаты вручную?
Поищите еще служебные файлы CVS. Её тоже многие используют :)
И таки да, вмест совета админам закрывать доступ к файлам на уровне вебсервера, лучше рекомендовать не пускать программистов в DocumentRoot, а писать для них инсталятор. Который и файлы лишние уберет и права правильные поставит.
НЛО прилетело и опубликовало эту надпись здесь
А почему только о русских доменах речь? А кода Гугла у вас нет?
Беда
Великолепно!
НЛО прилетело и опубликовало эту надпись здесь
Молодцы!
Нет, до доткомов надо вам все-тки добраться. ну ее эту работу)))
Парни, вы наверно сейчас обломали очень много народу, которые об этом знали, использовали но помалкивали:)
НЛО прилетело и опубликовало эту надпись здесь
Какой шпионаж. Исходный код лежит в отрытом доступе без пометки «секретно» и без копирайта. Бери — не хочу
в доткоме о подобной уязвимости знают? где-нибудь проскакивало?
не пали хату раньше времени, у нас еще есть шанс :)
НЛО прилетело и опубликовало эту надпись здесь
Так забавно читать хабр на английском :)
Буржуи обзавидуются когда увидят размер зарплат в России.
Senior Mobile Software Developer 95 000 USD / month
Coder 30 000 USD / month
Webmaster s / n Contract
Sales Manager (all regions) s / n Contract
Programmer PHP / JS s / n Contract
Freelancer-joomler. Novosibirsk s / n Contract
PHP Programmer 50 000 USD / month
Senior Mobile Software Developer 95 000 USD / month
Coder 30 000 USD / month
Webmaster s / n Contract
Sales Manager (all regions) s / n Contract
Programmer PHP / JS s / n Contract
Freelancer-joomler. Novosibirsk s / n Contract
PHP Programmer 50 000 USD / month
Глеб, надо отразить всю сенсационность в заголовке. Например: «BREAKING: Source Code of MAJOR Internet Projects Were Got Through /.svn vulnerability»
Зря, наверное, выложили) Скоро будет хабраэффект на хабре)
«Including Yandex (Russian search engine )»
А про Яндекс то вроде как неправда.
А про Яндекс то вроде как неправда.
кстати там нашел такую ссылку http://www.google.ru/search?q=inurl%3A%22*.com*.svn%2Fentries%22, так что достаточно написать парсер для гугла ))
жесть, сразу все закрыл, у мейла кое где еще пашет ;)
Хочется побольше интересных фактов! :)
Отличная работа :)
Еще одно подтверждение о пользе хранения исходников вне public_html, рельсы, джанги и Git рулят :)
Еще одно подтверждение о пользе хранения исходников вне public_html, рельсы, джанги и Git рулят :)
Товарищи Авторы! Что с Яндекс-деньгами и Вебмани? Имеет смысл выводить их поскорее? :)
Побольше бы таких людей, которые найдя дырку начинают сканировать на её наличие целый рунет, и не для своих пагубных целей, а ради интереса, который принесёт только пользу для незнающих владельцев сайтов, потому что их предупредят. Спасибо, что вы есть!
Пост доказывающий превосходство bzr над svn [x]
Bazaar отдаёт только по ssh, никаких http. Если конечно не ставить специально веб-интерфейс.
Bazaar отдаёт только по ssh, никаких http. Если конечно не ставить специально веб-интерфейс.
Нашли из чего делать откровение. Это же обычная приватная папка, первым делом закрывается, как и «Index of» апача и прочих веб-серверов. Жаль что такой низкий уровень разработчиков и администраторов.
Я восторжен вами до безумия!!!
Я смотрю, многие рванули доказывать превосходство других систем контроля версий над SVN на базе этого топика. Очередной раз из-за «криворуких» пользователей страдает технология :(
Для того, чтобы выливать сырцы на сайт, есть svn export. Это же ясно как божий день. Как можно додуматься лить в веб исходники со скрытыми каталогами .svn? Небось еще и скрытые файлы IDE (такие как .project) туда же попадают…
Для того, чтобы выливать сырцы на сайт, есть svn export. Это же ясно как божий день. Как можно додуматься лить в веб исходники со скрытыми каталогами .svn? Небось еще и скрытые файлы IDE (такие как .project) туда же попадают…
Тут вы немного не в теме.
Есть своя прелесть, когда проект находится под контролем версий и его можно обновить до любой ревизии в течении пары секунд.
Есть своя прелесть, когда проект находится под контролем версий и его можно обновить до любой ревизии в течении пары секунд.
Ага. Вы еще скажите, что «по живому» обновляете production из trunc-а.
Для обновления пишутся скрипты, которые закрывают сайт, потом экспортят код, делают какие-то действия если надо, а потом открывают сайт.
Мне еще интересно, что вы будете делать, если посреди «живого» апдейта упадет связь с SVN-сервером?
Для обновления пишутся скрипты, которые закрывают сайт, потом экспортят код, делают какие-то действия если надо, а потом открывают сайт.
Мне еще интересно, что вы будете делать, если посреди «живого» апдейта упадет связь с SVN-сервером?
Были получены исходники 3300 глобальных интернет-проектов