Linuxformat - Вклад участника [ru]

LXF91:Системы управления версиями

2008-03-30T13:17:35Z

-=JeN=-: /* Таблица функций */

== Системы управления версиями ==
''Git или Bazaar, CVS или Subversion: что лучше для вашего проекта? Выясняет '''Грэм Моррисон'''.''

Нет сомнения: без систем управления версиями Linux никогда не достиг бы такого расцвета. Управление версиями связывает тысячи разработчиков, собирая сделанное ими и предоставляя результаты остальным.
Оно похоже на клей, удерживающий проект в целости и равновесии.

{{Врезка
| Заголовок = Про наш тест
| Содержание = Мы рассмотрели семь наиболее солидных систем управления версиями, доступных для Linux. Есть несколько прекрасных коммерческих продуктов, но мы сосредоточились на открытых решениях. Отчасти потому, что они доступны свободно, но также и потому, что открытые системы обычно одни из лучших,
независимо от цены. Мы рассматривали простоту использования, качество документации и производительность каждой системы, а также их прозрачность в работе. Победитель этого '''Сравнения''' должен быть мощным и не создавать препятствий процессу разработки.
| Ширина = 220px
}}

Все системы управления версиями используют один и тот же основной принцип. Они регистрируют изменения в программном коде – или, в правильной терминологии, отслеживают версии. Каждое изменение
(обычно представляющее собой добавление нового файла или модификацию существующего) порождает новую версию. Другой важный аспект систем управления версиями – совместная работа. Они должны позволять
разработчикам трудиться вместе и держать каждого из них в курсе изменений, сделанных товарищами.

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

=== Путь Торвальдса ===
Другой подход к совместной работе скорее похож на передачу файлов в пиринговых (peer-to-peer) сетях, чем на разработку приложений. Вместо использования центрального сервера, хранящего все данные проекта, каждый разработчик отвечает за синхронизацию своей рабочей копии проекта с остальными разработчиками. Проект становится децентрализованным. Этот подход, судя по всему, является модной тенденцией, если принять во внимание Git Торвальдса и ряд других систем, успешно применяющих децентрализованное управление версиями.

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

Если вы ищете себе систему управления версиями, сейчас самое время побольше узнать о существующих разновидностях. Это одна из областей Open Source, где коммерческие продукты сталкиваются с действительно серьезной конкуренцией, а основные инструменты становятся все лучше с каждым релизом.

=== RCS ===
Старейшая система в нашем Сравнении.

Исходная система управления пересмотрами версий (Revision Control System; да-да – RCS и вправду дей-
ствует согласно этикетке), может, и вытесняется CVS, но остается популярным выбором в некоторых особых случаях, и есть две главных причины предпочесть RCS более продвинутым решениям. Во-первых, эта система сравнительно проста в использовании и помогает овладеть основными навыками, необходимы-
ми для работы в других системах управления пересмотрами версий. Во-вторых, RCS удобна для резервного копирования файлов конфигурации и для ведения небольшой истории откатов (undo/redo). Если вам не понравятся сделанные изменения, очень легко вернуться к более ранней версии.

RCS возвращает нас во времена младенчества совместной разработки ПО, и как таковая предлагает скудный набор функций посравнению с более современными конкурентами. Крупнейший недостаток заключается в том, что RCS умеет работать только с отдельным файлом. Вашей первой мыслью станет: «Ну и что с нее толку?». И верно, из-за своих ограничений RCS – плохой выбор для управления проектом, но случается, что и с отдельным файлом надо поработать, и узконаправленный подход RCS будет более оправдан.

Другое ограничение – в одно и то же время с файлом может работать лишь один разработчик. Один файл, один активный редактор: это не делает RCS самой гибкой системой в мире. Если ваши требования к редактированию отдельного файла выходят за пределы элементарного сотрудничества, ищите дальше.

Будучи старой, и официально входящей в состав проекта GNU, RCS распространена повсеместно – вы найдете ее предустановленной на многих системах, а если нет – инсталляция обычно сводится к простому щелчку мышью в менеджере пакетов вашего дистрибутива. Сейчас это скорее исторический экспонат, чем действительно полезный инструмент (мы бы использовали ее для случайного конфигурационного файла, но вряд ли для чего-то еще), но она служит хорошим введением в мир систем управления версиями, и
вряд ли отпугнет слишком многих людей.

{{Врезка
| left
| Заголовок = Вердикт
| Содержание =
'''RCS''' 
'''Версия''': 5.7 
'''Сайт''': http://www.gnu.org/software/rcs/rcs.html 
'''Лицензия''': GPL 
Малость староват, чтобы рассматриваться всерьез, но раз уж он установлен в большинстве систем по умолчанию, его, возможно, стоит попробовать. 
'''Рейтинг''' 3/10
|Ширина=320px
}}

=== CVS ===
Второе открытие RCS для тысяч хакеров.

Именно с CVS все становится серьезным. Она была разработана для решения основной проблемы RCS: ограниченности работой с отдельным файлом.
Дик Груне [Dick Grune], первоначальный разработчик CVS, нуждался в инструменте для совместной работы над проектом компилятора C с двумя своими студентами, поскольку расписания всех троих резко отличались.

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

CVS также решает проблему множества пользователей за счет использования клиент-серверной модели. Наличие разработчиков, параллельно работающих над одними и теми же файлами (отсюда и полное имя системы – Concurrent Version System, система управления параллельными версиями) означает, что для обработки изменений CVS нуждается в сервере. Она блокирует файлы, которые изменяются, или предоставляет простой доступ только на чтение. Сервер CVS также способен управлять более чем одним
проектом (они хранятся в виде «модулей»). Хотя команды обработки файлов во многом похожи (checkout, update, commit), их теперь нужно исполнять из оболочки CVS, а не из командной строки, как это было в RCS.

