Глава 8 RPM

Глава 8 RPM

Фирма Microsoft и Windows уже приучили нас, что установка любой программы начинается с запуска программ Setup или Install. Затем, после согласия с лицензионным соглашением (по которому фирма-производитель обязывает вас установить программное обеспечение только на один компьютер, и, в свою очередь, сообщает, что не несет никакой ответственности за функционирование этого программного обеспечения), задается пара вопросов (куда и какие модули программного обеспечения установить) и все: «Программа установлена, перезагрузите, пожалуйста, компьютер». Достаточно быстро и просто.

Остаются, конечно, некоторые вопросы: "Почему я не могу убрать лишнюю функциональность, зачем эта игра перезаписала мой DirectX 8 своим DirectX 5, для чего в системе столько DLL для разных версий Visual Basic." Но, в общем, это намного проще, чем вручную копировать какие-то архивы, распаковывать их, править конфигурационные файлы, искать конфликты библиотек и версий, а в самом неприятном случае – получать ошибки компиляции или линковки и просматривать исходные тексты программ. Это еще один упрек Linux со стороны пользователей Windows. И как часто бывает, они не совсем правы. Да, в большинстве своем программы Linux поставляются в виде исходных кодов, упакованных в архив. Но так наиболее просто удовлетворить требование лицензии GNU, которая обязывает дистрибьютора программы в обязательном порядке предоставить потребителю ее исходный код.

Не следует также забывать, что программы разрабатываются не только для Linux, обычно их можно откомпилировать на многих UNIX-платформах, а в UNIX-мире стандартом de-facto для пакетов является так называемый «tarballs». Tarballs – это архивы, которые распаковываются утилитой tar (файлы с расширением tar) или gzip (файлы с расширением tar.gz). Поскольку Linux-программы по большей части распространяются через Интернет, проще выложить на FTP-сервер и скачать оттуда архив только с исходным кодом программы, чем выкачивать архив и с исходными кодами, и с откомпилированной программой. Кроме того, энтузиасты Linux, как правило, имеют привычку смотреть исходные коды программ, изменять их и компилировать так, как им нравится (включать поддержку команд определенного процессора, добиваться максимального уровня оптимизации, различной степени выдачи отладочной информации и т. д.).

Однако с приходом в мир Linux пользователей, которые не желают учить опции компилятора, помнить, какие библиотеки установлены в системе, ждать по полчаса, пока откомпилируется программа и т. п., остро возник вопрос о стандартизации процесса установки программ в Linux. На сегодняшний день есть, по меньшей мере, три, или, если быть совсем точным, три с половиной способа установки программ. Способ первый, «старейшина» – программы распространяются в виде архивов исходных кодов *.tar.gz, которые необходимо распаковать и, в простейшем случае, откомпилировать командами make, make install. Способ второй — воспользоваться программой RPM (Red Hat Linux package management, Red Hat Linux менеджер пакетов) и, соответственно, пакетами RPM, содержащими уже откомпилированный код программ. Способ «два с половиной» – воспользоваться программой RPM и пакетами RPM с исходным кодом. Здесь два варианта: или получать исходный код пакетов, или делать из пакета с исходным кодом пакет с исполняемым кодом и устанавливать. Способ третий — разновидность второго – менеджер пакетов, входящий в дистрибутив Linux Debian. Возможно, в этой главе не будет упомянут какой-то другой способ инсталляции или менеджер пакетов. Мир Linux и Интернет настолько велики, что узнать или охватить все невозможно. Как уже упоминалось, значительная часть современных дистрибутивов тем или иным образом основаны на дистрибутиве Red Hat Linux, или, по крайней мере, имеют утилиты, способные работать с пакетами формата RPM. Поэтому эта глава полностью посвящена RPM-пакетам и RPM-менеджерам.

Система поддержки пакетов RPM

Во многом благодаря RPM, а так же удобной программе инсталляции Linux, дистрибутив Red Hat Linux завоевал огромнейшую популярность. Рассмотрим вкратце основные особенности RPM.

Для системного администратора RPM предоставляет следующие возможности:

