Операционная система состоит не только из ядра и библиотек, но и из множества сторонних программ. Создатели операционной системы, разработчики программ и системные администраторы должны иметь простые и удобные для всех средства управления этим набором программного обеспечения. Разные версии операционной системы UNIX имеют собственные средства управления программным обсепеченнием, во многом принципиально схожие.
Презентация 8-01: этапы работы с программой
Обычно создание и использование программного обеспечения требует следующих участников:
- разработчик;
- системный администратор;
- пользователь.
Если речь идёт о свободных и открытых программах, то эти три группы людей очень часто трудно разделимы и составляют так называемое сообщество (community) вокруг проекта. При этом появляется еще одна важная сторона — разработчики дистрибутивов, наиболее ярко представленные в операционной системе Linux.
Обычный процесс создания, установки и использования программы показан на рисунке Рисунок 3.15, «Этапы создания и использования ПО». В этой упрощённой схеме опущены такие участники процесса, как служба поддержки или дистрибьюторы, важные в первую очередь для коммерческих систем, тогда как отношения, специфичные для откртытых разработок помечены пунктиром.
Если вопрос использования и конфигурирования программного обеспечения сильно зависит от конкретной программы (как правило, доступна документация для пользователей системы), то общее администрирование (установка программы, обновление, её удаление) — наоборот, стремится к унификации для облегчения работы системного администратора.
Вспомним хотя бы стандартную иерархию каталогов UNIX. Исполняемые файлы программ обычно располагаются в одних каталогах, библиотеки — в других, файлы с данными — в третьих. Это удобно при использовании и конфигурировании, но в процессе установки или удаления программы практически очень сложно производить это вручную. Т.е. необходимы специальные автоматизирующие средства, позволяющие администратору легко (желательно полу-автоматически) производить установки, обновление и удаление программ.
Другой важной функцией систем управления программым обсепечением является организация связи между разработчиками программы (или дистрибутива) и администратором — уведомление о выходе новых версий программ или критических обновлений, загрузка программ через Интернет, средства обратной связи.
Презентация 8-02: способы установки программ
Самым простым способом распространения программы является простой файловый архив, который содержит исполняемый файл, набор библиотек и других файлов, необходимых для запуска программы. Но распространение программ в бинарном виде связано с рядом проблем: исполняемые файлы отличаются для разных архитектур и операционных систем (UNIX-подобные операционные системы имеют общие стандартные интерфейсы, а не реализации). Поэтому в открытых проектах принято распространять программы в виде исходных текстов.
Изначально развитие систем установки программ в UNIX-подобных системах шло со стороны разработчиков. Средства, используемые ими для компиляции и сборки программ (например, утилита make), широко использовались и для их установки и удаления.
Make-файл определённого вида является стандартом де-факто для большинства открытых проектов. С его помощью можно получить готовую к использованию программу из исходных текстов на компилируемом языке (как правило это C или C++). Обычно в make-файле определяются специальные цели: clean, install, uninstall и т.д., которые выполняют стандартные действия — соответственно очистку дерева исходных текстов от прмежудочных объектных файлов, установку и удаление собранной программы из системы и т.п.. При этом всё, что требуется от администратора при установке, это выполнить следующую последовательность команд:
Пример 3.5. Сборка и уставка программы с помощью make
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-подобных операционных
систем помогли программы automake и
autoconf, с помощью которых можно на основе анализа
установленных в системе программ и библиотек, особенностей операционной системы
и аппаратной архитектуры получить make-файл, по которому будет произведена
компиляция и установка программы. Сейчас любая программа, доступная в исходных
текстах содержит файл configure, запуск которой с
необходимыми параметрами позволяет администратору получить make-файлы для сборки
программы в данной системе с указанными опциями.
Со временем большую часть работы по сборке программ из исходных текстов и предоставлению их администратору стали выполнять разработчики дистрибутивов, одновременно унифицируя все программное обеспечение, установленное в системе. Акцент при этом сместился от программы или набора различных файлов к пакету.
Презентация 8-03: из чего состоит пакет
Пакет — специальный файловый архив, который содержит программу или набор программ вместе с информацией о зависимостях (других пакетах, необходимых для установки данного пакета), инструкции по установке или удалению программы. Разница между пакетом и программой аналогична разнице между службой и демоном (см. «Системные службы») — администратор работает с пакетом в терминах его функциональности.
Существует несколько широко распространённых форматов пакетов, обычно связанных с различными дистрибутивами. Но все они характеризуются следующими параметрами (см. Рисунок 3.16, «Основные составляющие пакета»).
- название
Имя программы (например, apache) или функции, закреплённой за пакетом (например, base-system — файлы и программы, составляющие основу системы).
- версия
Версия программы, присвоенная разработчиками, обычно дополняется версией пакета внутри дистрибутива (например, «pciutils-2.1.11-alt10»).
- зависимости
Список пакетов с версиями, необходимые для установки и работы данного пакета. Как правило, пакеты в системе образуют решетку зависимостей.
- автор(ы)
Имя и контакты автора или коллектива авторов программы, адрес домашней страницы проекта.
- описание
Краткая (или не очень) информация о пакете — соответствующей программе или функции.
- содежимое
Пакеты бывают бинарными или с исходными текстами. В первом случае это скомпилированне исполняемые и прочие файлы программы, во втором — исходые тексты и инструкции по сборке.
Для работы с каждым из форматом пакетов используются специальные программы администрирования. Как правило, в различных дистрибутивах операционных систем приняты собственные системы управления пакетами.
Изначально идея структуризации сборки программ из исходных текстов развилась в BSD-системах (см. также «Системы, наследующие BSD»). В них (изначально во FreeBSD) было введено понятие порта — пакета специального вида, который сам не содержит исходных текстов, а только адрес их местонахождения (как правило, сайт разработчика), дополнительные патчи и инструкции по сборке. Такая схема позволила значитель ускорить процесс создания дистрибутива и добавления в него новых программ.
Среди дистрибутивов GNU/Linux аналогичное решение предлагается в дистрибутиве Gentoo. Собственная, усовершенствованная версия портов, названная портежи (portages), позволяет сконфигурировать систему под конкретную задачу и даже специфическую архитектуру.
При всей простоте решения — полном переносе процесса компиляции программ от создателей дистрибутива к администратору — возникает ряд проблем. Одна из самых существенных — большой объём работы администратора, также немаловажными являются длительность процесса установки и зависимость от используемых средств разработки (по сути, даже на сервере приходится устанавливать компилятор gcc).
Исторически первые и самые распространённые на данный момент дистрибутивы Linux — Debian и RedHat — являются типичным примерами систем с бинарными пакетами. Пакеты распространяются в специальном формате (rpm для RedHat и dep для Debian), имя пакета как правило содержит название программы и версию. Эти же форматы остались у продолжателей идей этих дистрибутивов — Mandriva, ALT Linux, Ubuntu и т.п.. Работа с пакетами ведётся с помощью утилит, входящих в базовые программы дистрибутива.
На начальном этапе развития пакетных систем существовало обязательное и достаточно строгое понятие релиза системы — набора пакетов, соответствующий определённой версии дистрибутивов. Такой набор пакетов распространяется на компакт-дисках и, возможно, публикуется в Internet. Таким образом, обновление пакетов практически проходило поэтапно — вместе с обновлением версии дистрибутива. Этот подход до сих пор активно практикуется в коммерческих дистрибутивах.
С развитием Internet пакетные системы стали выносить на публику репозитарии пакетов — хранилище пакетов системы, содержащее «текущее состояние» системы, множетство всех пакетов, образующих цепочку зависимостей. Репозитарии удобны тем, что они находятся в «живом» состоянии — пакеты постоянно обновляются разработчиками дистрибутива и могут быть легко загружены и установлены пользователем. Как правило, для автоматизации и удобства работы с репозитарием используется специальная программа (например, APT). Имея постоянный доступ в Internet, можно развернуть всю систему из небольшого начального набора пакетов, включающего базовую систему и программу по работе с репозитарием.
Надо отметить, что акцент на бинарные пакеты в таких системах не мешает им также распространять пакеты с исходными версиями программ (например, source rpm).
Очевидно, что в данном случае большая часть работы перекладывается на создателей дистрибутива. Это сказывается, в частности, на том, что добавление новых версий программ в таких системах происходит медленнее, чем в системах, основанных на сборке из исходных текстов.
В рамках этих лекций будет рассматриваться управление пакетами на основе rpm и APT, которое можно применить к ряду дистрибутивов Linux.
Презентация 8-04: зависимость и конфликт
Как уже было сказано выше, пакеты в системе выстраиваются в сеть зависимостей и блокировок. Например, веб-сервер apache может зависеть от множества пакетов, т.е. администратору придётся установить все из них перед установкой самого пакета apache. Аналогичная ситуация возникает и при удалении пакета: удаление одной из зависимостей вообще говоря некорректно и может привести к отказу работы программ из основного пакета.
На рисунке Рисунок 3.17, «Пример зависимости пакетов в системе» показан пример
реальных зависимостей пакетов в одном из дистрибутивов GNU/Linux. Зависимость
между пакетами может основываться на:
- функциональной зависимости, например, программы от библиотеки (например, библиотека «libreadline», предоставляющая функцию гибкого ввода текста в командной строке)
- зависимости от набора данных или конфигураций (так, пакет «terminfo» предоставляет набор конфигураций терминалов);
- зависимости при установке — без данного пакета не удастся развернуть и проинициализировать требуемый пакет;
- виртуальные зависимости — используются для объединения пакетов в группы, удобные для установки и обновления (например, пакет «glibc» зависит от множества пакетов вида «glibc-*», релизующие отдельные компоненты базовой системной библиотеки).
Часто в рамках одной системы доступно для установки несколько версий программы (а, следовательно, и пакета). Как правило, разные версии пакета не могут одновременно присутствовать в системе. Такая ситуация называется конфликтом между пакетами в системе. Другой причиной конфликта может быть аналогичная функциональность пакетов, например в системе может быть установлен только один демон планирования заданий, хотя существует несколько его реализаций, представленных различными пакетами.
Презентация 8-05: менеджер пакетов RPM
Администратору системы приходится выполнять следующие операции при работе с пакетами:
- установка программ;
- обновление программ (например, в связи с выходом её новой версии);
- удаление программ;
- получение информации о пакетах — как установленных, так и не установленных.
При этом необходимо автоматизировать работу с зависимостями и конфликтами, так как число пакетов и связей между ними в современных системах очень велико (тысячи и более).
Менеджер пакетов RPM был создан в рамках дистрибутива RedHat
и на данный момент является наиболее распространённым средством оргнанизации
пакетов в операционной системе GNU/Linux. Менеджер пакетов состоит из следующих
компонентов:
- исполняемого файла rpm, который является консольным интерфейсом к системе управления пакетами;
- базы данных пакетов, расположенной в каталоге
/var/lib/rpm— здесь хранится информация об установленных пакетах, индексы для быстрого поиска и т.п.; - самих пакетов в специальном формате (обычно с расширением
.rpm). Пакет представляет собой архив из: собственно содержимого пакетов (каталогов и файлов с установленными правами) и метаинформации: заголовка, зависимостей, установочных скриптов.
Презентация 8-06: название RPM-пакета
Обычно файлы RPM-пакетов имеют специальным образом построенные имена:
имя_пакета-версия_программы-версия_пакета.архитектура.rpm
- имя пакета
Может соответствовать программе или библиотеке, заключённой в этом пакете, либо же задавать его назначение (например, «setup» или «initscripts»).
- версия программы
Версия программы или библиотеки, которая составляет основу пакета (например, в случае пакета «automake-1.9.2-3», это «1.9.2»).
- версия пакета
Для каждой версии программы может существовать несколько версий пакетов, это связано с тем, что создатели дистрибутива
GNU/Linuxмогут изменять программу, внося свои патчи, или же изменять сам пакет — установочные скрипты, описание и т. п.. Например, пакет «xmms-1.2.10-9» имеет уже девятую версию. В некоторых дистрибутивахGNU/Linuxк версии пакета прибавляют специальную приставку, например: «pciutils-2.1.11-alt10».- архитектура
Программы могут быть скомпилированны под разные аппаратные архитектуры, например «i386» для Intel x86-совместимых процессоров или «ppc» для POWER от IBM. Пакеты, которые не содержат откомпилированных программ или библиотек (например, скрипты или конфигурационные файлы) обычно обозначаются как «noarch».
Презентация 8-07: Основные операции RPM
Рассмотрим основные операции, выполняемые с помощью программы rpm. Любые действия по изменению пакетов в системе требуют прав суперпользователя.
-
Установка пакета:
rpm -i имя_пакета
Менеджер пакетов проверяет зависимости и конфликты для данного пакета, а затем разворачивает его в операционной системе.
-
Обновление пакета:
rpm -U имя_пакета
Менеджер пакетов проверяет возможность обновления установленного в системе пакета данным пакетом, затем разворачивает новые файлы в системе. При этом используется специальных механизм для сохранения старых версий изменённых файлов (например, конфигурационных).
-
Удаление пакета:
rpm -e имя_пакета
Менеджер пакетов удаляет пакет, предварительно проверяя наличие обратных зависимостей от этого пакета.
-
Получение информации о пакетах. Информация обо всех установленных пакетах сохраняется и индексируется в специальной базе данных. С помощью следующих команд можно узнать как информацию об установленных пакетах, так и информацию, извлекаемую из локальных
.rpm-файлов.-
Список установленных пакетов:
rpm -qa
Менеджер пакетов выводит список всех пакетов, установленных в системе. Вот пример вывода такой команды:
Пример 3.6. Получение списка установленных пакетов
user@desktop ~ $ rpm -qa rpm -qa apt-0.5.15lorg2-alt3 nvidia_glx_1.0.7676-1.0.7676-alt17 gnupg-1.4.2.2-alt1 libpcap0.8-0.9.4-alt1 printer-drivers-base-2.1-alt5 ...
-
Поиск пакета по файлу:
rpm -qf имя_файла
Полезной функцией является поиск пакета, который содержит заданный файл.
Пример 3.7. Получение пакета по имени файла
user@desktop ~ $ rpm -qf /var/log/messages syslog-common-1.4.1-alt23
-
Информация о пакете:
rpm -qi имя_пакета
С помощью этой команды можно узнать сведения о пакете: название и версию программы, организацию и человека, собравших этот пакет, время создания пакета, лицензию и т. п.. В пример Пример 3.8, «Получение информации о пакете» показана информация о пакете «bash», установленном в системе.
Пример 3.8. Получение информации о пакете
user@desktop ~ $ rpm -qi bash Name : bash Relocations: (not relocateable) Version : 3.1.17 Vendor: ALT Linux Team Release : alt1 Build Date: Птн 14 Апр 2006 00:38:44 Install date: Птн 12 Май 2006 03:24:15 Build Host: ldv.hasher.altlinux.org Group : Интерпретаторы команд Source RPM: bash-3.1.17-alt1.src.rpm Size : 1019953 License: GPL Packager : Dmitry V. Levin <ldv@altlinux.org> URL : http://www.gnu.org/software/bash/ Summary : The GNU Bourne Again SHell (Bash) Description : Bash is an sh-compatible command language interpreter that executes commands read from the standard input or from a file. Bash also incorporates useful features from the Korn and C shells (ksh and csh). Most sh scripts can be run by bash without modification. Bash is ultimately intended to be a conformant implementation of the IEEE POSIX Shell and Tools specification (IEEE Working Group 1003.2).
-
Список файлов в пакете:
rpm -ql имя_пакета
С помощью этой команды можно увидеть полный список файлов в пакете.
Пример 3.9. Получение информации о пакете
user@desktop ~ $ rpm -ql gzip /bin/gunzip /bin/gzip /bin/zcat /usr/bin/gunzip /usr/bin/gzip /usr/bin/zcat /usr/share/doc/gzip-1.3.5 /usr/share/doc/gzip-1.3.5/AUTHORS /usr/share/doc/gzip-1.3.5/ChangeLog.bz2 /usr/share/doc/gzip-1.3.5/NEWS /usr/share/doc/gzip-1.3.5/README /usr/share/doc/gzip-1.3.5/THANKS /usr/share/doc/gzip-1.3.5/TODO /usr/share/info/gzip.info.bz2 /usr/share/man/man1/gunzip.1.gz /usr/share/man/man1/gzip.1.gz /usr/share/man/man1/zcat.1.gz
-
Файлы, изменённые после установки: Во время обновления пакетов часто бывает нужно узнать изменения, произошедшие с момента установки пакета. Это можно сделать, выполнив следующую команду:
rpm -V имя_пакета
...
-
Презентация 8-08: работа с репозитарием
...
Среди дистрибутивов GNU/Linux стало распространённым явлением размещение
пакетов в Интернет, в так называемом репозитарии
пакетов. Администратор может загрузить оттуда самую последнюю версию
пакета и установить его в системе. Для облегчения работы с репозитарием
существуют специальные программы, такие как apt или
yum.
Программа apt впервые появилась в дистрибутиве
Debian GNU/Linux, но позже распространилась и в дистрибутивах, основанных на
RPM.
В процесс разработки и использования программного обеспечения вовлечены несколько лиц, основными являются разработчик, администратор, пользователь и (в открытых системах) разработчик дистрибутива.
Администратор использует специальные средства для установки и обновления программного обеспечения в системе. В открытых системах существует возможность получения любой программы из исходных текстов, но этот способ не всегда удобен.
Многие UNIX-подобные системы предлагают собственные средства управления программами — на основе компиляции программ или на основе бинарных пакетов.
Наиболее распространённым форматом (и менеджером) пакетов является rpm, впервые использованный в дистрибутиве Red Hat.
Современные дистрибутивы используют репозитарии — архивы текущих версий всех пакетов — для более простой установки и обновления программ через Internet. Работа с репозитариями пакетов производится через дополнительные программы, например, APT.
Ключевые термины: makefile, зависимость, пакет, порт, репозитарий, конфликтом
- Курячий Г.В., Маслинский К.А. Операционная система Linux. — М.: Интуит.Ру, 2005. — 392 с.: ил.
