Презентация 8-01: основные роли при работе с ПО

Создание и использование любого программного обеспечения предполагает существование следующих ролей:

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

В сложившейся современной модели распространения свободного ПО выделилась ещё одна группа ролей — разработчики дистрибутивов, которые берут на себя функции интеграторов, объединяющих различные независимые компоненты в целостные и готовые к использованию «решения». Наибольшее значение роль разработчиков дистрибутивов получила в операционной системе Linux.

Основные роли и взаимосвязи участников в процессе создания, установки и использования программы показаны на рисунке Рисунок 3.14, «Основные роли в процессе создания и использования ПО». В этой упрощённой схеме опущены такие участники процесса, как служба поддержки или дистрибьюторы, важные в первую очередь для коммерческих систем, тогда как отношения, специфичные для открытых разработок, помечены пунктиром.

Рисунок 3.14. Основные роли в процессе создания и использования ПО

Если вопрос использования и конфигурирования программного обеспечения сильно зависит от конкретной программы (как правило, доступна документация для пользователей системы), то общие задачи администрирования (установка программы, её обновление, удаление) — наоборот, стремятся к унификации для облегчения работы системного администратора.

Вспомним хотя бы стандартную иерархию каталогов UNIX. Исполняемые файлы программ обычно располагаются в одних каталогах, библиотеки — в других, файлы с данными — в третьих. Это удобно при использовании и конфигурировании, но в процессе установки или удаления программы практически очень сложно производить это вручную. Т. е. необходимы специальные автоматизирующие средства, позволяющие администратору легко (желательно полуавтоматически) производить установки, обновление и удаление программ.

Другой важной функцией систем управления программым обеспечением является организация связи между разработчиками программы (или дистрибутива) и администратором — уведомление о выходе новых версий программ или критических обновлений, загрузка программ через Интернет, средства обратной связи.

Презентация 8-02: распространение ПО в двоичной форме и в исходных текстах

Самым простым способом распространения программы является простой файловый архив, который содержит исполняемый файл, набор библиотек и других файлов, необходимых для запуска программы. Но распространение программ в двоичном виде связано с рядом проблем: исполняемые файлы различаются для разных архитектур и операционных систем (UNIX-подобные операционные системы имеют общие стандартные интерфейсы, а не реализации). В результате двоичная программа «для UNIX» обычно оказывается реально применимой на очень узком круге платформ. Применимость такой программы также стремительно падает с течением времени: быстро устаревают аппаратные архитектуры, меняются реализации системообразующих компонентов, меняются даже стандарты.

Рисунок 3.15. Распространение ПО в двоичной форме

В настоящий момент распространение программ в бинарном виде характерно только для проприетарных версий UNIX: AIX, HP-UX, MacOS X, Solaris и др. Эти версии UNIX чаще всего поставляются для небольшого регламентированного списка аппаратных платформ.

Поскольку ОС UNIX изначально создавалась как переносимая система, не привязанная к конкретной аппаратной платформе, в UNIX-сообществе было принято распространять программы в виде исходных текстов, с тем чтобы каждый пользователь имел возможность самостоятельно скомпилировать программу для своей архитектуры, в случае необходимости даже внеся изменения в исходный текст. Таким образом с разработчика программы фактически снимается забота о существующем в мире многообразии аппаратных архитектур и реализаций UNIX.

Очевидно, что преимущества по переносимости программы в этом случае компенсируются увеличением затрат на стороне пользователей: от них требуется владение средствами разработки (компиляторы и т. п.), машинные ресурсы на компиляцию (для больших программ они весьма значительны даже по современным меркам), а при необходимости «приспосабливать» программу к своему окружению — ещё и высокий уровень компетенции в разработке ПО и операционных системах.

В тот период, когда UNIX-сообщество было в первую очередь сообществом разработчиков, предполагалось, что средства разработки установлены в любой UNIX-системе, где может быть востребована программа, распространяемая разработчиками в виде исходных текстов. Поэтому вплоне естественно сложилось, что средства, используемые для компиляции и сборки программ (например, утилита make), были приспособлены и для решения задач из области уже системного администрирования: установки и удаления полученных программ.