• модернизировать отдельные компоненты системы или набора пакетов, сохраняя их конфигурацию;

• получать информацию об используемых пакетом файлах;

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

• производить проверку пакетов;

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

• производить автоматизированное обновление пакетов (например, получение обновлений с FTP-сервера).

Благодаря этому с помощью RPM можно устанавливать, обновлять, удалять пакеты единственной командой в текстовом режиме или несколькими щелчками мышью в графическом менеджере пакетов. Пакет RPM содержит информацию о себе в заголовке пакета. Эта информация при установке пакета добавляется в базу данных установленных пакетов, где содержится информация о том, где находится пакет, какие дополнительные (supporting) пакеты ему необходимы и установлены ли они. Знатоки Windows могут заметить, что централизованная база данных установленных пакетов очень сильно напоминает часто критикуемый реестр Windows. Сравнение, однако, поверхностно. На самом деле, реестр Windows помимо списка установленных программ содержит в себе многочисленные системные настройки, без которых (повреждение или отсутствие реестра) не будет функционировать система в целом. Для Linux отсутствие или повреждение базы данных установленных пакетов вовсе не фатально. Как будет показано далее, базу данных всегда можно попытаться создать заново. Но не это главное. Отсутствие или повреждение базы данных никоим образом не сказывается на работоспособности системы – она полноценно функционирует. Могут возникнуть проблемы с обновлением или установкой пакетов, но их можно обойти с помощью специальных ключей программы RPM (принудительная инсталляция, отказ проверять зависимости и т. п.).

Принципы наименования пакетов

Имя пакета характеризует сам пакет, его версию, версию сборки исполняемых файлов (релиз) и архитектуру и задается в виде «имя_программы-версия-релиз.платформа» или «src.rpm».

Рассмотрим для примера пакет telnet-server-0.17–18.i386.rpm. По названию файла можно определить, что пакет содержит tclnct-ссрвср версии 0.17, версия сборки файлов (релиз) 18 для данной версии пакета Red Hat Linux, собрана для процессора Intel 80386 и выше, формат файла – RPM. Файл пакета, у которого вместо архитектуры (например, i586) стоит src, содержит в себе исходные тексты программы. Иногда встречается немного другая структура именования пакета, например, apache-1.3.3–1.src.rpm. Здесь версия пакета – 1.3.3 – состоит из трех цифр. На инсталляционных дисках Red Hat и на FTP скомпилированные пакеты хранятся в каталоге RPMS, а пакеты, содержащие исходный код, – в каталоге SRPMS.

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

Достоинства RPM

К основным достоинствам RPM относятся:

• удобная установка программ;

• возможность инсталляции по FTP;

• проверка системы на наличие компонентов, необходимых устанавливаемому пакету;

• простое удаление пакетов из системы. При этом осуществляется проверка зависимостей пакетов системы от удаляемого пакета;

• обновление (Upgrade) пакетов с контролем версии, запрет установки пакета с более ранней версией, чем установленный в системе (Degrade);

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

• наличие общей иерархии пакетов, с помощью которой просто определить, к какой категории программ относится пакет;

• обеспечение возможности определения принадлежности файла или каталога к пакету;

• комплексная проверка состояния пакетов в системе: что изменялось, что испортилось, что случайно удалили и т. д.;

• отсутствие необходимости производить перезагрузку системы после инсталляции нового пакета. Пакет готов к эксплуатации сразу после установки.

Недостатки RPM

Пакет RPM имеет и недостатки:

• многие программы пакета обновляются позже, чем официально выходят версии программного обеспечения;

• отсутствие RPM для некоторых программ;

• централизованная база установленных пакетов.

Информация, содержащаяся в пакете

Каждый пакет RPM содержит в себе стандартный набор полей, которые характеризуют содержание пакета. Наиболее интересные для пользователя поля приведены ниже.

• Build Host – имя хоста, на котором производилась сборка пакета;

• Build Date – время сборки пакета;

• Change Log – краткий список изменений в программе, по сравнению с предыдущими версиями;

• Copyright – копирайт владельца;

• Description – описание пакета, обычно 1–2 Кбайт текста;