Также усложнился запуск или подключение к серверу, но это не слишком обременительно для среднего программиста. CVS по-прежнему хороший выбор, и, подобно RCS, устанавливается по умолчанию с большинством операционных систем Linux, получая при этом преимущества повсеместной поддержки. Многие инструменты и приложения Linux все еще собираются с использованием CVS – это по-прежнему самая популярная система управления версиями – и практически для каждой крупной ОС существует масса
графических клиентов на выбор.
{{Врезка
| left
| Заголовок = Вердикт
| Содержание =
'''CVS''' 
'''Версия''': 1:1.12 
'''Сайт''': http://www.nongnu.org/cvs 
'''Лицензия''': GPL 
CVS является хорошим выбором, просто потому, что многие другие разработчики уже используют ее. Но вы ее перерастете.
'''Рейтинг''' 6/10
|Ширина=320px
}}

=== Aegis ===
Первая альтернатива клиент-серверной модели.

Впервые выпущенная в 1991 году, Aegis применяет иной подход к управлению версиями, заметно отличаясь
от Subversion и CVS. Например, изменения децентрализованы, а цикл разработки управляется тестами. Последнее – это методология экстремального программирования, где программист обязан предъявить несколько тестов, прежде чем включить в приложение новую функцию. В результате ваша локальная «песочница» включает только те файлы, с которыми работаете вы, что приводит к путанице, если вы привыкли иметь полную рабочую копию всего проекта.

Это – часть крупнейшей проблемы Aegis: трудности использования. Хороший пример - настройка репозитория. Прежде чем приступить к использованию Aegis, вам нужно создать новый проект, содержащий несколько файлов конфигурации. Для этого проекта желательно создать отдельного пользователя, отчасти потому, что модель безопасности Aegis полностью полагается на права доступа к файлам, а отчасти потому, что это обеспечивает приличный уровень безопасности. Для предоставления доступа другим пользователям используются права группы, а значения umask определяют доступ группы к каждому
конкретному проекту.

Aegis успешно использует функции Unix, реализованные в любой Linux-системе. Здесь нет интегрированной поддержки совместной работы по сети, но проект можно легко разделять, используя стандартные протоколы типа FTP, HTTP и NFS. Документация даже хвастает поддержкой «беговой сети», когда участники берут ноги в руки и мчатся по коридору к компьютеру, куда нужно скопировать проект. Не слишком удобно для больших расстояний.

Эта сложность отчасти компенсируется документацией хорошего качества, доступной в сети, хотя и в виде плохо отформатированного HTML. Есть несколько графических интерфейсов (использующих Tk) для общих команд, и отличная web-оболочка, но они не конкуренты многим сторонним приложениям, доступным для CVS или Subversion.

{{Врезка
| left
| Заголовок = Вердикт
| Содержание =
'''Aegis''' 
'''Версия''': 4.22 
'''Сайт''': http://aegis.sourceforge.net 
'''Лицензия''': GPL 
Неудобна и сложна в использовании, но ее особый набор функций может оказаться созвучным вашему стилю
разработки.
'''Рейтинг''' 5/10
|Ширина=320px
}}

=== Monotone ===
Система с собственным сетевым протоколом.

Monotone – это управление версиями для нынешнего поколения разработчиков. Здесь нет старых технологий или старого исходного кода. Выбран распределенный подход, без центрального сервера. Вместо этого каждый клиент отвечает за синхронизацию изменений со всеми другими – во многом тем же способом, каким работает протокол предоставления файлов в общий доступ. Он работает за счет сохранения локальной копии каждого изменения в базе данных SQLite и сравнения версий файлов с использованием алгоритма хэширования SHA1.

Установка проста, и полная версия превосходит Aegis. Используя командную строку и команду Monotone, вы сперва создаете базу данных, затем генерируете пару ключей SHA1 для подписывания своих файлов. Пользователям Subversion и CVS покажется очень знакомой работа репозиторием. Команды add (добавле-
ние), status (состояние) и commit (фиксация) имеют синтаксис, почти идентичный CVS.

Различие проявляется при слиянии ваших изменений с ветвями разработки других людей. Вам сначала нужно экспортировать свой открытый ключ и получить копию от ваших коллег. Затем они должны импортировать ваш общий ключ в «связку ключей» своего Monotone. После добавления имен коллег в локальный файл разрешений круг доверия замыкается, и вам нужно просто запустить команду server в
Monotone. После этого каждый зарегистриро- ванный пользователь сможет синхронизироваться с вашей рабочей копией дерева разработки, используя команду sync. Для копирования данных через интернет или локальную сеть Monotone использует собственный протокол, NetSync. Но поскольку он использует один порт (4691), его довольно легко пробросить через SSH-туннель – чтобы обойти слишком усердные брандмауэры.

Единственный недостаток – отсутствие графических инструментов, помогающих управлять репозиторием. Единственный существующий вариант, Monotone-viz, великолепен для отображения ветвей проекта, но слабо подходит для чего-то еще.
{{Врезка
| left
| Заголовок = Вердикт
| Содержание =
'''Monotone''' 
'''Версия''': 0.32 
'''Сайт''': http://www.venge.net/monotone 
'''Лицензия''': GPL 
Monotone сочетает свежий подход к управлению версиями с прекрасной документацией, эффективностью и
энтузиазмом.
'''Рейтинг''' 7/10
|Ширина=320px
}}

=== Subversion ===
Набирающая популярность альтернатива CVS, богатая графическими оболочками.

Когда вы какое-то время используете CVS, определенные моменты становятся настоящей проблемой. Первый – любые файлы и каталоги, которые вы перемещаете в пределах своей локальной копии, не будут учтены в изменениях. Они ускользают от радара CVS, и их нужно добавлять как новые файлы; а значит, теряется вся накопленная история и информация об изменениях файла или каталога. Поначалу это не проблема, но когда вы в проекте шесть или двенадцать месяцев, это превращается в настоящую пытку.

Другая серьезная беда CVS заключается в том, что ‘commit’ не выполняется одним махом, атомарно. Вместо этого он запускается для каждого изменения, насколько это ему удается. Если разработчику случается в это время редактировать файл, значит, ему не повезло. Subversion решает обе эти про-
блемы, а также исправляет другие недочеты CVS, например, обеспечивает версионность символических ссылок и реализует поддержку двоичных файлов.