Рисунок 3.16. Распространение ПО в форме исходных текстов

Make-файл определённого вида к настоящему времени является стандартом де-факто для большинства открытых проектов. С его помощью можно получить готовую к использованию программу из исходных текстов на компилируемом языке (как правило это C или C++). Обычно в make-файле определяются специальные цели для задач системного администрирования: install и uninstall, которые выполняют стандартные действия — соответственно установку и удаление скомпилированной программы из системы. При этом всё, что требуется от администратора для компиляции из исходных текстов и установки программы, это выполнить следующую последовательность команд:

desktop src # tar -xzf a-program-1.00.tar.gz
desktop src # cd a-program-1.00
desktop a-program-1.00 # make
... происходит компиляция и сборка программы ...
desktop a-program-1.00 # make install
... программа устанавливается в систему ...

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

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

Дополнительный источник осложнений представляют собой зависимости программ. Так, крупные современные проекты могут использовать десятки других программ и библиотек, например, веб-сервер apache зависит от десятка других проектов, начиная от базовой системной библиотеки libc и заканчивая библиотекой expat для синтаксического анализа XML. Так как большинство проектов развивается независимо друг от друга и выпускает новые версии довольно часто, отслеживание зависимостей и корректное обновление программ могут превратиться в сущий ад для администратора.

Дальнейшее упрощение задач администратора в отношении отслеживания зависимостей и различий в реализации разных UNIX-систем в рамках той же модели — посредством сборочных процедур — предоставляют программы пакета autotools: automake и autoconf. Эти средства по существу реализуют адаптивные сборочные процедуры, которые способны настраиваться в зависимости от особенностей сборочной среды. Они позволяют на основе анализа присутствующих в системе программ и библиотек, особенностей операционной системы и аппаратной архитектуры автоматически получить make-файл, по которому будет произведена компиляция и установка программы.

Презентация 8-03: виды дистрибутивов

С выходом свободных UNIX-систем за пределы профессионального сообщества разработчиков, появлением и развитием дистрибутивов, между разработчиками программ и их пользователями возникла ещё одна ступень — разработчики дистрибутивов. Постепенно именно они стали выполнять большую часть требующей высокой квалификации работы по сборке программ из исходных текстов и адаптации их к конкретной системе. Одновременно они стали заниматься унификацией всего программного обеспечения, составляющего дистрибутив.

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

Пакет — специальный файловый архив, который содержит программу или набор программ или указание на способ получения программы (например, адрес в Интернете) вместе с формализованной информацией, необходимой для интеграции данной программы в систему. Разница между пакетом и программой аналогична разнице между службой и демоном (см. «Системные службы») — администратор работает с пакетом в терминах его функциональности.

Введение понятия пакет, помимо прочего, позволяет формализовать понятие зависимости: указывая в метаинформации пакета имена и версии других пакетов, от которых зависит данный. Таким образом, при установке пакета можно автоматически отслеживать наличие в системе всех необходимых для него комопонентов (других пакетов нужных версий), о чём ещё будет сказано далее (см. раздел «Задачи менеджера пакетов»).

Изначально идея систематизации сборки программ, составляющих UNIX-систему, из исходных текстов развилась в BSD-системах (см. также «Системы, наследующие BSD»). В них (изначально во FreeBSD) было введено понятие порта — пакета специального вида, который сам не содержит исходных текстов, а только адрес их местонахождения (как правило, сайт разработчика), но содержит главную «точку приложения» знаний: дополнительные изменения, внесённые разработчиками дистрибутива, и формализованные инструкции по сборке.

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

Пример развития данной схемы до логического предела демонстрирует проект Linux From Scratch, — дистрибутив, который по существу не содержит вообще никаких текстов программ, а представляет собой обстоятельнейшую инструкцию для администратора, как самостоятельно скомпилировать все компоненты системы, начиная с средств разработки и ядра.