• Group – группа/подгруппа программного обеспечения, к которому относится пакет. К примеру – Development/Languages;

• License – лицензия, по которой распространяется пакет. Для большинства программ, поставляемых в дистрибутиве, лицензия – GPL. Для большинства библиотек – LGPL;

• Name – имя программы, к примеру apache;

• Version – версия программы;

• Release – релиз (версия сборки);

• RPM version – версия пакета RPM: для Red Hat Linux 1 х версия 4, для более ранних – версия 3;

• Size – размер в байтах;

• Source RPM – пакет с исходными кодами, на базе которого собирался бинарный пакет. Например: gcc-2.96–85.src.ipm;

• Summary – краткое, в одно-два предложения описание пакета. Например: The С Preprocessor;

• URL – Web-адрес разработчика программы;

• Vendor – сборщик пакета, например: Red Hat, Inc.

Категории пакетов

Для удобства пользователей пакеты содержат в себе признак, указывающий, к какой категории программного обеспечения относится пакет (поле Group). Стандартная иерархия пакетов приведена на рис. 8.1.

Рис. 8.1. Стандартная иерархия пакетов

Ниже дана краткая расшифровка категорий пакетов.

• Amusements – развлечения. К этому разделу обычно относятся игры и всякие бесполезные, но веселые программки – глаза, которые следят за курсором, котенок, бегающий по экрану, и т. п.:

– Games – подраздел предназначен для игр;

– Graphics – всякие забавные графические программы, в том числе хранители экрана (screensavers).

• Applications – приложения. Раздел предназначен для пользовательских (в широком смысле) программ. Как правило, сюда помещаются программы общего назначения: редакторы, инженерные пакеты, средства мультимедиа:

– Archiving – подраздел, посвященный программам и утилитам архивации;

– Communications – подраздел, содержащий все, что относится к связи. Здесь собраны разнообразные программы и утилиты для работы с модемами, факсами, ISDN, ATM, радиосвязью и многое другое;

– Databases – подраздел, посвященный базам данных и разнообразным утилитам для взаимодействия с базами данных;

– Editors – редакторы. В этом разделе хранятся разнообразные редакторы, от очень простых консольных редакторов до графических монстров;

– Engineering – подраздел, посвященный инженерным пакетам: редакторы схем, формул, химических соединений, чертежные пакеты и тому подобные приложения;

– File – подраздел, содержащий утилиты для работы с файлами;

– Internet – программы, предназначенные для работы в Интернете: Web-браузеры, почтовые клиенты, клиенты ICQ и новостей, чатов и FTP;

– Multimedia – все для мультимедиа: проигрыватели CD, MP3-файлов, программы для просмотра телепередач и приема радиостанций, микшеры и т. д.;

– Productivity – подраздел для программ, позволяющих увеличить производительность труда: органайзеры, напоминалки, картотеки и т. п.;

– Publishing – подраздел для программ подготовки документов к печати: программы верстки, разметки и т. п.;

– System – подраздел для системных программ. Здесь могут быть программы, предназначенные только для администратора, и программы, интересные только для пользователя;

– Text – подраздел для программ и утилит работы с текстом: поиск слов и фраз, замены и т. п.

• Development – раздел, полностью посвященный программированию и программистам: отладчики, компиляторы, библиотеки разработчика, различные утилиты:

– Debuggers – подраздел для программ-отладчиков;

– Languages – подраздел, посвященный языкам программирования, компиляторам, интерпретаторам;

– Libraries – подраздел для библиотек: по большей части библиотеки разработчика, не системные;

– System – подраздел для системных утилит;

– Tools – подраздел для различного инструментария программиста, не попавшего в предыдущие подразделы.

• Documentation – раздел для документации, поставляемой отдельно от программ.

• System Environment – раздел системного окружения, наиболее ориентированный на ядро системы:

– Base – подраздел для базовых пакетов;

– Daemons – подраздел исключительно для демонов (daemon, демон – программа, выполняющая некоторые системные функции или являющаяся сервером каких-то услуг, сервисов);

– Kernel – подраздел, предназначенный исключительно для ядра Linux как в двоичном виде, так и в исходных кодах;

