Программное обеспечение стремительно совершенствуется. Ежегодно выходят новые версии ОС, ежемесячно появляются новые продукты и ежедневно добавляются исправления к ним. Поэтому администраторам систем нужно следить за этим круговоротом ПО, чтобы не пропустить новую важную функцию и исправить ошибки в старой версии программы. Кажется даже, что быть в курсе всех изменений невозможно, но это не так. И здесь на помощь при установке новых приложений и версий придут системы сетевого обновления, все шире распространяющиеся в мире ПО с открытыми кодами.
Сейчас практически все производители дистрибутивов Linux имеют в том или ином виде систему сетевого обновления. Такая популярность этих систем, возможно, связана с тем, что пользователи хотят оперативно получать исправления к уже установленному ПО и расширять функциональные возможности уже работающего. Впрочем, зачастую подобные программы применяют даже для групповой разработки и отладки программного обеспечения. Так или иначе, но интерес к системам обновления возрастает, и уже возникли компании, основывающие свой бизнес на таких системах.
Правила обновления
Все системы обновлений построены по одному принципу: есть сервер, подключенный к Интернету и содержащий репозитарий* пакетов, и есть клиент, в определенное время обращающийся к серверу и спрашивающий: «Что новенького?»
Различаются отдельные виды cистем обновления лишь деталями. Вот их мы рассмотрим поподробнее. Обновление уже работающих систем требует соблюдения достаточно жестких требований, что заставляет разработчиков дистрибутивов перестроить свою работу, а на это идут далеко не все. Поэтому большинство таких продуктов появляются как результат компромисса между соблюдением предъявляемых к ним требований и возможностями их разработчиков.
|
| Схема системы сетевого обновления |
Системы сетевого обновления состоят из репозитария пакетов и связанного с ним клиентского приложения. Причем желательно, чтобы поддерживались различные способы доставки пакетов, проверялись зависимости приложений между собой, гарантировалась целостность системы и неизменность файлов при передаче их по сети. Все репозитарии строятся на основе пакетов, представляющих собой набор файлов приложения и его конфигурации, сценарии установки и удаления, а также минимальную документацию, и все это должно быть упаковано в один файл. Различаются также пакеты, содержащие исполняемые программы, набор файлов-заголовков для разработки, исходные тексты программ и подробную документацию. Фактически есть два формата пакетов, на основе которых строятся репозитарии: Debian с расширением deb и RedHat Packet Manager с программой установки RPM. Однако хорошая система обновлений не только управляет пакетами, но и обеспечивает контроль целостности всей ОС и работающего в ней ПО. Таким образом, репозитарий должен выполнять следующие функции:
- автоматическое управление пакетами, включая проверку электронных подписей разработчиков;
- корректную установку взаимосвязей между пакетами, в том числе устранение конфликтов между файлами;
- проверку исполнимости приложений пакета;
- проверку компилируемости исходных текстов пакетов.
Одновременно на клиентское приложение возлагаются такие обязанности:
- проверка целостности пакета и корректности электронной подписи разработчика;
- проверка взаимосвязей и дозагрузка модулей, необходимых для непротиворечивого обновления;
- корректное обновление файлов пакета с разрешением конфликтных ситуаций;
- проверка целостности установленных файлов.
Все функции системы сетевого обновления должны обеспечивать сохранение целостности ОС и приложений при их модернизации. Это правило достаточно жесткое, и его несоблюдение чревато возможностью сбоев обновляемого компьютера, установкой неработоспособного приложения или потерей пользовательских данных.
Репозитарии, содержащие большое количество пакетов, должны отвечать требованию согласованности, т. е. во всех пакетах необходимо правильно устанавливать необходимые зависимости и, если возможно, устранять лишние связи. В спецификации RPM, на основе которого построено большинство репозитариев, есть возможность указать зависимости, однако устанавливает их разработчик, а он может и ошибиться. В результате либо пакет не установится, либо не произойдет обновления нужных пакету библиотек. Поэтому в системах с множеством пакетов важна не только возможность определения всех зависимостей, но и автоматическая проверка согласованности этих зависимостей во всех пакетах репозитария с учетом текущих версий. В противном случае вообще рискованно заниматься обновлениями, поскольку после очередной модернизации система иногда просто перестает работать. Следовательно, разработчики репозитариев должны создать сценарии для анализа и корректной установки всех зависимостей.
Еще более интеллектуальные репозитарии способны вычислять пакеты, требующиеся для самостоятельной сборки приложения, например, такой, которую рекомендуется выполнять в локальной среде chroot environment. Соблюдение предложенных зависимостей гарантирует, что в системе установлены все компоненты, обеспечивающие самостоятельную сборку приложения из ее исходных текстов.
Дистрибутивы и репозитарии
Стиль Debian
Дистрибутив Debian снабжен одной из старейших систем сетевого обновления. По сути, весь проект Debian основан на соответствующем репозитарии, поскольку сценарии управления пакетами построены так, что они же являются инструментом отладки приложений на различных платформах. Дистрибутив Debian распространяется для десяти различных процессорных архитектур. Причем самому разработчику достаточно одной, а компилирование под остальные выполняется автоматически, и его результаты сообщаются автору пакета.
В качестве клиентского приложения у Debian используется apt-get, контролирующий репозитарий и дозагружающий необходимые файлы. Это текстовая утилита, и ее можно применять для автоматического обновления. Пользователь также может участвовать в процессе разработки приложений, посылая на сервер сообщения об ошибке с указанием ее уровня. Такие сообщения приходят в систему обработки ошибок (Bug Tracking System — BTS), фактически руководящую выпуском стабильного репозитария — дистрибутива. Ни один пакет не может попасть в стабильную часть репозитария, пока в нем не будут решены проблемы, отмеченные как release critical. Таким образом, система обновлений одновременно исполняет роль и средства отладки, и технической поддержки.
Российская компания ALT Linux придерживается аналогичного стиля при разработке и распространении ПО. Она выпускает дистрибутив только для платформы x86, однако активно использует сценарии для управления пакетами, а также имеет свою BTS. Эта фирма в качестве базового репозитария для разработки создала Sisyphus, но стабильных дистрибутивов несколько: наиболее полный — Master, для начинающих — Junior, для защищенных серверных систем — Castle. Все они выделены в отдельные стабильные репозитарии, где пакеты обновляются лишь для устранения серьезных ошибок, влияющих на защищенность или надежность пользовательской системы. ALT Linux использует формат пакетов rpm, а в качестве клиентской программы — apt-get, адаптированный к rpm-пакетам бразильской компанией Conectiva.
Еще один дистрибутив, снабженный репозитарием, — Mandrake. Уже в его седьмой версии появилась система установки и обновления, именуемая urpmi. В частности, в дистрибутиве Master 2.0 компании ALT Linux она поставляется как дополнительная к apt-get, что обеспечивает пользователю свободу выбора. Сам Mandrake возник в тот момент, когда Red Hat отказался распространять в своем составе KDE. Изначально новый дистрибутив позиционировался как Red Hat с KDE, но тем не менее испытал большое влияние Debian. Даже появились заявления, что очередная версия будет построена на Debian, но этого не случилось.
Система urpmi в основном служит средством управления rpm-пакетами из дистрибутива, а также способна получать обновленные пакеты из серверного репозитария. Однако программа urpmi имеет определенные функциональные недостатки, в частности, она иногда ставит два конфликтующих пакета, что нередко приводит к выходу системы из строя. Дистрибутив Mandrake пытался использовать apt-get, однако разработчикам не удалось выдержать достаточно жесткие требования по зависимостям. В urpmi предусмотрено несколько обходных маневров, однако apt-get более надежно контролирует целостность системы, чем urpmi.
Стиль SuSE
Собственную систему обновления пакетов под названием YaST Online Update (YOU)разработала и SuSE. Собственно, YaST в основном предназначена для установки Linux на компьютер, но она имеет и утилиту обновления пакетов по сети. Это одна из первых систем сетевого обновления, характеризующаяся тем, что работает медленно, поскольку после установки пакета запускается ресурсоемкий сценарий, производительность которого зависит от числа установленных пакетов. Эта программа свободно не распространяется, хотя ее исходные тексты и доступны. Так что у SuSE нет клонов из-за невозможности коммерческого использования YaST.
Впрочем, SuSE имеет только стабильный репозитарий, полностью соответствующий дистрибутиву, обновляющемуся примерно трижды в год. Причем в Интернете новые версии пакетов выкладываются лишь через месяц после их выхода в виде дистрибутива на дисках. Энтузиасты сделали для SuSE систему распространения обновлений через Интернет, применяющую другую адаптированную для RPM версию apt-get под именем apt4rpm. Эта программа работает с пакетами, не собранными специально с учетом требований apt-get, в частности пакетами SuSE. Поэтому при эксплуатации подобной системы могут возникнуть определенные недоразумения, если в данных пакетах некорректно указаны зависимости. А поскольку владельцы репозитария распространяют те пакеты, которые сами не собирают, то автоматической проверки зависимостей на стороне репозитария у них, скорее всего, и не предусмотрено.
Стиль Red Hat
Наиболее популярным дистрибутивом Linux стал Red Hat, долго не имевший своей системы сетевого обновления. Правда, сейчас она уже появилась в виде дополнительной платной услуги. Однако репозитарий Red Hat, к сожалению, содержит не очень много пакетов. Компания, видимо, рассчитывает, что все производители ПО и так будут собирать их. Собственно говоря, это и происходит, но поскольку дополнительные пакеты не являются сборкой самой Red Hat, то компания не несет за них никакой ответственности.
Система сетевого обновления Red Hat — платная служба, поэтому большинство клонов Red Hat не имеют системы обновлений. Впрочем, в версии 7.3 российского дистрибутива ASPLinux, производители которого стремятся к совместимости с Rad Hat, появилась собственная система обновлений, называемая yum. Этот дистрибутив совместим с Red Hat, так что проверок на конфликты в нем не проводится. Например, в ASPLinux 7.3 пакеты emacs и xemacs не могут быть установлены одновременно, поскольку имеют конфликтующий файл. Кроме того, данная программа достаточно нова, она разрабатывалась для других целей и пока не имеет графических средств управления. Тем не менее появление бесплатной системы сетевого обновления у дистрибутива, совместимого с Red Hat, делает его способным к конкуренции даже с оригиналом.
Системы обновления для приложений
Впрочем, системы обновления есть не только для дистрибутива, но и для отдельных приложений. Одна из самых популярных систем обновления для массовых пользователей — это Ximian, разработанная одноименной компанией. У нее свой репозитарий пакетов, содержащий отдельные приложения для различных дистрибутивов. В Ximian работают некоторые разработчики GNOME, графической среды для Linux. Данная среда, адаптированная для разных дистрибутивов, и есть основной продукт компании. Сам проект Ximian сейчас включает большой набор настольных приложений, в том числе и офисных, в частности программу обновлений, позволяющую модифицировать все поставляемые Ximian приложения. Кстати, можно купить приоритетное обслуживание для обновлений. Кроме того, Ximian начала продавать коммерческие дополнения к своим свободно распространяемым приложениям. Пользователи Red Hat очень часто прибегают к услугам Ximian, поскольку получают возможность сетевого обновления своих приложений.
Способы распространения обновлений
Система обновления должна поддерживать различные способы доставки пакетов: через Интернет, по локальной сети или же на носителях любых типов: CD-ROM, DVD или zip. Тогда пользователи могут получить максимальную свободу в обновлении ПО и оптимизировать свои расходы на поддержку системы. Важно также, что можно создать свой собственный репозитарий, в который администратор системы будет включать только те пакеты, что нужны его компании, а затем с помощью системы обновления устанавливать их на все ПК в своем офисе.
Практически все общедоступные репозитарии можно свободно распространять, а вот коммерческие имеют определенные ограничения. В частности, дистрибутив ALT Linux Master кроме собственно программы обновления содержит набор сценариев для подготовки сетевого репозитария или дистрибутива на CD-ROM. С помощью этих сценариев компания может создавать свои собственные дистрибутивы, содержащие лишь то, что ей требуется.
Некоторые системы обновления позволяют делать локальные репозитарии. Требований к ним меньше, поскольку не нужно проверять согласованность пакетов, а достаточно обеспечить их наличие в локальном репозитарии. Обновления такого репозитария можно выполнять ежедневно в часы минимальной загрузки корпоративного канала связи с Интернетом. Локальные репозитарии могут пригодиться еще и в том случае, когда нужно проверить работоспособность новой версии программы перед ее клонированием на все остальные машины. Такая буферная проверка рекомендуется при выполнении обновлений с нестабильного репозитария, например с Sisyphus.
Применение
Прежде чем выбирать систему сетевого обновления, стоит сначала ответить на вопрос: нужна ли она вообще? Так, если набор задач, решаемых компьютером, ограничен, то обновление может не потребоваться, поскольку надежнее будет пересобрать (откомпилировать) пакеты самому. В больших системах, где используется много различных приложений, выгоднее доверить их компиляцию сторонней компании и заниматься только обновлением уже готовых к работе пакетов. Кроме того, система обновления, как правило, поддерживает целостность операционной среды, обеспечивая совместную работу ее компонентов. Без системы обновлений пользователям приходится следить за всеми зависимостями самостоятельно, а в большой системе — это непростая задача.
В общем, если компания использует Linux на не нуждающемся в усиленном обслуживании сервере с ограниченным набором достаточно простых функций, то частого обновления и не потребуется. А если Linux применяют в динамически развивающейся сложной вычислительной системе, то стоит подумать об обновлении хотя бы определенной части построенного решения.
* * *
Напоследок хочется привести пример удачного применения системы обновления для оперативного «латания дыр» в системе защиты. Одно время появлялись сообщения об ошибках, найденных в такой популярной библиотеке, как zlib. Она реализует широко известный алгоритм сжатия информации zip. Причем библиотека настолько компактна, что разработчики предпочитают интегрировать ее в свои продукты целиком. Найденная в реализации алгоритма ошибка могла бы нарушить работу приложения, поэтому разработчики программ с открытыми исходными текстами спешно вывели эту библиотеку из состава приложений в динамически присоединяемые модули. Как только ошибка была официально признана и появились рекомендации по ее исправлению, библиотека zlib была модифицирована. В результате ошибки были изъяты сразу же из всех приложений, использующих zlib.
ОБ АВТОРЕ
Валерий Коржов — обозреватель еженедельника «ComputerWorld Россия», e-mail:oskar@osp.ru.
* Структурированное хранилище пакетов.