В результате Subversion довольно быстро вытесняет CVS как предпочтительную систему управления версиями, и многие выдающиеся проекты, включая GCC, Samba, Mono, Apache, Python и KDE, переключаются на него для управления исходным кодом.

==== Без боли ====
Нет сомнений, что Subversion популярна именно благодаря сходству с CVS. Она использует ту же самую клиент-серверную модель, и основная масса ее команд – двойники команд CVS. Кроме переноса истории версий вашего проекта, переключение с одной системы на другую проходит относительно безболезненно. Зачастую вам может сойти с рук простая замена команды CVS на svn-эквивалент. Установка прямолинейна, и вы найдете пакеты Subversion почти в каждом дистрибутиве Linux, вышедшем за последнюю пару лет.
Клиент полезен и сам по себе, а в некоторых случаях он может оказаться единственным способом скачать версии разработчика какого-нибудь интересного вам проекта. Вы также обнаружите изобилие графических
интерфейсов, пытающихся сроднить командную строку с преимуществами графических инструментов. Популярный выбор – ksvn для KDE и более общий esvn. Поддержка Subversion также встроена во многие интегрированные среды разработки, включая KDevelop, Eclipse (с расширением Subclipse), Zend Studio и Xcode от Apple.

Что касается доступа к серверу, большинство крупных проектов применяют в этом качестве популярный модуль Apache WebDAV, предоставляющий доступ к web-серверу на чтение-запись.Установить его не слож-
но, и раз уж модуль Apache загружен должным образом, настройка тоже дело простое. Вы, скорее всего, обнаружите, что ваш дистрибутив включает этот модуль, заранее скомпилированный для вашей версии Apache. Есть и более простое решение, удобное для небольших групп разработчиков – использовать интегрированный в Subversion протокол SVN, как сам по себе в доверенной сети, так и через SSH-туннель, если ваши коллеги разбросаны по всему Интернету.

Subversion – не самое эффективное ПО для управления версиями. Полная копия репозитория сохраняется в скрытом каталоге, что имеет свое преимущество – можно вносить изменения, когда сеть недоступна – но требует очень много места. База данных истории изменений также может расти экспоненциально, по мере внесения изменений всеми разработчиками, и вам необходимо обеспечить регулярное резервирование базы данных Berkeley. Сценарии резервирования предусмотрены, и они присоединяются к «ловушкам» (hooks). «Ловушки» вызываются определенными событиями, например, внесением изменений (commit) разработчиком, и предоставляют эффективный способ настройки сервера Subversion под ваши нужды.

Благодаря своей повсеместности, Subversion обещает более высокий уровень поддержки сообществом, чем многие другие системы управления пересмотрами. Есть книги, форумы, списки рассылки и свободно
публикуемая документация; они помогут вам приступить к работе. Многие проблемы можно решить, скопировав сообщение об ошибке в строку поиска Google, чего нельзя сказать о Monotone или Bazaar. Добавим сюда относительную простоту установки репозитория Subversion или присоединения к открытой
разработке, размещенной на другом сервере (как SourceForge, так и Google Code сейчас используют Subversion), и Subversion становится непревзойденной.
{{Врезка
| left
| Заголовок = Вердикт
| Содержание =
'''Subversion''' 
'''Версия''': 1.4 
'''Сайт''': http://subversion.tigris.org 
'''Лицензия''': Apache/BSD 
Subversion – вне всякой конкуренции. Она комплексна, предельно модифицируема и отлично поддерживается.
'''Рейтинг''' 9/10
|Ширина=320px
}}

=== Git ===
Кто сказал, что Линус был сердит?

Даже если вы не интересуетесь программами управления ревизиями, имя Git вам, вероятно, попадалось
на том мощном форуме, Slashdot. Git – это еще один плод разума Линуса Торвальса, и появился он со скандалом. В мире «До Git» многие основные разработчики ядра Linux использовали закрытый инструмент управления пересмотрами под названием BitKeeper. Но когда в начале 2005 г. было объявлено об отзыве бесплатной версии BitKeeper, в ответ на поднявшийся в сообществе шум Торвальдс разработал Git. Он объявил, что Git – это вам не просто система управления ревизиями, а скорее усовершенствованная файловая систему. Прежде всего, однако, Git разрабатывался с прицелом на производительность. Когда вы
работаете с проектом масштаба ядра Linux, производительность – это все.

Подобно Monotone, Git – распределенная система, без сервера. Но в то же время, в Интернете есть серверы, используемые в качестве центрального репозитория для определенных проектов: прекрасный пример – http://www.kernel.org. Различие между использованием их и чего-то вроде Subversion заключается в том, что если данные на kernel.org будут утрачены, последнюю версию ядра можно будет снова собрать из кода, распределенного среди разработчиков, потому что каждый из них имеет собственную рабочую копию репозитория в подкаталоге .git.

Минуло почти два года, и Git настолько упрочил свои позиции, что вы найдете его либо установленным по умолчанию, либо на расстоянии всего нескольких щелчков мышью в менеджере пакетов каждого свежего дистрибутива Linux. Несмотря на свою репутацию инструмента для хакеров, он сравнительно прост в использовании. Например, репликация удаленного репозитория – это обычно трудоемкая работа. Но в случае с Git это легко. Просто выполните git clone, указав URL удаленного репозитория. Другие коман-
ды работают подобно аналогичным функциям в Subversion, и есть прекрасная утилита для обеспечения взаимодействия между двумя системами.
{{Врезка
| left
| Заголовок = Вердикт
| Содержание =
'''Git''' 
'''Версия''': 1.4 
'''Сайт''': http://git.or.cz 
'''Лицензия''': GPL 
Всего двух лет от роду, Git является высокопроизводительным, серьезным решением для крупнейших проектов.
'''Рейтинг''' 7/10
|Ширина=320px
}}

=== Bazaar ===
Система управления версиями, спонсируемая Canonical.