Среди широко используемых дистрибутивов GNU/Linux на сборке из исходных текстов основан Gentoo. Собственная, усовершенствованная версия портов, названная портежи (portages), позволяет сконфигурировать систему под конкретную задачу и даже специфическую архитектуру.

Рисунок 3.17. Распространение ПО в форме портов/портежей

Однако при таком распределении задач (компиляция на стороне администратора системы) сохраняется длительность процесса установки и зависимость от используемых средств разработки — даже на сервере приходится устанавливать компилятор gcc.

Презентация 8-04: из чего состоит пакет

Другим путём пошли разработчики многих дистрибутивов, основанных на распространении двоичных пакетов. Первые примеры использования двоичных пакетов в дистрибутивах Linux относятся к ранним версиям дистрибутивов Debian, RedHat и Slackware. Основное отличие подхода заключается в том, что системному администратору компоненты системы предлагаются не в виде пакетов с исходными текстами, а в виде пакетов, содержащих двоичные, скомпилированные версии программ. Таким образом с администратора системы снимается необходимость иметь средства разработки (сборочную среду) и тратить время на сборку программ. Более того, поскольку пакет содержит также и процедуры установки/удаления программы, основные задачи управления ПО становятся вполне доступными и пользователю, не имеющему специальной подготовки.

Описанные выше (см. раздел «Формы распространения программного обеспечения») проблемы, связанные с распространением двоичных программ, в логике таких дистрибутивов решены так: разработчики предоставляют дистрибутив, представляющий собой полноценную систему для решения определённого класса задач и поддерживающий определённый круг оборудования. Пользователю остаётся только выбрать подходящий дистрибутив и устанавливать и обновлять необходимые ему компоненты — пакеты. Работоспособность пакетов на данной аппаратной платформе, их интеграцию в системе, отслеживание зависимостей обеспечивают разработчики дистрибутива. Точнее, в рамках дистрибутива у каждого пакета традиционно имеется сопровождающий (package maintainer) или группа сопровождающих. Это ограничивает пользователя теми программами, что представлены в дистрибутиве. Установка любого ПО из других источников влечёт все описанные выше проблемы и требования для системного администратора или пользователя.

Рисунок 3.18. Распространение ПО в форме двоичных пакетов

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

На начальном этапе развития пакетных систем существовало обязательное и достаточно строгое понятие релиза системы — набора пакетов, соответствующего определённой версии дистрибутивов. Такой набор пакетов распространяется на компакт-дисках и, возможно, публикуется в Internet. Таким образом, обновление пакетов практически проходило поэтапно — вместе с обновлением версии дистрибутива. Этот подход до сих пор активно практикуется в коммерческих дистрибутивах.

С развитием Internet пакетные системы стали выносить на публику репозитарии пакетов — хранилище пакетов системы, содержащее «текущее состояние» системы, множетство всех пакетов и зависимостей между ними. Репозитарии удобны тем, что они находятся в «живом» состоянии — пакеты постоянно обновляются разработчиками дистрибутива и могут быть легко загружены и установлены пользователем. Как правило, для автоматизации и удобства работы с репозитарием (а именно, установки пакетов с удовлетворением всех зависимостей) используется специальная программа (например, APT). Имея постоянный доступ в Internet, можно развернуть всю систему из небольшого начального набора пакетов, включающего базовую систему и программу по работе с репозитарием.

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

Существует несколько широко распространённых форматов пакетов, обычно связанных с различными дистрибутивами. Но в каждом из форматов будут присутствовать следующие логические составляющие (см. Рисунок 3.19, «Основные составляющие пакета»).

Рисунок 3.19. Основные составляющие пакета

Самые распространённые на данный момент дистрибутивы Linux — Debian и RedHat — являются типичным примерами систем с двоичными пакетами (rpm для RedHat и deb для Debian). Эти два формата пакетов используются также и в других дистрибутивах — Mandriva, ALT Linux, Ubuntu и т. д.

Презентация 8-05: зависимость и конфликт

Администратору системы приходится выполнять следующие операции при работе с пакетами:

