Linux

– IP-Masquerade mini-howto – организация маскарадинга.

Глава 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.