Bazaar – наследник распределенной системы управления версиями, Bazaar-NG, возникший благодаря спонсорской поддержке от Canonical Ltd. Неудивительно, что Bazaar используется разработчиками
Ubuntu и старается быть как можно более понятным. Хотя он использует распределенную модель, многие из команд очень похожи на команды CVS или Subversion. Поскольку центральный сервер отсутствует, вы заметите различия только когда захотите предоставить в общий доступ свою локальную рабочую
копию – вам нужно будет вытянуть (pull) изменения с удаленного репозитория и объединить (merge) со своими изменениями.

Документация великолепна, включая учебники, охватывающие сложные темы, например, отслеживание главной версии и интеграцию с CVS. Базовый учебник даже проводит вас через ряд основных концепций, характерных для всех утилит управления версиями – прекрасный букварь для начинающих. Публикация вашей работы также освежающе проста. Просто скопируйте содержимое свое го рабочего каталога на web-сервер, и другие разработчики смогут забирать копии вашей ветви оттуда. Вы можете синхронизировать
ее со своей рабочей копией, используя rsync; в протокол также встроена поддержка SFTP, вызываемая через команду push.

Bazaar использует интерфейс расширений для обеспечения дополнительных функций. Например, несколько графических компонентов на GTK2 можно запускать прямо из командной строки Bazaar. Скажем, ввод bzr
visualize откроет визуализатор ветви, который выглядит подобно визуализатору Git. Есть также графические компоненты для команд commit, diff, annotate и branch.

Bazaar трудно не полюбить. У него тот самый разумный подход, который создал популярность Ubuntu, а графические интерфейсы здорово помогают людям, напуганным множеством опций командной строки.
{{Врезка
| left
| Заголовок = Вердикт
| Содержание =
'''Bazaar''' 
'''Версия''': 0.11 
'''Сайт''': www.bazaar-vcs.org 
'''Лицензия''': GPL 
Bazaar имеет великолепные графические инструменты и прост в понимании. Наша любимая распределенная система управления версиями.
'''Рейтинг''' 8/10
|Ширина=320px
}}

=== Вердикт ===
'''Subversion 9/10'''

Если честно, мы приступали к этому '''Сравнению''', думая, что это будет игра в одни ворота. Все мы использовали Subversion, были знакомы с тем, как она работает, и в большинстве наших проектов
также используется Subversion. Кому ж еще победить?