– Libraries – подраздел для системных библиотек;

– Shells – подраздел для хранения разнообразных командных оболочек.

• User Interface – раздел пользовательского интерфейса. Вернее было бы назвать его разделом, посвященным X Window:

– Desktops – подраздел, посвященный различным оконным менеджерам;

– X – пакеты, относящиеся к X Window;

– X Hardware Support – подраздел содержит пакеты, ориентированные на конкретный тип видеокарт.

Команды консольного менеджера RPM

Раздел полностью посвящен консольному менеджеру RPM. Понятно желание пользоваться графическими менеджерами пакетов – красиво, наглядно, удобно, просто, в конце концов. Но не следует забывать, всегда может случится так, что у вас не будет возможности загрузить X Window (например, необходимо установить новую версию X Window), да и возможностей у RPM побольше, а ресурсов он потребляет несравненно меньше. Тем более, что еще никто не отменял дистанционное администрирование, при котором вообще невозможно воспользоваться графическими пакетами. Раздел практически полностью основывается на содержимом шап-страницы RPM.

Итак, использование RPM, Менеджера пакетов от Red Hat. Может быть выбран один из следующих основных режимов:

• инициализация базы данных;

• пересборка базы данных;

• сборка пакетов;

• рекомпиляция пакетов;

• сборка пакетов из tar-архивов;

• запрос;

• показ полей запроса;

• установка;

• обновление;

• удаление;

• верификация;

• проверка подписи;

• повторная подпись;

• добавление подписи;

• установка владельцев и групп;

• показ конфигурации.

Общие опции

Общие опции могут быть использованы во всех режимах работы:

• -vv – выводить много отладочной информации;

• -quiet – выводить как можно меньше сообщений: как правило, выводятся только сообщения об ошибках;

• -help – вывести более детальную, чем обычно, справку об использовании RPM;

• -version – вывести одну строку, содержащую номер версии используемого RPM;

• -rcfile <список_файлов> – каждый из файлов из разделенного двоеточиями <списка_файлов> последовательно читается RPM на предмет конфигурационной информации. По умолчанию <список_файлов> выглядит как /usr/lib/ipm/ipmrc:/etc/ipmrc:~/.ipmrc. В этом списке обязана существовать только первая строка; все тильды будут заменены значением $номе;

• -root <каталог> – использовать для всех операций файловую систему с корнем в <каталог>. Обратите внимание, это значит, что база данных также будет читаться и модифицироваться под <каталог> и все pre– и post-скрипты будут исполняться после chroot () в <каталог>;

• -dbpath <путь> – использовать базу данных RPM в <путь>;

• -justdb – обновить только базу данных, не файловую систему;

• -ftpproxy <host> – использовать <host> как FTP-прокси (см. разд. «Опции FTP/HTTP»);

• -httpproxy <host> – использовать <host> как НТТР-прокси (см. разд. «Опции FTP/HTTP»);

• -ftpport <порт> – использовать <порт> как FTP-порт прокси-сервера (см. разд. «Опции FTP/HTTP»);

• -httpport <порт> – использовать <порт> как HTTP-порт прокси-сервера (см. разд. «Опции FTP/HTTP»);

• -pipe <cmd> – перенаправляет вывод RPM на вход команды <cmd>.

Опции установки и обновления

Общая форма команды установки новых RPM выглядит так:

rpm -i [опции-установки] <файл_пакета>

Общая форма команды обновления установленных RPM выглядит так:

rpm -U [опции-установки] <файл_пакета>

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

rpm -F [опции-установки] <файл_пакета>

Или

rpm -freshen [опции-установки] <файл_пакета>

Эта команда производит обновление пакетов, но только если в системе существуют более ранние версии этих пакетов.

