Управление программным обеспечением

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

Что включает в себя управление программным обеспечением

Презентация 8-01: этапы работы с программой

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

  • разработчик;
  • системный администратор;
  • пользователь.

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

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

Рисунок 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, «Основные составляющие пакета»).

Рисунок 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-*», релизующие отдельные компоненты базовой системной библиотеки).

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

Пример зависимости пакетов в системе

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

Менеджер пакетов RPM

Презентация 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. Любые действия по изменению пакетов в системе требуют прав суперпользователя.

  1. Установка пакета:

    rpm -i имя_пакета

    Менеджер пакетов проверяет зависимости и конфликты для данного пакета, а затем разворачивает его в операционной системе.

  2. Обновление пакета:

    rpm -U имя_пакета

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

  3. Удаление пакета:

    rpm -e имя_пакета

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

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

    1. Список установленных пакетов:

      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
      ...


    2. Поиск пакета по файлу:

      rpm -qf имя_файла

      Полезной функцией является поиск пакета, который содержит заданный файл.

      Пример 3.7. Получение пакета по имени файла

      user@desktop ~ $ rpm -qf /var/log/messages
      syslog-common-1.4.1-alt23


    3. Информация о пакете:

      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).


    4. Список файлов в пакете:

      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


    5. Файлы, изменённые после установки: Во время обновления пакетов часто бывает нужно узнать изменения, произошедшие с момента установки пакета. Это можно сделать, выполнив следующую команду:

      rpm -V имя_пакета

      ...

Репозитарии пакетов

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

...

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

Программа apt впервые появилась в дистрибутиве Debian GNU/Linux, но позже распространилась и в дистрибутивах, основанных на RPM.

Резюме

Презентация 8-09: резюме

В процесс разработки и использования программного обеспечения вовлечены несколько лиц, основными являются разработчик, администратор, пользователь и (в открытых системах) разработчик дистрибутива.

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

Многие UNIX-подобные системы предлагают собственные средства управления программами — на основе компиляции программ или на основе бинарных пакетов.

Наиболее распространённым форматом (и менеджером) пакетов является rpm, впервые использованный в дистрибутиве Red Hat.

Современные дистрибутивы используют репозитарии — архивы текущих версий всех пакетов — для более простой установки и обновления программ через Internet. Работа с репозитариями пакетов производится через дополнительные программы, например, APT.

Ключевые термины: makefile, зависимость, пакет, порт, репозитарий, конфликтом

Дополнительные материалы

  1. Курячий Г.В., Маслинский К.А. Операционная система Linux. — М.: Интуит.Ру, 2005. — 392 с.: ил.

Вопросы

Презентация

Рисунок 3.18. Презентация 8-01: этапы работы с программой

Презентация 8-01: этапы работы с программой


Рисунок 3.19. Презентация 8-02: способы установки программ

Презентация 8-02: способы установки программ


Рисунок 3.20. Презентация 8-03: из чего состоит пакет

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


Рисунок 3.21. Презентация 8-04: зависимость и конфликт

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


Рисунок 3.22. Презентация 8-05: менеджер пакетов RPM

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


Рисунок 3.23. Презентация 8-06: название RPM-пакета

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


Рисунок 3.24. Презентация 8-07: Основные операции RPM

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


Рисунок 3.25. Презентация 8-08: работа с репозитарием

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


Рисунок 3.26. Презентация 8-09: резюме

Презентация 8-09: резюме








На главную









Радио для всех
©
Научно-популярный образовательный ресурс


Создать сайт бесплатно