Что ж, так и вышло, но не с такой легкостью, как мы думали. Распределенные модели, используемые Monotone, Bazaar и Git, удивительно просты в использовании, а отсутствие центрального сервера – реальная инновация. Если бы мы выбирали распределенное решение, это был бы Bazaar. Благодаря раз-
работчикам из Canonical, он выглядел самым ухоженным и проработанным из трех. Но и Git, и Monotone удивили нас своим удобством, и в следующие двенадцать месяцев мы можем стать свидетелями захвата ими значительной доли рынка за счет некоторых других систем.
{{Врезка
| Заголовок = Ваше мнение
| Содержание = Кому нужна помощь в изучении использо-
вания систем управления версиями, может
взять наш учебник Subversion в wiki Linux
Format (http://linuxformat.co.uk/wiki). Но сис-
темы управления версиями – не только для
программистов. Сообщите нам, если приду-
маете какое-то крутое применение для сис-
темы управления версиями. Например,
в LXF82 мы перевели на Subversion наш
домашний каталог. Присылайте свои идеи
на letters@linuxformat.ru.
|Ширина=220px}}
В конечном итоге, никто не обогнал Subversion. Здесь больше функций, чем в любой другой рассмотренной нами системе, выше стабильность и полнее поддержка. Subversion также сравнительно проста для каждого, имеющего опыт работы с CVS, да и вообще удобна – и для маленьких проектов с
парой программистов, и для огромных, имеющих тысячи разработчиков. Именно комбинация проверенной и заслуживающей доверия технологии с разносторонностью, достаточной для удовлетворения потребностей большинства людей, позволила Subversion победить. Наличие ряда графических оболочек, как и
интеграция во многие популярные IDE, также помогли сделать Subversion хорошим выбором для тех, кто не хотел бы надолго оставаться один на один с командной строкой.

Без сомнения, в целом качество систем управления версиями, рассмотренных в этом '''Сравнении''', невероятно высокое. Даже последние двенадцать месяцев продемонстрировали впечатляющий прогресс. Достаточно взглянуть, каких успехов достиг Git за столь короткое время, чтобы понять, как быстро все
это развивается, и насколько жизненно необходимыми являются системы управления версиями для будущего Linux. И если по усердию, с которым разрабатываются системы управления версиями, судить о будущем Linux, то оно выглядит прекрасным.

=== Врезки ===
==== Терминология управления версиями ====
Несмотря на значительные различия между отдельными системами управления версиями, они используют общие термины:
*'''Репозиторий (repository)'''. Здесь размещаются все файлы проекта. Репозиторий может размещаться на удаленном сервере, локально на вашем компьютере, или и там, и там.
*'''Рабочая копия (working copy)'''. Ваша личная версия репозитория, включающая все сделанные вами изменения и модификации. Также известна как «песочница» (sandbox).
*'''Фиксация (commit)'''. Загрузка в репозиторий изменений, которые вы сделали локально. Если возникнут конфликты, вам нужно будет разобраться с ними.
*'''Ветвь (branch)''' или '''ответвление (fork)'''. Пометка набора изменений как изолированных от основной ветви разработки. Удобно для работы над новыми версиями и выпусками исправлений.
*'''Выписка (checkout)'''. Получение копии проекта из рабочего репозитория. Впоследствии она становится вашей рабочей копией.

==== Таблица функций ====
[[Изображение:Lxf91_func_tabl.PNG|800x250px]]

LXF91:Системы управления версиями

2008-03-30T13:15:40Z

-=JeN=-: /* Таблица функций */

LXF91:Системы управления версиями

2008-03-30T13:14:14Z

-=JeN=-: /* Таблица функций */

Файл:Lxf91 func tabl.PNG

2008-03-30T13:13:42Z

-=JeN=-: LXF91. Таблица функций, 25 страница, третья по счету врезка.

LXF91. Таблица функций, 25 страница, третья по счету врезка.

LXF91:Системы управления версиями

2008-03-30T13:12:31Z

-=JeN=-:

-=JeN=-:

LXF91:Дневники демонов

2008-03-10T15:58:04Z

-=JeN=-: Новая: == Ведение журналов Syslog и его окрестности. Записки демонов == ''Учитесь правильно читать файлы журналов:...

LXF91:15 мгновений безопасности

2008-03-10T15:50:05Z

-=JeN=-:

== 15 ценных советов по безопасности ==
''Думаете, ваш компьютер с Linux защищен? Вы уверены? Даже самая безопасная ОС станет легкой добычей, если пренебрегать основными правилами. '''Грэм Моррисон''' даст 15 советов, чтобы предприимчивый взломщик плюнул на ваш ПК и убрался вон...''
 
=== Усильте пароли пользователей ===
Знаем, это похоже на надоевшую проповедь. Кто хоть раз читал это, читал и тысячу раз: слабый пароль – самая частая «точка входа» потенциального взломщика. Но к проповеди все глухи. В октябре прошлого
года 34 тысячи паролей пользователей MySpace '''[myspace.com – популярный сайт и сетевое сообщество – ''прим. пер.'']''' были похищены в результате атаки фишеров, реализованной через поддельную страницу входа в систему. MySpace получил серьезную пробоину, а эксперт по безопасности Брюс Шнайер [Bruce Schneier] – прекрасную возможность заглянуть в коллективный разум 34-х тысяч типичных пользователей компьютера. Тремя самыми популярными паролями оказались ''password1'', ''abc123'', а самым креативным – ''myspace1''. Шнайер ехидно отметил, что пользователи MySpace как минимум научились добавлять цифры к легко угадываемому слову, хотя все еще используют символы только в нижнем регистре.

Вот такие пароли выбираются типичными пользователями для защиты своих драгоценных данных.
Если вы недостаточно напуганы, скачайте инструмент взлома паролей вроде John the Ripper (www.openwall.com/john) и натравите его на свой файл с зашифрованными паролями (см. LXF84). Шнайер
рекомендует брать пароль, не включающий ни обычные слова, ни какие-либо производные сокращения, ни даты, которые легко узнать: все они подвержены атакам по словарю. Смешивайте регистры и добавляйте небуквенные символы.

=== Установите пароль BIOS ===
Не будем зацикливаться на паролях; это последнее упоминание о них. Но раз уж вы защитили свою учетную запись паролем, недоступным даже вашему двойнику из параллельной вселенной, почему бы не
применить эту теорию к другим областям? Если вас беспокоит, что кто-то имеет физический доступ к вашей машине – например, она используется как сервер в небольшом офисе – установите стойкий
пароль на BIOS вашей системы. Эта программа загружается первой, непосредственно отвечает за первичную настройку вашего оборудования и проверяет, что все работает должным образом.

Многие BIOS можно настроить на запрос пароля во время загрузки. Есть множество типов BIOS, и настройка будет зависеть от специфики вашего оборудования. Обычно, чтобы попасть в меню BIOS,
следует удерживать [F2] во время загрузки машины, затем выбрать страницу '''Security''', где вы сможете установить свой пароль. После этого единственным способом загрузить вашу систему, не зная пароля, будет очистка памяти BIOS – обычно тут не обойтись без вскрытия корпуса и извлечения бата-
рейки материнской платы '''[не обольщайтесь – зачастую достаточно просто снять специальную перемычку; кроме того, некоторые версии BIOS принимают т.н. «инженерный пароль», – ''прим. ред.'']'''.

=== Установите брандмауэр ===
Пару лет назад считалось чистым безумием подключаться к Интернету без брандмауэра. Правда заключается в том, что брандмауэры воспринимаются совершенно неправильно. Они лишь блокирует доступ
к определенным сетевым портам на вашей машине. Если нет сервиса, прослушивающего этот порт, злонамеренный удаленный процесс не получит доступа к вашей системе независимо от того, запущен бранд-
мауэр или нет. Именно поэтому Ubuntu не запускает брандмауэр по умолчанию: там просто не работают никакие сетевые сервисы, которыми мог бы воспользоваться злоумышленник. Брандмауэр может помочь только в том случае, если к вашей машине осуществляются как доверенные, так и не заслуживающие доверия сетевые подключения. В этом случае брандмауэр будет оберегать небезопасные сервисы от доступа из потенциально опасной сети. Уязвимыми сервисами могут быть внутренний web-сервер или общие ресурсы NFS.

Функции брандмауэра в Linux фактически выполняются ядром,
благодаря сложному инструменту iptables, используемому для филь-
трации и перенаправления пакетов. Можно строить правила вруч-
ную, используя команду iptables, но большинство пользователей
предпочитают графический интерфейс. Хороший выбор – Firestarter:
он предлагает «мастера», помогающего выполнить стандартную
настройку и даже разделить ваше интернет-соединение с другими
компьютерами локальной сети. Вы всегда можете проверить эффек-
тивность защиты, используя для тестирования брандмауэра внешний
сайт, например, Shields Up (www.grc.com/x/ne.dll?bh0bkyd2).

=== Разберитесь с правами ===
Многие из нас в курсе, что Unix-подобные ОС вроде Linux используют права для предоставления доступа к файлам и приложениям, но как убедиться, что они настроены должным образом? Взгляните на содержи
мое своего каталога '''/home''', набрав в командной строке '''ls -l /home'''. Вывод ls, вероятно, будет подобен этому:
drwxr-xr-x 66 graham graham 2904 2007-01-23 10:09 graham
В выводе будет запись для каждого пользователя вашей системы, и проблема заключается в строке прав
доступа – '''drwxr-xr-x'''. Если коротко, то '''d''' – это признак каталога, '''rwx''' – права доступа владельца файла (чтение, запись и исполнение), первые символы '''r-x''' – права группы, а вторые '''r-x''' – права всех остальных. Следующая часть, '''graham graham''',обозначает пользователя и группу, владеющих этим каталогом. Многие дистрибутивы глобально открывают домашние каталоги пользователей на чтение, а значит, каждый, имеющий доступ к вашей машине, сможет прочитать содержимое вашего домашнего каталога. Вам следует изменить права с помощью chmod. Например, '''chmod go-rx /home/graham''' отнимет доступ на чтение и исполнение у всех пользователей в этой же группе, а также у всех прочих пользователей.
Руководство по правам доступа для начинающих.

=== Следите за sudo ===
Для быстрого запуска приложений с привилегиями администратора системы в Ubuntu применяется утилита ''sudo''. Именно для этого ''sudo'' и разработана. Но предоставление любому пользователю доступа через sudo может быть рискованно с точки зрения безопасности, поскольку вы не контролируете, кто и что запускает. Решение – разрешить использование ''sudo'' только конкретным пользователям и точно настроить, какой доступ и к каким средствам им необходим.

Для редактирования привилегий sudo существует файл конфигурации, но изменять его нужно собствен
ным vi-подобным редактором под названием visudo. Первое, что нужно сделать – это отредактировать строку '''root ALL=(ALL) ALL''', заменив '''root''' на список пользователей (через запятую), которых вы хотите допустить к командам, требующим повышенных привилегий. Другой частый пример – заменить секцию после '''‘ALL=’''' на список каталогов (тоже через запятую), к которым вы хотите предоставить доступ перечисленным пользователям: два наиболее типичных случая – '''/sbin''' и '''/usr/sbin'''.
Чтобы подпускать к учетной записи root только пользователей – членов группы admin, введите следующее:
%admin ALL=(ALL) ALL

=== Не используйте setuid – правда! ===
'''Setuid''' – прекрасная практическая идея: это просто еще один бит прав доступа, наряду с чтением, записью и исполнением, позволяющий запускать команду с привилегиями владельца файла. То есть обычный пользователь может выполнять команды администрирования, если привилегии, требуемые для их выполнения,
определены правом '''setuid'''. '''Setuid''' также полезен для приложений, работающих с оборудованием, доступным только администратору: например, приводов CD-RW. Но применение '''setuid''' создает значительный риск. Если использующая его команда по той или иной причине «рухнет», запустившему ее пользователю могут достаться привилегии «погибшей» программы. Плохие ребята, взламывающие Linux, точно знают, какие setuid-инструменты можно уговорить вести себя неправильно.

Хороший пример использования '''setuid''' – команда ''ping'', требующая административных привилегий для получения доступа к сети.Команда '''ls -l /bin/ping''' выдаст следующее:
-rwsr-xr-x 1 root root 30804 2006-10-16 18:32 /bin/ping
Дополнительный символ '''s''' в секции прав показывает, что бит '''setuid''' установлен. Во время выполнения ''ping'' получает права пользователя-владельца файла, в данном случае это '''root'''. Оставить инструменты с установленным '''setuid''' в вашем дистрибутиве – приемлемый риск, но вы должны дважды подумать, прежде чем использовать его для упрощения жизни при написании своих собственных скриптов.

=== Запускайте проверку на вирусы ===
Хотя Linux не слишком обременен разрушительными вирусами, все же сравнительно легко непреднамеренно пропустить вирус к тем, с кем вы взаимодействуете, потому что на вашем рабочем столе могут потихоньку дремать зараженные файлы – плод злонамеренного почтового сообщения или скачивания. Даже если они не в силах сделать ничего дурного на вашей Linux-системе, они по-прежнему способны причинить вред какой-нибудь другой ОС. Запуск антивирусного ПО на вашем Linux-компьютере даст вам душевное спокойствие при отправке файлов вашим знакомым, а также отловит подозрительные двоичные
файлы, не позволив им покинуть лабораторию.

Наш любимый антивирусный пакет – ''ClamAV'', имеющий версии для Mac и Windows, если вы хотите соблазнить друзей открытым ПО. Он полностью бесплатен, и база данных известных вирусов обычно
обновляется в течение 24 часов с момента обнаружения нового вируса. ''ClamAV'' выиграл наше сравнение антивирусов в [[LXF74|LXF74/75]], поскольку он достаточно гибок для использования как на почтовом сервере, так и в настольной системе. Если он установлен, вы можете проанализировать любые подозрительные файлы, просто щелкнув на файле правой кнопкой мыши и выбрав пункт «сканирование на вирусы».

=== Закалите SSH ===
Теперь, когда вы сделали пароли более стойкими, захватить машину удаленно – через SSH – будет куда как труднее. Но вы можете сделать еще больше, чтобы быть уверенным, что какой-нибудь пацан с другого континента не покопается в ваших личных файлах. Первое – это запретить удаленный доступ пользователю root в конфигурационном файле SSH. Откройте '''/etc/sshd.conf''' или '''/etc/ssh/sshd_config''' в своем любимом текстовом редакторе и убедитесь,что опция '''PermitRootLogin''' установлена в '''no'''. Теперь вам, а заодно и
пацану с другого континента, нужно будет получать доступ с правами root через учетную запись обычного пользователя.

Еще одна опция, которую стоит поискать в файле конфигурации – '''Protocol 2'''. Любые другие строки с '''‘Protocol’''' нужно закомментировать, поскольку они разрешают соединения, использующие менее безопасные ранние версии протокола, лишая вас при этом множества преимуществ.

=== Заприте SSH на ключ ===
Самый безопасный способ работать с SSH – это использовать для аутентификации соединения пару из открытого и закрытого ключей и запретить доступ к SSH-серверу с обычным паролем. Вы можете сгенерировать ключи на клиенте с помощью '''ssh-keygen -t dsa'''. У вас будет запрошено месторасположение ключа (его можно оставить по умолчанию), а затем парольная фраза. Если вы оставите парольную фразу пустой, при создании нового SSH-соединения никакие пароли запрашиваться не будут, и соединение будет установлено прозрачно. Это полезно для автоматизации таких задач, как удаленное резервное копирование, но каждый, имеющий копию этого ключа, сможет под ключиться к вашему серверу.

Следующий шаг – скопировать открытый ключ на сервер. Это выполняется командой
ssh-copy-id -i ~/.ssh/id_dsa.pub server_address
Теперь вы должны получить возможность подключаться к своему SSH-серверу, используя аутентификацию по ключу. Если вы столкнетесь с проблемами, первым делом убедитесь, что аутентификация по открытому ключу разрешена в файле конфигурации SSH (это выглядит как '''PubkeyAuthentication yes'''), а если это не поможет, убедитесь, что и ваш домашний каталог, и каталог '''.ssh''' на удаленной машине имеют права доступа '''‘drwx------’'''. Наконец, когда все заработает, запретите в конфигурационном файле SSH аутентификацию по паролю.

=== Раздавайте свой открытый ключ ===
Если вы приедете на одну из крупных конференций разработчиков открытого ПО, например, OSCon, Akademy или Guadec, вы, вероятно, увидите странный пункт в программе мероприятия, называющийся
‘key signing party’ («вечеринка подписания ключей», не путайте с ‘key party’ '''[key party – вечеринка, в начале которой мужчины складывают ключи от машин в кучу, а в конце женщины выбирают случайный ключ, определяя тем самым своего сексуального партнера, – ''прим. пер.'']'''). Это возможность для разработчиков поделиться открытыми PGP-ключами, а также единственный способ получить на 100% достоверный ключ, не перехваченный при пересылке (что известно как «атака посредника»). Пусть вы не разработчик, но распространение своего открытого ключа по доверенному каналу – прекрасный
способ подтвердить свою личность, во многом подобный подписи в реальной жизни.

Сперва вам нужно создать ключ, набрав '''gpg --gen-key'''. Выберите опции по умолчанию с размером ключа '''‘4096’''' для параноиков и введите свой адрес электронной почты. Важнейшая часть – ключевая
фраза, она используется для защиты вашего ключа таким же способом, как пароль защищает учетную запись. Чем длиннее и случайнее по своей природе эта фраза, тем сложнее ее взломать. Вы должны будете отправить идентификатор своего ключа на электронный адрес, прежде чем получить список всех ключей, которые собираетесь подписывать.

На самой вечеринке вы можете удостоверить личности людей в списке и подлинность их ключей. Затем вы отправляете их ключи к своему и отсылаете копию партнеру, который поступает так же – тем самым будет построена так называемая «сеть доверия» между участниками. PGP-ключи также можно использовать для шифрования файлов и электронных сообщений, предназначенных к отправке через небезопасную сеть. Ими гораздо проще управлять, когда используются графические интерфейсы типа ''Kpgp'', или когда они
интегрированы в почтовый клиент типа ''Evolution'' или ''KMail''.

=== Проверяйте системные журналы ===
Linux – одна из самых разговорчивых ОС. В журналах можно найти запись почти для каждой возникающей проблемы. Возможно, именно по этой причине очень немногие из нас не ленятся их просматривать.
Что довольно глупо, поскольку файлы журналов могут показать, как атаковалась ваша система и какие меры следует предпринять, чтобы атаки терпели поражение.

Все системные файлы журналов размещаются в каталоге '''/var/log''', и можно многое узнать, просто просматривая их время от времени. Файл с именем '''messages''' – хорошее место для старта. Он содержит общие сообщения системы, а также протокол загрузки. Протокол последней загрузки также можно отобразить командой '''dmesg'''. Если вы хотите найти что-нибудь определенное, вам поможет '''grep'''. Используйте команду '''tail -f''', чтобы просматривать на экране последние записи в жур-
нале и команду '''logger''' для добавления собственных сообщений.
Читайте о ведении журналов в статье [[LXF91:Дневники демонов|"Дневники демонов"]].

=== Будьте на шаг впереди ===
Когда вы обнаружите проблему, не тяните с решением. В случае спама для поимки виновного мало что можно сделать. Но в Интернете можно найти обратный адрес отправителя, а также машину, использованную для отсылки сообщения, и добавить ее адрес в базу данных своего спам-фильтра (вы же используете спам-фильтр, не так ли?). А вот об атаках фишеров следует сообщать. Во-первых, организации, которая оказалась под атакой, а во-вторых, на сайт, отслеживающий фишеров, например, www.antiphishing.org.

Другой способ активной защиты: если у вас работает сервер SSH, приглядывайте за файлом '''/var/log/auth.log''', и рано или поздно увидите, что кто-то пытался угадать ваш пароль, чтобы дорваться до
вашей машины. Строка в журнале может выглядеть, например, так:
Failed password for invalid user test from ip_address port 55218 ssh2

Здесь кто-то пытался соединиться с вашей машиной как пользователь '''test''', но потерпел неудачу.
Вы узнаете больше о компьютере, который покушался на вашу машину, набрав '''whois ip_address;'''
вывод зачастую включает номер контактного телефона. В большинстве случаев это окажется обычный провайдер, который более чем заинтересован в сведениях, что один из его клиентов пытался получить неавторизованный доступ к чужой системе.

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

Шифрование поможет в этой беде. Есть две опции, поддерживаемых среднестатистической точкой доступа: WEP и WPA. WEP старше, и имеет известные уязвимости. Если кто-то стянет достаточно данных, зашифрованных с помощью WEP, из этих данных вполне осуществимо извлечь ключ, и ваше соединение будет взломано. WPA, напротив, сейчас считается безопасным. Единственная проблема WPA заключается в том, что в Linux беспроводные драйверы только начали поддерживать его.

Оба метода работают, в общем, одинаково. Вы задаете пароль для точки доступа и используете его на вашем ноутбуке для подключения к сети. Благодаря современным инструментам Linux, таким, как ''Network
Manager'' в Gnome и его KDE-эквивалент, управление паролями выполняется весьма просто. Как только пароль будет принят, вы сможете свободно использовать свое соединение.

=== Поддерживайте актуальность ===
На данный момент у вас могла возникнуть мысль, что определенные экземпляры ПО в Linux уязвимее других. Чем больше программ у пользователя, тем вероятнее, что будет обнаружена уязвимость или ошибка. Все, что имеет выход в Интернет, всегда подпадает под больший риск, чем небольшая программа с малым количеством доверенных пользователей, и поэтому проблемы с пакетными версиями Apache и PHP являются вполне обычными. Чтобы контролировать эти проблемы, следует регулярно обновлять свою систему. Многие дистрибутивы Linux сейчас включают менеджер обновлений, который доставляет их на вашу
систему по мере обнаружения уязвимостей. Вы должны убедиться, что это действительно происходит. В частности, в Ubuntu слишком легко отключить ''Update Manager'' и забыть запустить его вновь. Это очень печально, поскольку для 6.06 LTS обещаны обновления безопасности в течение пяти лет.

=== Учтите, безопасность не приходит сама ===
Это самый важный совет. В Linux нет ни ежедневных напоминаний, от которых страдают пользователи других операционных систем, ни финансового бремени от запуска платных антивирусов, брандмауэра и блокировщика всплывающих окон. Но это не значит, что нет угрозы. Если вы не поленитесь заглянуть в свои файлы журналов, то увидите, что она определенно есть. И когда система, которую вы считали безопасной, взламывается, последствия могут быть вдесятеро ужаснее, чем просто заражение вирусом. Ваша машина может использоваться для размещения нелегального ПО, организации атак типа «отказ в обслуживании», или просто для рассылки тысячи спам-сообщений в час.

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

2008-03-10T12:03:53Z

-=JeN=-: Новая: __TOC__ === Обзоры === * Nokia N800 N770 понравился многим – какое впечатление произведет на нашего обозре...

__TOC__
=== Обзоры ===
* [[LXF91:N800|Nokia N800]]
N770 понравился многим – какое впечатление
произведет на нашего обозревателя его
последователь?
* [[LXF91:DVD940e|HP DVD940e]]
HP выпустила библиотеку для поддержки
технологии LightScribe – мы оценили
результаты
* [[LXF91:K3b 1.0|K3b 1.0]]
Утилита записи дисков из KDE доросла до
версии 1.0 – насколько номер соотвествует ее
зрелости?
* [[LXF91:Greenphone|Greenphone]]
Открытый сотовый телефон или игрушка для
разработчиков? Мнение Linux Format.
* [[LXF91:Metisse|Metisse]]
Узнайте, чем решение Mandriva отличается от
Xgl и AIGLX.
* [[LXF91:Sabayon Linux 3.2|Sabayon Linux 3.2]]
Linux на десерт – что получится, если смешать
все вкусные новинки в одном дистрибутиве?

 
[[LXF91:15 мгновений безопасности|15 мгновений безопасности]]
Держите систему на замке
 
[[LXF91:Дневники демонов|Дневники демонов]]
Ведение журналов: syslog и окрестности
 
[[LXF91:Neo1973|Neo1973 – новая мобильная революция]]
Узнайте, как OpenMoko и FIC изменят вашу мобильную жизнь к лучшему
 
[[LXF91:Путь к просвещению|Путь к просвещению]]
Под знаменами E17 на PS3
 

=== Сравнение ===
* [[LXF91:Системы управления версиями|Системы управления версиями]]
Git или Bazaar, CVS или Subversion: что лучше для вашего проекта? Выясняет Грэм Моррисон.

=== Спецрепортаж ===
* [[LXF91:Второе пришествие GIMP|Второе пришествие GIMP]]
Что нам готовит фаворит открытой графики?

=== Постоянные рубрики ===
* [[LXF91:Новости|Новости]]
* [[LXF91:DistroWatch|DistroWatch]]
Дополнительная информация о трехмерном рабочем столе Mandriva
плюс SimplyMepis и FreeBSD.
* [[LXF91:Интервью LXF|Интервью LXF]]
Что изменилось бы в Sendmail, если бы Эрик Оллмен начал с нуля?
* [[LXF91:Что за штука|Что за штука]]
W3C норовит пройтись метлой по пыльным уголкам Web:
что нам готовит XHML?
* [[LXF91:Ответы|Ответы]]
В этом месяце: символьные ссылки, слайд-шоу, Evolution
и другие проблемы пользователей
* [[LXF91:Через месяц|Через месяц]]
Что ждет нас в мае

=== Учебники ===
'''Система'''
* [[LXF91:Следите за пользователями!|Следите за пользователями!]]
Стойкие пароли и права доступа к файлам
для начинающих. 
'''XSLT'''
* [[LXF91:Создаем таблицу стилей|Создаем таблицу стилей]]
Программирование на языке таблиц стилей
XML: ваша RSS-лента будет выглядеть намного
лучше. 
'''SugarCRM'''
* [[LXF91:Как ее настроить|Как ее настроить]]
Мы установили великолепную открытую
CRM-систему: пришла пора приспособить ее
к нуждам вашей организации. 
'''Mono'''
* [[LXF91:Программируйте с GTK|Программируйте с GTK]]
Набросайте интерфейс для своего RSS-
агрегатора и заставьте его работать! 
'''Deb'''
* [[LXF91:Соберите собственный пакет|Соберите собственный пакет]]
«Создание и распространение пакета – это
способ выразить благодарность сообществу».
Узнайте больше! 
'''GTK'''
* [[LXF91:Новый Glade|Новый Glade]]
Сделайте это на C! Новый Glade позволяет
писать удивительно изящные приложения. 
'''Unix API'''
* [[LXF91:Окна ncurses|Окна ncurses]]
Создаем удобный интерфейс для утилит
командной строки. 
'''Java EE'''
* [[LXF91:Сессии и фильтры|Сессии и фильтры]]
Разграничиваем доступ к web-приложению
и фильтруем нежелательных посетителей. 
'''PostgreSQL'''
* [[LXF91:Дополнительные главы|Дополнительные главы]]
Резервное копирование, репликация,
автовакуум – что еще умеет PostgreSQL? 
'''LaTeX'''
* [[LXF91:Создаем презентацию|Создаем презентацию]]
Чтобы впечатлить аудиторию, не нужно
открывать Impress. Сделайте презентацию
в LaTeX – и вас не забудут! 
'''Blender'''
* [[LXF91:Скелетная анимация|Скелетная анимация]]
Орлята учатся летать – пингвины
учатся ходить.