Допускается задание <файл_пакета> в виде FTP– или HTTP-адресов (например, http://www.freshmeat.net/Linux/ww-l.ll-5.src.rpm). В этом случае перед установкой пакет будет получен с сервера, указанного в адресе. Подробную информацию о встроенной поддержке FTP/HTTP см. в разд. «Опции FTP/HTTP» данной главы.

Опции:

• -force – то же, что и комбинация – replacepkgs, – replace-ffiilleess и – oidpackage. Принудительная установка пакета, невзирая на наличие неудовлетворенных зависимостей или уже установленных пакетов, и моющих более позднюю версию;

• -h, -hash – выводить 50 раз знак # по мере распаковки архива с пакетом. Используется с -v для придания читабельного вида. Можно использовать при автоматической установке пакетов, когда результат инсталляции выводится в журнальный (лог, log) файл;

• -oidpackage – позволяет заменить новый пакет на более старый при обновлении (откатиться назад). Как правило, необходимость отката (rollback) возникает в двух случаях: первый – при смене версий программного обеспечения (например, компилятор gcc поменял версию с 2.9х на 3.0), а новая версия имеет недостатки в функционировании (подвисает, исчезли необходимые вам свойства программы и т. д.). Второй – новая версия программного обеспечения конфликтует с уже установленными пакетами (не те версии библиотек, другой формат вызова модулей и т. п.);

• -percent – выводить процент готовности по мере распаковки архива с пакетом. Задумано для облегчения использования RPM из других утилит;

• -repiacef iies – устанавливать пакеты, даже если они перепишут файлы из других, уже установленных пакетов;

• -replacepkgs – устанавливать пакеты, даже если некоторые из них уже установлены в системе;

• -aiifiles – устанавливать или обновлять все файлы, определенные как missingok (согласно базе RPM – отсутствующие файлы в системе для данного пакета), даже если они уже существуют;

• -nodeps – не проверять зависимости перед установкой или обновлением пакета;

• -noscripts – не исполнять pre– и post-установочных скриптов;

• -notriggers – не исполнять триггер-скриптов, взведенных на установку данного пакета;

• -ignoresize – не проверять файловую систему на наличие достаточного свободного места перед установкой этого пакета;

• -exciudepath <путь> – не устанавливать файлы, чьи имена начинаются с <путь>;

• -exciudedocs – не устанавливать никаких файлов, отмеченных как файлы документации (включает man-документацию и документы texinfo);

• -inciudedocs – устанавливать файлы документации. Это поведение по умолчанию;

• -test – не устанавливать пакет, просто проверить возможность установки и сообщить о потенциальных проблемах;

• -ignorearch – произвести установку или обновление, даже если архитектуры бинарного RPM и машины не совпадают;

• -ignoreos – произвести установку или обновление, даже если операционные системы бинарного RPM и машины не совпадают;

• -prefix <путь> – установить префикс установки в <путь> для переместимых пакетов;

• -relocate <старый_путь>=<новый_путь> – для переместимых пакетов: преобразовывает в <новый_путь> файлы, которые должны были бы быть установлены в <старый_путь>;

• -badreioc – для использования вместе с – relocate. Производит перемещение, даже если пакет непереместимый;

• -noorder – не переупорядочивать список устанавливаемых пакетов. Обычно список переупорядочивается для удовлетворения зависимостей.

Данный текст является ознакомительным фрагментом.



Поделитесь на страничке

Похожие главы из других книг:

Глава 17 DNS

Из книги автора

Глава 17 DNS DNS – это Доменная Система Имен (Domain Name System). DNS преобразует символические имена машин в IP-адреса и наоборот – из IP-адреса в символическое имя. Для чего это нужно? Во-первых, человеку легче запомнить осмысленное имя – типа vasya.ru чем 195.66.195.42, а для компьютера проще


Глава 20 FTP

Из книги автора

Глава 20 FTP Эта глава посвящена протоколу FTP, настройке сервера FTP, проблемам конфигурации и безопасности сервера.Протокол FTPПротокол FTP (File Transfer Protocol, протокол передачи файлов) предназначен для передачи файлов в сети Интернет. Этот протокол был разработан на заре эры


ГЛАВА 14

Из книги автора

ГЛАВА 14 Переменные среды и интерпретатора shellЧтобы продуктивно работать с интерпретатором shell, нужно уметь управлять переменными этого интерпретатора. Переменными интерпретатора shell являются наименования, которым присваиваются значения. В качестве значений может


ГЛАВА 15

Из книги автора

ГЛАВА 15 Использование кавычекВ главе 14 обсуждались методы работы с переменными и операции подстановки. Чаще всего ошибки в использовании кавычек возникают при выполнении подстановок переменных в сценариях. Кавычки оказывают существенное влияние на формирование


ГЛАВА 16

Из книги автора

ГЛАВА 16 Понятие о shell–сценарииВ shell–сценарий может включаться одна или несколько команд; здесь нет общепринятых правил. Зачем же создавать целый сценарий ради двух–трех команд? Все зависит от предпочтений пользователя.В этой главе рассматриваются следующие


ГЛАВА 17

Из книги автора

ГЛАВА 17 Проверка условийПри создании сценария уточняется идентичность строк, права доступа к файлу или же выполняется проверка численных значений. На основе результатов проверки предпринимаются дальнейшие действия. Проверка обычно осуществляется с помощью команды test.


ГЛАВА 18

Из книги автора

ГЛАВА 18 Управляющие конструкцииВсе функциональные сценарии должны предлагать возможности по выбору возможных вариантов. При определенных условиях сценарии должны выполнять обработку списков. Этим вопросам посвящена настоящая глава. Кроме того, в ней описывается


ГЛАВА 19

Из книги автора

ГЛАВА 19 Функции интерпретатора shellДо сих пор весь программный код сценариев данной книги выполнялся последовательно от начала до конца программы. Подобный подход неплох, но при этом некоторые фрагменты кода, рассмотренного в наших примерах, дублируются в пределах


ГЛАВА 21

Из книги автора

ГЛАВА 21 Создание экранного выводаС помощью shell–сценариев можно создавать профессионального вида экраны, позволяющие реализовать интерактивное взаимодействие пользователя с системой. Для этого достаточно располагать цветным монитором и использовать команду tput.В


ГЛАВА 22

Из книги автора

ГЛАВА 22 Создание экранного вводаКогда речь идет об экранном вводе, или вводе данных, подразумевают ввод информации (в нашем случае с помощью клавиатуры), а затем — проверку достоверности введенных данных. Если данные удовлетворяют неким критериям, они


ГЛАВА 23

Из книги автора

ГЛАВА 23 Отладка сценариевОдной из самых сложных задач при создании shell–сценариев является их отладка. Желательно, чтобы пользователь, выполняющий эту задачу, получил консультации на данном этапе. Чтобы избежать распространенных ошибок, достаточно следовать указанному


ГЛАВА 24

Из книги автора

ГЛАВА 24 Встроенные команды интерпретатора shellВ предыдущих главах нам уже встречались конструкции, встроенные в интерпретатор shell Напомним, что речь идет о командах, которые не находятся в каталоге /bin или usr/bin, а встроены в интерпретатор Bourne shell. Скорость выполнения


ГЛАВА 25

Из книги автора

ГЛАВА 25 Дальнейшее изучение конструкции "документ здесь"При рассмотрении стандартного потока ввода и вывода, а также циклов while уже обсуждалась конструкция "документ здесь". Описывались методика пересылки электронной почты и способы формирования экранов меню, но


ГЛАВА 26

Из книги автора

ГЛАВА 26 Утилиты интерпретатора shellВ этой главе рассматриваются следующие темы:    • создание датируемых имен файлов и временных файлов;    • сигналы;   • команда trap и способы перехвата сигналов;   • команда eval;    • команда


ГЛАВА 28

Из книги автора

ГЛАВА 28 Сценарии уровня выполненияЕсли при загрузке системы вам нужно автоматически запустить приложение, службу или сценарий либо корректно завершить их работу при перезапуске системы, то необходимо создать сценарий уровня выполнения. Почти все варианты системы Linux, а


ГЛАВА 29

Из книги автора

ГЛАВА 29 Сценарии cgiВ настоящее время, когда практически на каждом ПК установлен Web–сервер, глава, посвященная сценариям cgi, органически вписывается в книгу по shell–программированию.В главе будут рассмотрены следующие темы:   • базовые сценарии cgi;   • использование