Были получены исходники 3300 глобальных интернет-проектов

    Пару месяцев назад нами (2Товарища и Антон Исайкин) была обнаружена уязвимость, присущая в основном большим интернет-проектам (вроде Рамблера, Мейла, Яндекса, Оперы и пр.). Удалось получить доступ к файловым структурам известнейших сайтов (в общей сложности 3320 сайтов) и в ряде случаев их полные исходные коды.

    Казалось бы, что в XXI веке трудно найти подобную уязвимость. Кажется, что уже всё найдено, а то что не найдено, сидит где-то очень очень глубоко. Оказалось, что корнем сегодняшнего зла является вполне повседневная вещь. Наверняка каждый из вас когда-нибудь имел дело с системой контроля версий SVN.

    SVN является продвинутым средством для организации совместной разработки десятков, а то и сотен разработчиков. В силу особенностей архитектуры, SVN хранит в каждой директории проекта свои метафайлы, аккуратно сложенные в скрытую директорию .svn. В одном из файлов под названием entries находится список всех файлов и директорий, расположенных в той же папке, что и .svn. Так же там находится информация о расположении репозитория, размере файлов, даты их изменения и логины пользователей, работающих над проектом. Уже не плохо, правда? Объясню, получается, если проект разрабатывается с помощью SVN, то заглянув по адресу draftcopy.ru/.svn/entries мы увидим файловую структуру корня проекта с авторами, последними изменениями, ссылкой на основную ветку репозитория итп.

    Но можно пойти и далее. В той же папке .svn находится директори text-base, в которой лежат последние версии всех файлов, находящихся в репозитории. Картину дополняет так же и то, что файлы имеют не стандартное расширение (например .php), которое позволяет их сразу отправить на интерпретатор, а дополнительное расширение .svn-base, благодаря которому файл отдается запросившему его человеку «как есть», т.е. голый исходный код!

    draftcopy.ru/.svn/text-base/index.php.svn-base

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

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

    Защита от уязвимости


    Уязвимость можно обойти несколькими путями. Путь в лоб — запретить обращаться к метадиректориям SVN по 80-ому порту, т.е. средствами вебсервера.

    Решение для nginx

    location ~ /.svn/ {
        deny    all;
    }
    

    Глобальных локейшенов в nginx`е нет, поэтому прийдется подписывать для каждой server области. Чтобы правило имело силу, необходимо загружать его до других локейшенов с регулярным выражением. Универсальный способ — первым локейшеном.

    Решение для Apache

    <Directory ~ ".*\.svn">
        Order allow,deny
        Deny from all
        Satisfy All
    </Directory>
    

    Тут немного проще, дописываем это в httpd.conf и на всех проектах под управлением apache чтение из директории .svn будет недоступно.

    Решение средствами SVN
    Защита от уязвимости средствами вебсервера — лечение болезни. Любой доктор скажет, что профилактика проще, легче и менее затратней, чем лечение. Поэтому лучшим решение будет отсутствие этих самых метадиректорий в корне проекта. Добиться этого можно средствами svn export из основной ветки.
    Информация взята с twocomrades.ru



    История исследования


    Как уже было сказано, было решено просканировать весь рунет на наличие подобной уязвимости. Были подняты прокси-сервера, написан парсер и получена свежая база доменов в зоне ru. Первая версия скрипта работала две недели, получая сайт за сайтом в один поток. К завершению сканирования, база насчитывала более 3000 уязвимых сайтов и занимала более ста гигабайт исходных кодов.

    Проблемой первого сканировния было то, что скачивались все сорцы без разбора, не зависимо от того, отдавали они 200 или 500 код, а так же закачивалась графика и js-скрипты. А так же часто веб-сервера были настроены таким образом чтобы отдавать 200 код, даже если файл на самом дела отсутствовал.

    Вторая версия скрипта была уже шустрее, работала в несколько потоков с двух серверных машин и правильно различала коды ответа содержимое полученных страниц. Мы обошли весь рунет за 4 дня. Дальнейшими планами была база доткомов. Стало очевидно, что при текущих ресурсах обход был бы выполнен как минимум за пару лет (зона com сейчас насчитывает более 700 млн доменов (против 2 млн ru)).

    К дел был привлечен отличный си-программист Андрей Сатеренко, который написал быстрого демона, который сумел бы в пару раз сократить наши временные затраты. Но, к сожалению, к этому моменту лето кончилось, навалилилась работа. Грандиозные планы было решено свернуть.

    Прежде чем публиковать открыто информацию об уязвимости, необходимо было предупредить всех пострадавших. В первую очередь письма были разосланы гигантам (yandex.ru, rambler.ru, mail.ru, opera.com, rbc.ru, 003.ru, bolero.ru, habrahabr.ru, итого 19 адресов), затем, сегодняшней ночью, письма получили остальные 3000+ сайтов.

    Выпуск этой статьи был задержан ожиданием пока opera.com закроет уязвимость на всех своих серверах.

    Немного статистики:

    Просканировано доменов: 2253388
    Уязвимых: 3320

    Статистики по оповещениям пока нет, возможна она будет опубликована через пару недель. Из крупных порталов, ответили шестеро. Самым оперативным оказался Яндекс, прислав ответное письмо ночью в воскресенье. Десять проектов никак не прореагировали на наши письма, три проекта закрыли уязвимость не поблагодарив.
    Мы не злопамятные, мы запишем их имена…

    Несколько интересных фактов:

    1. Киберсквотеры полюбили SVN, как и оптимизаторы;
    2. Единый CSS для календарей яндекса собирается из десятка CSS средстами $make из консоли 0_0;
    3. На проектах Рамблера пользуются сервисами Яндекса 0_0, найдены файлы «подтверждения домена» для сервисов Яндекса;
    4. РБК использует и сервисы яндекса и сервисы гугля и очень любят «сложные» пароли;
    5. Опера уважает MySQL, но сайт у них на голом html с реальными директориями и поддиректориями;
    6. Блондинка уважает CodeIgniter;
    7. PostgreSQL уважают движок wikimedia => PostgreSQL уважают MySQL ;-) ошибко ;-(
    8. Все проекты Футурико (и Лепра) написаны на perl.
    9. Порядка 10 сайтов со словами в домене типа «hack» и «secure» уязвимы;
    10. Многие уверены, что назвав директорию с phpmyadmin примерно «__xpma123uff__» но сохранив пароль в конфиг, это хорошая защита;
    11. Многие до сих пор хранят конфиги в inc файлах, без расширения .php, которые открываются как текст в браузере.

    P.S. Во избежании конфликтов все исходные коды, полученные за время исследования были распечатанны и сожжены.
    P.S.S. Два пункта:
    • абсолютно все, кто мог пострадать, получили предупреждения об уязвимости с точной датой обнародования заранее.
    • никакие исходные коды ни при каких условиях не будут опубликованы или проданы. Не стоит писать нам по этому поводу.

    P.P.P.S. Спасибо за содействие хабрапользователю oowl.
    P.P.P.P.S. Никаких сорцов самого поискового механизма Яндекса получено не было, однако были получены корни веб морды некоторых ресурсов. Верстка, xmlapi, xsl шаблоны итп. Ничего серьезного, разве что все адреса репозиториев, логины разработчиков итп. Кукуц, Бобук, расслабьтесь.

    Игорь Сысоев, ведущий системный администратор компании Рамблер, разработчик известного своей легкостью веб-сервера nginx ответил на пару наших вопросов:
    • Q: Отчего сразу столько известных проектов пренебрегли такой элементарной возможностью утечки?
      A: Причин, я думаю, много — кто-то считает, что в .svn лежит всё то же самое, доступное и без .svn. Кто-то, возможно, просто не знал или забыл об .svn.
    • Q: Планируется ли внести в nginx возможность глобально перенаправлять URL (до директивы server, чтобы можно было при настройке сразу заблокировать потенциально опасные адреса)?
      A: Нет. Я считаю, что глобальные настройки в конечном итоге приводят к конфигурации, которую с каждым разом всё сложнее сопровождать.



    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 909
    • +1
      распечатать & сжечь — а-ля культ Вуду? ;)
      • +14
        У нас свои методы :-)
        • +3
          Распечатать на бумагу и сжечь винты? :)
          • 0
            Перед этим поцарапав. С двух сторон.
          • +7
            Антон, я реально горжусь тем, что мы когда-то сотрудничали. Сложно представить себе масштаб того, что вы сделали. Полезность этого и эффект для вашего паблисити. Поздравляю.
            • +7
              вы подтвердили существование лепры! да еще как громко!
            • +45
              Это ппц, авации, браво.

              Новость года, однозначно.
            • +127
              Дайте-ка посмотреть, — Воланд протянул руку ладонью кверху.
              — Я, к сожалению, не могу этого сделать, — ответил мастер, — потому что я сжег его в печке.
              — Простите, не поверю, — ответил Воланд, — этого быть не может. Рукописи не горят. — Он повернулся к Бегемоту и сказал: — Ну-ка, Бегемот, дай сюда роман.
              Кот моментально вскочил со стула, и все увидели, что он сидел на толстой пачке рукописей. Верхний экземпляр кот с поклоном подал Воланду

              М.А.Булгаков, «Мастер и Маргарита»
              • +7
                Израсходовал последний плюс ;).
              • +1
                Нужно было скурить)
              • +67
                Это ш пипец!
                • +41
                  Я думаю, вы не понимаете всей звиздецовости ситуации.

                  > Были подняты прокси-сервера, написан парсер и получена свежая база доменов в зоне ru.

                  Они сканировали только зону .RU, а есть еще .COM, .NET, .ORG и больше сотни национальных TLD…
                  • +20
                    Да, вы правы. Но предупредить ВСЕХ физически невозможно. Поэтому было решено придать делу максимальную огласку, чтобы потенциально уязвимые в прочих зонах смогли оперативно все закрыть.
                    • +12
                      На каких англоязычных ресурсах разместили инфу?
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • –26
                          Сайты, сделанные грамотными разработчиками и обслуживаемые опытными администраторами — в безопасности, а то что поломают 10-долларовый сайт на 5-долларовом хостинге, никому не грозит, не разводите панику.
                          • +13
                            Угу. yandex тому примером.
                            • –23
                              Там же во-первых большая команда, во-вторых, админ там, как выснилось, не разбирается в безопасности (я бы посоветовал руководству книг ему что ли полезных по этой теме дать почитать и перейти на майкрософтовскую VCS, она то точно без пакости (шутка)), а программисты тут не при чем :)
                              • 0
                                Видимо имелся ввиду VSS
                                • 0
                                  VCS = Version Control System, это перевод на английский термина «система контроля версий» ;-)
                                  Таким образом, VSS — это VCS.
                                  • –1
                                    VCS — так не говорят, говорят SCM — Source Code Management
                            • +10
                              Типичный пример «10-долларовый сайт на 5-долларовом хостинге»:
                              apache.org/.svn/entries
                              • –23
                                Apache это же OpenSource, что там украдешь? Мануал по апачу что ли?? Ну вы смешной, как можно украсть то, что и так открыто ))

                                p.s. И вообще, я думаю опенсурсу к взломам не привыкать, в открытых движках постоянно находят уязвимости

                                p.p.s И вообще, ломать опенсоурс сайты или вредить их деятельности — бесчеловечно и низко, я считаю.
                                • 0
                                  classmates.com, bolero.ru? Примеры взяты из комментариям к этой же записи, думаю вы при желании и еще примеров почерпнуть сможете.
                                  • –5
                                    Я конечно не видел западные classmates, но если это то же, что и наши «одноклассники», пусть их ломают. это позор рунета, я считаю.

                                    И кстати, с чего вы взяли что крупные сайты делаются квалифицированными разработчиками? Может clssmates индусы делают (это к слову о 10-долларовых сайтах, не надо понимать что он и в самом деле столько стоит)?
                                    • +2
                                      > И кстати, с чего вы взяли что крупные сайты делаются квалифицированными разработчиками?

                                      Скажите, а чем вообще занимаются квалифицированные разработчики?
                                      • –7
                                        Ваш провокационный комментарий вызывает желание ответить от первого лица:) но я сдержусь!

                                        А если ближе к теме — интерфейс одноклассников квалифицировнный разработчик бы не придумал (ну или не смог бы выносить, если его придумали до него). И дыру с svn бы не оставил.
                                • 0
                                  ну этим-то точно можно не запариваться:)
                                  • 0
                                    До сих пор лог не закрыт…
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                    • –1
                                      Вот я помню сказал как-то Линуксоидам что их Линукс не так уж и хорош… А это, что, ерунда :) К тому же у меня такие значения кармы (знаю что меньше -100 должно быть :) ), что на них уже просто невозможно повлиять
                                    • +1
                                      Уязвимы все, вот только степень уязвимости неодинакова.
                                • +13
                                  Так, ребята юзающие git! Мы тоже уязвимы в случае, если корень репозитория доступен из веба.

                                  Причем исходники сливаются очень красиво, не надо писать никаких парсеров:
                                  git clone example.com/.git/

                                  К счастью, в большинстве случаев корень репа, а значит и папка .git закрыты извне.

                                  ПС: Кто-нибудь, переведите эту статью на английский!
                                  • +1
                                    Для 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 -
                                    • +2
                                      Значит, все-таки, не так бесполезна предложенная мной чуть более чем полтора года назад система защиты ini-фалйов на веб-серверах!
                                      bolzamo.org.ru/82/
                                      • +3
                                        Бесполезна, есть 3 способа проще: 1) хранить ini файлы в отдельной закрытой извне папке 2) хранить код вне корня сайта (т е вообще недоступным извне) 3) прописать в htaccess/конфиг сервера запрет на доступ к *.ini, ваше решение — детский сад.
                                        • 0
                                          ну да, в целом все верно… За исключением того момента, что хостеры порой бывают настолько суровы, что закрывают клиентам возможность настраивать сервер через .htaccess. Явление редкое, но в природе все-таки встречающееся. Кроме того, закрывать возможность скачивать ini-файлы — бред, так как возникнут сложности с публикацией каких-нибудь конфигов для it-шных сайтов.
                                          А расположение же настроек вне корня сайтов… Ну скажем так, пользователь продукта врядли поймет благородные мотивы разработчика, который в описание процесса установки впишет размещение каталога вне корня сайта. Скорее всего такой разработчик будет сначала трижды проклят, а потом уже, возможно, понят.
                                          Некоторые разработчики суеверны, и не любят, когда их проклинают.
                                          • 0
                                            Суровых хостеров — в топку. На моем « элитном» бесплаьном хостинге хтаккесс разрешен.

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

                                            Можно напистаь установщик, кроме того нормальныен сайты устанавливает разработчик а не заказчик.
                                            • 0
                                              А нормальный сферический конь в вакууме ростом один метр и весом один килограмм должен двигаться со скоростью 1м/ч без ускорения.
                                              • +2
                                                Не придумывайте, если у вас даже нет возможности править htaccess, это ваши проблемы, и решение с комментированием — изврат и муть. А еслив .ini встретится последвательность '*/', a?
                                                • 0
                                                  ы! А об этом я как-то в свое время не подумал… Ну тогда php-парсер умрет с ошибкой, но секретных данных не выдаст. Что же до отсутствие возможности править .htaccess — реально бывали такие случаи, и «это ваши проблемы» сказать можно, а можно подсказать решение для тех, чьи это проблемы, что я собсна и сделал. Моя проблема как разработчика — заставить свое творение работать с наименьшими запросами к среде окружения, и без капризов по поводу мелких серверных настроек.
                                                  Но насчет последовательности — улыбнуло, плюсанул :)
                              • +24
                                Оу, можно смело сказать:
                                Галактеко опасносте!

                                *Поставил наблюдение за тостером. Кто их занет
                              • +181
                                Аплодисменты.
                              • +2
                                Проблема в отсутствии/квалификации CSO, и банальная лень админов написать инсталятор для выкатки кода на продакшн. Любой сканер уязвимостей находит такие директории.
                                • +1
                                  В Яндексе и Опере ленивые админы? Но уж точно не параноики :-) «как страшно жить» (с)
                                  А вообще — да, болезнь на удивление детская.
                                  • 0
                                    они бы еще где нибудь рядом архив с исходниками положили и думали, а мало ли не найдут! Причем тут SVN? Проблема, ИМХО, в лени.
                                    • +5
                                      Видимо проблема в том что разработкой занимаются одни люди, а настройкой установкой и обслуживанием серверов — другие, отсюда и бестолковость и дыры в безопасности. Я, когда ставил SNV, первым делом подумал, что это дыра в безопасности (вторым подумал — надо проверить, нет ли этой дыры на Хабре ;) ). Уверен, что любые ответственные разработчики делают также.

                                      Это дыра из серии, «положу install.php в корень, никто же не знает что он тут лежит». Детский сад, ей богу.

                                      Раскрытие исходных кодов не должно приводить к уязвимостям.
                                    • 0
                                      плюс миллиард.
                                      это просто тупо лень и низкая квалификация. Эта новость скорее повергла меня в гнев и обида за тех разработчиков, которые не поняли очевидного «левак в паблике, да ещё и не собственноручно генерируемый — потенциальная опасность в любом случае». И не важно какой это левак. .svn это канеш совсем верх совершенства, но даже .htaccess это УЖЕ идиотизм. И это не паранойа, это совсем другой подход «программа — слева, код — справа».
                                      • 0
                                        тьфу «программа — слева, паблик — справа» =)
                                      • 0
                                        Мало того, есть люди, которые прочитали эту новость на хабре и ничего не сделали у себя на проекте. Притом, что .svn имеется и некоторую инфу от туда вытащить можно.
                                        Вот это действительно лень… притом, в мне известных случаях, программистов…

                                        Или отложили действия на время прихода музы подобных действий…

                                      • –7
                                        Seriously?
                                        • +5
                                          Офигеть.
                                          • –7
                                            Статья очень похожа на «Продам исходные коды яндекса и других гигантов».

                                            Но тем не менее страшно интересно:
                                            1. чем все закончится с гигантами.
                                            2. ещё десяток интересных фактов о сайтах.
                                            3. чем защищались остальные 2253388-3320 порталов, если у них есть директория svn

                                            • 0
                                              >3. чем защищались остальные 2253388-3320 порталов, если у них есть директория svn
                                              там просто не работали по SVN, либо уже были защищены.
                                              • +6
                                                1. Мы дождались пока все гиганты закрыли уязвимость, только затем опубликовали топик.
                                                2. Возможно будет апдейт или новый пост, как наберем достаточно интересного.
                                                3. Под раздачу попали крупные сайты именно потому что в них ведется командная разработка. Остальные сайты разрабатываются либо одним человеком, либо без использования SVN.
                                                • –8
                                                  Реальный пруф есть помимо скриншотов которые слабать быстро можно? Э
                                                • 0
                                                  Дотком-то поставили сканить? ;)

                                                  Медленно, но верно?
                                                  • +1
                                                    2. ещё десяток интересных фактов о сайтах

                                                    тоже хочу это!
                                                    • 0
                                                      по пункту — 3. Остальные сайты разрабатываются либо одним человеком, либо без использования SVN.

                                                      Разрабатываться то они могли и с SVN, вот только разработчки отбкатав тесты, не поленились сделать экспорт на «боевой» сервер, а не разрабатывать на нём.
                                                    • +3
                                                      Скорее, это очень оригигнальное СV.
                                                    • +37
                                                      Хочется больше интимных подробностей :-)
                                                      • +3
                                                        очень, очень
                                                        • +7
                                                          Как пинки админам раздавались или в каких позах? :)
                                                          • 0
                                                            … и список топ-20 крупнейших сайтов (ну или топ-50)
                                                          • +2
                                                            1) так а если поставить аутентификацию по .htpasswd?
                                                            2) не представляю, как узнать домен, на котором у Яндекса репозиторий
                                                            • +2
                                                              Адрес репозитория как раз и написан в .svn/entries.
                                                              • +1
                                                                я наверно тупой. У меня сайт site.ru. На нем последняя ревизия, экспортированная (папки svn нету вовсе). Репозиторий расположен где-то в совершенно другом месте. Как Вы узнаете его адрес?
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                  • 0
                                                                    если вы не выносили в настройках svn папки .svn в другое место, то при чекауте из репозитория, или апдейте они создаются в каждой папке.
                                                                    • +1
                                                                      svn export делает слепок ревизии без служебных данных SVN. Там этих данных нет.
                                                                    • 0
                                                                      В таком случае вы все сделали правильно, и не страдаете данной уязвимостью. Речь о другом. Народ вон рабочие копии выкладывает.
                                                                  • 0
                                                                    2) Репозиторий на закрытом хосте. Так что это бесполезно. А вот список файлов засветили, это да.
                                                                  • +4
                                                                    Спасибо за информацию.

                                                                    Пошёл закрывать дыру на своих сайтах :)
                                                                    • –10
                                                                      Если проект написан на Ruby-on-Rails, то никакой уязвимости и быть не может.

                                                                      Структура не позволяет (в паблике токо рисунки и джаваскрипты)
                                                                      • –1
                                                                        А рисунки и джаваскрипты вне контроля версий?
                                                                        • 0
                                                                          В контроле версий, но что с ними можно сделать такого, что поломает сайт?
                                                                          • 0
                                                                            Про «сделать» тут речь и не идёт. Но в любом .svn есть как минимум адрес всего репозитория, есть логины юзеров… в общем, не то, что обязательно всем нужно видеть.
                                                                            • +2
                                                                              Ну тогда я не правильно Вас понял.
                                                                              За уязвимостью я предполагал, что можно вытаскивать скрипты.

                                                                              А юзеров и репозиторий узнать — это конечно плохо…
                                                                              • 0
                                                                                В том и дело что можно скрипты вытаскивать
                                                                          • +3
                                                                            git с hg не создают в каждой папке свои .git и .hg каталоги, только в корне. Замусоривать все своими папками — это особенность svn)
                                                                            • +1
                                                                              стоит заметить что любая dvcs если сделать чекаут в паблик сервера позволит вообще слить весь репозиторий нахрен. Но так как это явная фича, мало кто, думаю, додумается до такого идиотизма)
                                                                            • +1
                                                                              яваскрипты и картинки и так можно скачать :)
                                                                            • –2
                                                                              Хахаха!
                                                                            • +3
                                                                              Интересно, в конфиге Apache по-умолчанию будет запрет доступа к папкам .svn, как к файлам .ht*?
                                                                            • +6
                                                                              Мораль — юзайте git =)
                                                                              • +6
                                                                                У гита есть .git :-)
                                                                                • +3
                                                                                  Да, но только в корне, а кто же корень проекта шарит в www.
                                                                              • 0
                                                                                чтобы по одной папке в корне вытащить все содержимое?
                                                                                • +4
                                                                                  Мораль — читайте мануал по SVN (это я про svn export)
                                                                                  • –2
                                                                                    Nobody reads manuals (и в общем-то это правильно, они как правило огромные, только время зря тратить).
                                                                                    • +1
                                                                                      ага, и налоги лучше не платить. Если вы без сарказма, то вы, Тупой. И наоборот.
                                                                                  • 0
                                                                                    Мораль — юзайте svn export
                                                                                    • +7
                                                                                      Юзал — неудобно нифига. Если лежит раб. копия, то видно, какие в ней версии файлов, какие локальные правки — все четко и наглядно. Да и управлять удобнее — svn up (до любой ревизии), svn revert, svn merge.
                                                                                      Также экспорт всей папки с проектом невозможен по причине того, что в папке могут быть неверсионированные файлы, например сессии. Одной командой обновить проект не получиться, придется писать скрипт экспорта — а это лишние телодвижения и лишние проблемы.
                                                                                      Вставить в конфиг апача настройку для закрытости папки .svn намного проще и лучше будет.
                                                                                      • +1
                                                                                        Минус поставили, а теперь, пожалуйста, контраргументы?
                                                                                        Я серьезно, было бы интересно, чем экспорт удобнее рабочей копии, я свои привел в пользу рабочей копии — она гораздо более информативна и управляема.
                                                                                        • +6
                                                                                          Зачем на production-версии смотреть, «какие в ней версии файлов, какие локальные правки»? Рабочие сырцы вообще надо трогать только один раз при каждом апдейте, всё.

                                                                                          Никаких «svn up (до любой ревизии), svn revert, svn merge» в production быть не должно, это всё должно делать в другом месте, а на рабочую копию исходников должен отражаться только проверенный (протестированный) результат всех этих действий.

                                                                                          Если вы копаетесь в коде прямо на production-сервере, то я право не знаю, что тут можно сказать.

                                                                                          А скрипт писать надо все равно, потому что перед обновлением исходников сайт должен быть закрыт заставкой, а после обновления — открыт.
                                                                                          • 0
                                                                                            Я не копаюсь руками в коде, я лишь использую раб. копию как инструмент для выкладки. И с раб. копией мне гораздо удобнее и информативнее. Об этом подробнее написал в комменте ниже.
                                                                                            • 0
                                                                                              не надо ничего закрывать — надо просто апдейт сделать атомарным.
                                                                                          • +3
                                                                                            Тут много красивее путь Capistrano:

                                                                                            current

                                                                                            system (лежат папки с именем timestamp, вовнутрь которых делается как раз export. Задеплоили — симлинк current указал на последний снапшот.)

                                                                                            shared (some user data, logs, temp, ...)

                                                                                            И капистрано уже делает revert и много чего другого. Конечная цель — на сервер руками перестаешь лазить.

                                                                                            ЗЫ: к минусующим не отношусь.
                                                                                            • 0
                                                                                              Не нашел у вас спорных со мной моментов.
                                                                                              Кто сказал, что я лезу на сервак и там делаю руками svn up? Это не так, все делает скрипт через панельку деплоя. При этом в панельке можно посмотреть результаты обновления (svn diff боевой раб копии проекта с интересующей ревизией) перед обновлением, результаты собстно самого процесса обновления — этого без раб копии не посмотришь.

                                                                                              По поводу отделения обновляемых данных от необновляемых — у меня в раб. копии при ее создании прописывается игнор на неверсионированные папки — аналогия вашему разделению shared/system.

                                                                                              Ну и все-таки имеется специфика, такая, что на сервер руками все же лазят править, хотя я с этим борюсь и это неправильно, но т.к. все-таки это делают, я предпочитаю видеть измененными те файлы, которые изменили на боевом, кстати при svn up эти локальные правки не теряются.
                                                                                              • 0
                                                                                                Ок, подробнее:

                                                                                                >Если лежит раб. копия, то видно, какие в ней версии файлов
                                                                                                я и так знаю что за ревизия у меня выкачена на боевой

                                                                                                >какие локальные правки
                                                                                                боже упаси. Зоопарк такой уже проходили, наигрались, увольте.

                                                                                                >svn up (до любой ревизии), svn revert, svn merge.
                                                                                                cap deploy [-s revision=N], cap deploy:rollback…

                                                                                                >в папке могут быть неверсионированные файлы, например сессии.
                                                                                                Опять-таки, все подобное храним вне дерева исходников. Всем от этого жить проще. Пример на пальцах: есть dev-версия и production, и периодически надо вливать живые данные в dev. БД я синхронизирую, а папки от production банально копирую в dev. А так пришлось бы куски выискивать по всему дереву.

                                                                                                >Одной командой обновить проект не получится, придется писать скрипт экспорта
                                                                                                Это делается аж единожды для проекта (а дальше копипастит в другие). Кроме того, скрипт экспорта включает в себя лишь создание правильных ссылок, остальное — на автопилоте (в самом Capistrano уже много чего написано).

                                                                                                Я ни в коем случае не говорю что это не true way, а путь показанный мной — единственно верный. Просто показываю что с моей точки зрения удобнее, так как раньше делал именно так как описали Вы.
                                                                                                • 0
                                                                                                  ок, я понял, спасибо, что поделились своим подходом, на заметку возьму софтину обязательно и организацию.
                                                                                                  Только я пока остаюсь при своем мнении, т.к. у меня те же цели, что и у вас достигаются проще (без доп. софта и других телодвижений). Единственное, что требуется — понимание работы свн.
                                                                                                  И я тоже не говорю, что мой подход суперпупер правильный, но я против тех, кто говорит что раб. копии не место на боевом.
                                                                                                  Папки .svn светятся?
                                                                                                  Так прикройте их апачем и снаружи не будет никакой разницы между экспортом и раб. копией. Мы свои .svn в корневом конфиге апача закрыли сразу, как перешли к раб. копиям (сначала, кстати экспорт использовали со скриптами).
                                                                                                  • 0
                                                                                                    > Я ни в коем случае не говорю что это не true way, а путь показанный мной — единственно верный. Просто показываю что с моей точки зрения удобнее, так как раньше делал именно так как описали Вы.

                                                                                                    Мне кажется, что ваш методе действительно хорош. Я пару месяцев, после прочтения github.com/blog/470-deployment-script-spring-cleaning, планирую всё таки использовать готовые скрипты автоматизации деплоя.

                                                                                                    Пока использую .deb пакеты (собранные на офисном сервере), и делаю apt-get update && apt-get upgrade на каждом сервере ручками.

                                                                                                    Раньше использовал rsync исходников с офисной машины (с локальной машины скрипт заходил на офисный сервер, делали git checkout нужной версии, а потом с боевой машины делался rsync на дерево исходников, использовали ssh-forwarding и на продакшене не хранили данные о офисной машине)
                                                                                                    • 0
                                                                                                      Капистрано умеет и из локальной версии по rsync'у заливать сорсы на сервер. И с его помощью можно на ферме машин сделать одной командой набор действий, хоть тот же apt-get update && apt-get upgrade (при условии что процесс будет не интерактивным). Я, кстати, так правило для .svn на все сервера сразу разнес ;)

                                                                                                      А не опишете процесс создания своего apt-репо и сборку деб-пакетов (с нуля) блогпостом? ;) Я пришел к необходимости создания своего репо с nginx, чтоб все сервера апдейтить как-раз не руками.
                                                                                                      • 0
                                                                                                        Обязательно попробую. А из других систем вы что-то пробовали?

                                                                                                        • 0
                                                                                                          Для деплоймента пробовал еще Vlad the Deployer, но он как очень урезаный Capistrano.

                                                                                                          Для деплоймента конфигов — Puppet, но не проникся как-то.

                                                                                                          Была еще тулза аналогичная владу на питоне — простая довольно. Но я не питонист, увы.

                                                                                                          Основная причина выбора именно Capistrano — я программлю на Ruby & Rails. А таски для Capistrano пишутся именно на руби. Убив день-два на то чтоб сним основательно разобраться и поэкспериментировать понимаешь, что этой штуковиной можно сделать все.
                                                                                                          • 0
                                                                                                            Ок, спасибо за инфу. Я с руби никогда не сталкивался, но думаю проблем возникнуть не должно.

                                                                                                            По поводу дебиановского репозитория — я не спец в нём и сделал достаточно просто и быстро, без всяких заморочек (создание простого пакета, создание репозитория, выливка пакетов по rsync в репозиторий и обновление его структуры). Из всех функций deb-ов я использовал едва ли 5% (к примеру не использовал цифровую подпись пакетов и при апдейне надо указывать --force-yes).
                                                                                                            Если такая информация будет интересна — могу попробовать описать блогпостом. Стоит писать?
                                                                                                            • 0
                                                                                                              Я думаю — стоит. В комментах подскажут как чего можно улучшить ;)
                                                                                            • 0
                                                                                              мораль — билдите проект.
                                                                                            • 0
                                                                                              И отдайте вообще всю историю вашей разработки, а не только последние версии. Ах да, еще и пару экспериментальных веток с мега фичами.
                                                                                            • +4
                                                                                              Мда, а везде пишут, что с svn нужно export юзать. Видимо, лень побеждает? :-)
                                                                                              • +1
                                                                                                У гита есть .git :-)
                                                                                              • +6
                                                                                                Мне вот тоже странно, что большие крупные проекты зачем-то хранят svn-файлы на пордакшне.
                                                                                                У них же всегда тестовый(-е) сервер(-а) есть.
                                                                                                Зачем при этом держать всё дерево на основных серверах — решительно непонятно. Ведь даже если не задумываться о безопасности (что очень сомнительно), есть же ещё и такая вещь, как захламление сервера ненужными файлами.
                                                                                                Есть мнение, что работать от этого быстрее система не будет.
                                                                                                Всегда пользовали export и не парили себе мозг.
                                                                                                • 0
                                                                                                  а еще есть такая вещь как скорость обновления проэкта из тысяч файлов, после изменения двух
                                                                                                  • 0
                                                                                                    да, такая проблема есть.
                                                                                                    поэтому обновление производится в часы «пик-аута» (короче, ночью-утром).
                                                                                                    И замедление системы один раз в неделю (условно говоря) лучше, чем небольшое замедление системы постоянно.
                                                                                                    к тому же, никаких проблем с файлами, которые срочно пришлось поправить на сервере (ну бывает такое иногда, хотя это нехорошо).
                                                                                                    • +1
                                                                                                      а куда спешить при обновлении?
                                                                                                      экспорт в соседнюю папку и затем замена ей папки с проектом.
                                                                                                      • 0
                                                                                                        ну или так.
                                                                                                        у нас в проекте дольше всегл переназначались владельцы файлов, так что это было непринципиально.
                                                                                                        Это и будет основной проблемой при «обновления проэкта из тысяч файлов» (авторский синтаксис;))
                                                                                                        • +2
                                                                                                          и сменить линк со старой папки на новую, если что-то не заработало — обратно перекинуть
                                                                                                          • 0
                                                                                                            я когда-то для этих целей собирал iso-образ с проектом и монтировал его, а несколько старых хранил на всякий пожарный. но можно и так, наверное =)
                                                                                                            • 0
                                                                                                              Лучший вариант. Моментальный откат на предыдущую ревизию в случае проблем.
                                                                                                          • 0
                                                                                                            Моя интуиция подсказывает мне, что перезаливать тысячи файлов ради двух неверно. Просто нужно разработать/использовать удобный метод обновления файлов: решить эту проблему.
                                                                                                            • 0
                                                                                                              .svn deny all неплохой метод, имхо
                                                                                                      • +3
                                                                                                        Трагедия! Трагедия!
                                                                                                        • +10
                                                                                                          Почем пепел? :)
                                                                                                          • +16
                                                                                                            Не публикуется и не продается ни при каких условиях.
                                                                                                            • +61
                                                                                                              «ни при каких» это сколько? ;)
                                                                                                              • +3
                                                                                                                не думаю что те кому это надо приходят с деньгами… :(
                                                                                                                • +3
                                                                                                                  Напомнило видео «Штирлиц в Одессе»: "… эти рукописи бесценны, им нет цены!!!… Но для Вас, Штирлиц, 5 тысяч.." :)
                                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                    • +1
                                                                                                                      Такие вопросы надо задавать приватно.
                                                                                                                  • +2
                                                                                                                    головы посыпать?
                                                                                                                    • 0
                                                                                                                      Растения удобрять :-)
                                                                                                                      • 0
                                                                                                                        Программистам в корм подсыпать
                                                                                                                    • 0
                                                                                                                      Давно пользуюсь SVN и изначально думал, что такое возможно. У меня принцип защиты немного другой: есть скрипт, который выполняет роль build-скрипта, он чекаутит trunk в tmp фолдер, удаляет все .svn, а потом все ложит непосредственно куда надо.
                                                                                                                      • +8
                                                                                                                        Почему не используйте экспорт?
                                                                                                                        • +6
                                                                                                                          Виноват, не знал =)
                                                                                                                          • +1
                                                                                                                            Кроме экспорта разузнайте зачем нужна папка hooks в репозитории и как использовать лежащие в ней файлы
                                                                                                                          • 0
                                                                                                                            Ага, у меня билд-скрипт тоже просто экспортирует на сервер. Даже представить не мог, что кто-то может использовать рабочую копию.

                                                                                                                            Ещё в FileZilla есть настройка — игнорировать директории .svn при заливке.
                                                                                                                            • 0
                                                                                                                              а где именно? что-то не нашёл ((
                                                                                                                              • +1
                                                                                                                                Вид -> Фильтры по названию файлов. Клавиши Ctrl+I. Нужно поставить галку «CVS and SVN directories».
                                                                                                                            • 0
                                                                                                                              хм, поправьте если ошибаюсь, а экспорт разве не обновляет все файлы а не только ревизию, что для гигантов критишно?
                                                                                                                              • 0
                                                                                                                                Экспорт можно сделать от определенной ревизии и заливать нужно будет только изменившиеся файлы.
                                                                                                                                • 0
                                                                                                                                  А как на счёт удалённых из репозитария файлов?
                                                                                                                                • 0
                                                                                                                                  Да, переписывает все.
                                                                                                                              • +2
                                                                                                                                =)
                                                                                                                                Давно написал для простого экспорта от ревизии до ревизии скрипт. Жизнь облегчает неимоверно!
                                                                                                                                Делюсь:
                                                                                                                                webiteam.ru/2009/03/eksport-iz-svn/
                                                                                                                                • 0
                                                                                                                                  Перепишите его на Linux shell script. Тогда его можно использовать как post-commit хук. Вам многие будут благодарны
                                                                                                                                  • 0
                                                                                                                                    А в чем проблема сделать shell скрипт запускающий мой? =)
                                                                                                                                    • 0
                                                                                                                                      Ну… как то не кошерно ;)
                                                                                                                                      Первое запускает второе, второе — третье и т.д. Лучше же один скрипт
                                                                                                                              • +39
                                                                                                                                Ребятам, провернувшим все это исследование обеспеченно светлое будущее.
                                                                                                                                • +61
                                                                                                                                  И внеочередные воинские звания.