При этом необходимо автоматизировать работу с зависимостями и конфликтами, так как число пакетов и связей между ними в современных системах очень велико (тысячи и более).

Как уже было сказано выше, пакеты в системе выстраиваются в сеть зависимостей и блокировок. Например, веб-сервер apache может зависеть от множества пакетов, т.е. администратору придётся установить все из них перед установкой самого пакета apache.На рисунке Рисунок 3.20, «Пример зависимостей пакетов в системе» показан пример реальных зависимостей пакетов в одном из дистрибутивов GNU/Linux. Аналогичная ситуация возникает и при удалении пакета: удаление одной из зависимостей вообще говоря некорректно и может привести к отказу работы программ из основного пакета.

Рисунок 3.20. Пример зависимостей пакетов в системе

Зависимость между пакетами системы может основываться на:

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

Презентация 8-06: менеджер пакетов RPM

Менеджер пакетов RPM (RedHat Package Manager) был создан в рамках дистрибутива RedHat и на данный момент является наиболее распространённым средством оргнанизации пакетов в операционной системе GNU/Linux. Менеджер пакетов состоит из следующих компонентов:

Таким образом, при работе с RPM наи

Презентация 8-07: название RPM-пакета

Обычно файлы RPM-пакетов имеют специальным образом построенные имена:

имя_пакета-версия_программы-версия_пакета.архитектура.rpm

Презентация 8-08: Основные операции RPM

Презентация 8-09: работа с репозиторием

Среди дистрибутивов GNU/Linux стало распространённым явлением размещение пакетов в Интернет, в так называемом репозитории пакетов. Администратор может загрузить оттуда самую последнюю версию пакета и установить его в системе. Для облегчения работы с репозитарием существуют специальные программы, такие как APT в Debian или yum в RedHat.

Однако менеджеры пакетов оказались неспособны предотвратить все возможные коллизии при установке или удалении программ, а тем более эффективно устранить нарушения целостности системы. Особенно сильно этот недостаток сказывается при обновлении систем из централизованного репозитория пакетов, в котором последние могут непрерывно обновляться, дробиться на более мелкие и т. п. Этот недостаток и стимулировал создание систем управления программными пакетами и поддержания целостности системы.

Для автоматизации этого процесса и применяется Усовершенствованная система управления программными пакетами APT (от англ. Advanced Packaging Tool). Такая автоматизация достигается созданием одного или нескольких внешних репозиториев, в которых хранятся пакеты программ и относительно которых производится сверка пакетов, установленных в системе. Репозитории могут содержать как официальную версию дистрибутива, обновляемую его разработчиками по мере выхода новых версий программ, так и локальные наработки, например, пакеты, разработанные внутри компании.

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

Первоначально APT был разработан для управления установкой и удалением программ в дистрибутиве Debian GNU/Linux. При разработке ставилась задача заменить используемую в Debian систему выбора программных пакетов dselect на новую, обладающую большими возможностями и простым пользовательским интерфейсом, а также позволяющую производить установку, обновление и повседневные «хозяйственные» работы с установленными на машине программами без необходимости изучения тонкостей используемого в дистрибутиве менеджера программных пакетов.

Эти привлекательные возможности долгое время были доступны только пользователям Debian, поскольку в APT поддерживался только один менеджер пакетов, а именно применяемый в Debian менеджер пакетов dpkg. APT, однако, изначально проектировался как не зависящий от конкретного метода работы с установленными в системе пакетами, и эта особенность позволила разработчикам из бразильской компании Conectiva реализовать в нём поддержку менеджера пакетов RPM. Таким образом, пользователи основанных на RPM дистрибутивов получили возможность использовать этот мощный инструмент.

Система APT состоит из нескольких утилит. Чаще всего используется утилита управления пакетами apt-get: она автоматически определяет зависимости между пакетами и строго следит за их соблюдением при выполнении любой из следующих операций: установка, удаление или обновление пакетов.

rpm [подпись] метод:путь база название
rpm-src [подпись] метод:путь база название