Rpm-файл, что это такое
Обновлено: 21.11.2024
Несмотря на то, что следующие детали, касающиеся фактического формата файла пакета RPM, были точными на момент написания этой статьи, следует помнить о трех моментах:
Формат файла может быть изменен.
Если с файлом пакета необходимо каким-либо образом манипулировать, настоятельно рекомендуется использовать соответствующие подпрограммы rpmlib для доступа к файлу пакета. Почему? См. пункт №1!
В этом приложении описывается самая последняя версия формата файла RPM: версия 3. Утилита file(1) может использоваться для просмотра версии формата файла пакета.
Отбросив эти предостережения, давайте заглянем внутрь RPM-файла…
Файлы пакетов записываются на диск в сетевом порядке байтов. При необходимости RPM автоматически преобразует порядок байтов в хост-систему при чтении файла пакета. Давайте рассмотрим каждый раздел, начиная с лида.
Лид — это первая часть файла пакета RPM. В предыдущих версиях RPM он использовался для хранения информации, используемой внутри RPM. Однако сегодня единственная цель лида — облегчить идентификацию файла пакета RPM. Например, команда file(1) использует лид. [1] Вся информация, содержащаяся в лиде, продублирована или заменена информацией, содержащейся в заголовке. [2]
Давайте взглянем на реальный файл пакета и изучим различные фрагменты данных, из которых состоит лид. На следующем экране число слева от двоеточия представляет собой смещение в байтах в шестнадцатеричном формате от начала файла. Восемь групп по четыре символа показывают шестнадцатеричное значение байтов в файле — два байта на группу из четырех символов. Наконец, символы справа показывают значения ASCII байтов данных. Когда значение байта данных приводит к непечатаемому символу, вместо него вставляется точка (""."). Вот первые тридцать два байта файла пакета — в данном случае это файл пакета rpm-2.2.1-1.i386.rpm:
00000000: edab eedb 0300 0000 0001 7270 6d2d 322e . об/мин-2. 00000010: 322e 312d 3100 0000 0000 0000 0000 0000 2.1-1.
Первые четыре байта (edab eedb) — это магические значения, которые идентифицируют файл как файл пакета RPM. И команда file, и RPM используют эти магические числа, чтобы определить, является ли файл законным или нет.
Следующие два байта ( 0300 ) указывают версию формата файла RPM. В этом случае основной номер версии файла — 3, а дополнительный номер версии — 0. Версии RPM более поздние, чем 2.1, создают файлы пакетов версии 3.0.
Следующие два байта ( 0000 ) определяют тип файла RPM. В настоящее время определены два типа:
Двоичный файл пакета (тип = 0000 )
Исходный файл пакета (тип = 0001 )
В данном случае это двоичный файл пакета.
Следующие два байта ( 0001 ) используются для хранения архитектуры, для которой был создан пакет. В данном случае цифра 1 относится к архитектуре i386. [3] В случае с исходным файлом пакета эти два байта следует игнорировать, поскольку исходные пакеты не созданы для конкретной архитектуры.
Следующие шестьдесят шесть байтов (начиная с 7270 6d2d ) содержат имя пакета. Имя должно заканчиваться нулевым байтом, что оставляет шестьдесят пять байтов для обычного имени RPM в стиле имя-версия-выпуск. В этом случае мы можем прочитать имя с правой стороны вывода:
Поскольку имя rpm-2.2.1-1 короче шестидесяти пяти байтов, выделенных для имени, оставшиеся байты заполняются нулями.
Пропуская пространство, выделенное для имени, мы видим два байта ( 0001 ):
00000040: 0000 0000 0000 0000 0000 0000 0001 0005 . 00000050: 0400 0000 24e1 ffbf 6bb3 0008 00e6 ffbf . $. к.
Эти байты представляют операционную систему, для которой был создан этот пакет. В этом случае 1 равно Linux. Как и в случае перевода архитектуры в номер, операционная система и соответствующие кодовые номера можно найти в файле /usr/lib/rpmrc .
Следующие два байта (0005) указывают тип подписи, используемой в файле. Подпись типа 5 является новой для RPM-файлов версии 3. Подпись появляется следующей в файле, но нам нужно обсудить дополнительные детали, прежде чем исследовать подпись.
Изучив структуру C, определяющую интерес, и сопоставив ее с байтами в реальном файле пакета, можно легко извлечь данные из интереса. С точки зрения программирования также легко манипулировать данными в лиде — это просто вопрос использования имен элементов из структуры. Но есть проблема. И из-за этой проблемы лид больше не используется внутри RPM.
В чем проблема и почему лид больше не используется RPM? Ответом на эти вопросы является одно слово: негибкость. Техника определения структуры C для доступа к данным в файле не очень гибкая. Давайте рассмотрим пример.
Что мы можем сделать? Что ж, мы, конечно, могли бы изменить структуру таким образом, чтобы длина элемента имени составляла 100 байт.Но когда создается новая версия RPM с использованием этой новой структуры, возникают две проблемы:
Любой файл пакета, созданный с помощью новой версии RPM, не сможет читать старые форматы пакетов.
Любая старая версия RPM не сможет установить пакеты, созданные с помощью более новой версии RPM.
Не очень хорошая ситуация! В идеале мы хотели бы как-то устранить требование, чтобы формат данных, записываемых в файл пакета, был выгравирован на граните. Мы должны иметь возможность делать следующие вещи без потери совместимости с существующими версиями RPM.
Добавить дополнительные данные в формат файла.
Изменить размер существующих данных.
Изменить порядок данных.
Похоже, это большая проблема, но есть решение…
Решение состоит в стандартизации метода извлечения информации из файла. Для этого создается четко определенная структура данных, содержащая информацию о данных, которую легко найти, а затем физически отделяется эта информация от данных.
Когда данные требуются, их можно найти с помощью удобной для поиска информации, которая указывает на сами данные. Преимущество заключается в том, что данные можно размещать в любом месте файла, а формат самих данных может изменяться.
Структура заголовка — это решение RPM, позволяющее легко манипулировать информацией стандартным способом. Единственная цель структуры заголовка в жизни состоит в том, чтобы содержать ноль или более фрагментов данных. Файл может иметь более одной структуры заголовков. На самом деле файл пакета RPM состоит из двух — подписи и заголовка. Именно от этого заголовка структура заголовка получила свое название.
Каждая структура заголовка состоит из трех разделов. Первый раздел известен как заголовок структуры заголовка. Заголовок структуры заголовка используется для определения начала структуры заголовка, ее размера и количества содержащихся в ней элементов данных.
За заголовком структуры заголовка следует область, называемая индексом. Указатель содержит одну или несколько записей указателя. Каждая запись индекса содержит информацию об определенном элементе данных и указатель на него.
После индекса идет магазин. Именно в хранилище хранятся элементы данных. Данные в хранилище упакованы максимально плотно. Порядок, в котором хранятся данные, не имеет значения — это далеко от структуры C, используемой в лидерстве.
Давайте более подробно рассмотрим фактический формат структуры заголовка, начиная с заголовка структуры заголовка:
Заголовок структуры заголовка всегда начинается с трехбайтового магического числа: 8e ad e8 . За ним следует однобайтовый номер версии. Далее идут четыре байта, которые зарезервированы для будущего расширения. После зарезервированных байтов следует четырехбайтовое число, указывающее, сколько записей индекса существует в этой структуре заголовка, за которым следует еще одно четырехбайтовое число, указывающее, сколько байтов данных является частью структуры заголовка.
Индекс структуры заголовка состоит из нуля или более элементов индекса. Каждая запись имеет длину шестнадцать байт. Первые четыре байта содержат тег — числовое значение, определяющее, на какой тип данных указывает запись. Значения тегов изменяются в зависимости от положения структуры заголовка в файле RPM. Список фактических значений тегов и того, что они представляют, будет включен в это приложение позже.
За тегом следует четырехбайтный тип , представляющий собой числовое значение, описывающее формат данных, на которые указывает запись. Типы и их значения не изменяются от структуры заголовка к структуре заголовка. Вот текущий список:
Для некоторых типов данных может потребоваться пояснение. Тип данных STRING — это просто строка с завершающим нулем, а STRING_ARRAY — это набор строк. Наконец, тип данных BIN представляет собой набор двоичных данных. Обычно это используется для идентификации данных, которые длиннее INT, но не для печати STRING.
Далее идет четырехбайтовое смещение, содержащее положение данных относительно начала хранилища. Мы поговорим о магазине чуть позже.
Наконец, имеется четырехбайтовый счетчик, содержащий количество элементов данных, на которые указывает запись индекса. Есть несколько нюансов в значении счетчика, и они сосредоточены вокруг типов данных STRING и STRING_ARRAY. Данные STRING всегда имеют счетчик, равный 1, а данные STRING_ARRAY имеют счетчик, равный количеству строк, содержащихся в хранилище.
Хранилище — это место, где хранятся данные, содержащиеся в структуре заголовка. В зависимости от типа сохраняемых данных следует помнить о некоторых деталях:
Для данных STRING каждая строка заканчивается нулевым байтом.
Все данные в сетевом порядке байтов.
Отбросив все эти детали, давайте взглянем на подпись.
Раздел подписи следует за файлом пакета RPM.Он содержит информацию, которую можно использовать для проверки целостности и, при необходимости, подлинности большей части файла пакета. Подпись реализована в виде структуры заголовка.
Возможно, вы заметили слово "большинство" выше. Информация в структуре заголовка подписи основана только на содержимом заголовка файла пакета и архива. Данные в лиде и структура заголовка подписи не включаются при создании информации о подписи и не являются частью каких-либо последующих проверок на основе этой информации.
Хотя это упущение может показаться слабым местом RPM, на самом деле это не так. В случае лида, поскольку он используется только для легкой идентификации файлов пакета, любые изменения, внесенные в эту часть файла, в худшем случае оставят файл в таком состоянии, что RPM не распознает его как допустимый. пакетный файл. Аналогично, любые изменения в структуре заголовка подписи сделают невозможным проверку целостности файла, поскольку информация о подписи будет изменена по сравнению с исходными значениями.
Используя наши новые знания о структурах заголовков, давайте взглянем на сигнатуры в rpm-2.2.1-1.i386.rpm:
00000060: 8ead e801 0000 0000 0000 0003 0000 00ac .
Первые три байта ( 8ead e8 ) содержат магическое число для начала структуры заголовка. Следующий байт (01) — это версия структуры заголовка.
Как мы уже говорили ранее, следующие четыре байта ( 0000 0000 ) зарезервированы. Четыре байта после этого (0000 0003) представляют количество записей индекса в секции подписи, а именно три. Далее следуют четыре байта (0000 00ac), которые указывают, сколько байтов данных хранится в подписи. Шестнадцатеричное значение 00ac при преобразовании в десятичное означает, что длина хранилища составляет 172 байта.
Следом за первыми 16 байтами идет индекс. Каждая из трех записей индекса в этой структуре заголовка состоит из четырех 32-битных целых чисел в следующем порядке:
00000070: 0000 03e8 0000 0004 0000 0000 0000 0001 .
Тег состоит из первых четырех байтов ( 0000 03e8 ), что равно 1000 при переводе из шестнадцатеричного. Заглянув в исходный каталог RPM в файл lib/signature.h, мы находим следующие определения тегов:
Тег, который мы изучаем, предназначен для подписи размера. Продолжим.
Следующие четыре байта ( 0000 0004 ) содержат тип данных. Как мы видели ранее, тип данных 4 означает, что данные, хранящиеся для этой записи индекса, представляют собой 32-битное целое число. На мгновение пропуская следующие четыре байта, последние четыре байта ( 0000 0001 ) представляют собой количество 32-битных целых чисел, на которые указывает эта запись индекса.
Теперь вернемся к четырем байтам до счетчика ( 0000 0000 ). Это число представляет собой смещение в байтах, по которому находится сигнатура размера. Он имеет значение ноль, но вопрос, нулевые байты от чего? Ответ, хотя это и не приносит нам особой пользы, заключается в том, что смещение вычисляется от начала хранилища. Итак, сначала мы должны найти, где начинается магазин, и мы можем сделать это, выполнив простой расчет.
Во-первых, вернитесь к началу раздела подписи. (Мы сделали копию здесь, чтобы вам не нужно было листать со страницы на страницу)
00000060: 8ead e801 0000 0000 0000 0003 0000 00ac .
000000a0:0004 4c4f b025 b097 1597 0132 df35 d169 ..LO.%. 2.5.i
Если мы правильно рассчитали, первые четыре байта ( 0004 4c4f ) должны представлять размер этого файла. Преобразовывая в десятичную систему, это 281 679. Давайте посмотрим на размер фактического файла:
Хм, что-то не так. Или это? Похоже, что нам не хватает 336 байт, или в шестнадцатеричном формате — 150. Интересно, как это красивое круглое шестнадцатеричное число, не так ли? А пока давайте пройдемся по остальным элементам указателя и посмотрим, не появится ли где-нибудь еще шестнадцатеричный код 150.
00000080: 0000 03e9 0000 0007 0000 0004 0000 0010 .
000000a0:0004 4c4f b025 b097 1597 0132 df35 d169 ..LO.%. 2.5.i 000000b0:329c 5375 8900 9503 0500 31ed 6390 a520 2.Su. 1.с..
00000090: 0000 03ea 0000 0007 0000 0014 0000 0098 .
Он имеет значение тега 03ea (1002 в десятичном формате — блок подписи PGP) и также является типом данных BIN. Данные начинаются с 20 десятичных байтов от начала области данных, что соответствует смещению файла b4 (в шестнадцатеричном формате). Это очень важно — 152 байта! Вот данные, начиная с 8900:
Заголовок содержит всю доступную информацию о пакете. Такие записи, как имя пакета, версия и список файлов, содержатся в заголовке. Как и раздел подписи, заголовок имеет формат структуры заголовка. В отличие от подписи, которая имеет только три возможных типа тегов, заголовок имеет более шестидесяти различных тегов. Список определенных в настоящее время тегов появится позже в этом приложении в разделе под названием «Список тегов заголовков». Имейте в виду, что список тегов часто меняется — окончательный список появляется в исходниках RPM в lib/rpmlib.h .
00000150: 8ead e801 0000 0000 0000 0021 0000 09d3 .
Как и раньше, байт, следующий за магическим символом, идентифицирует эту структуру заголовка как формат версии 1. После четырех зарезервированных байтов мы находим количество записей, хранящихся в заголовке (0000 0021). Преобразовав в десятичный вид, мы обнаружим, что в заголовке 33 записи. Следующие четыре байта ( 0000 09d3 ), преобразованные в десятичные числа, сообщают нам, что в хранилище 2515 байт данных.
Поскольку заголовок представляет собой структуру заголовка, как и подпись, мы знаем, что следующие 16 байтов являются первой записью индекса:
00000160: 0000 03e8 0000 0006 0000 0000 0000 0001 .
Первые четыре байта (0000 03e8) — это тег, который является тегом для имени пакета. Следующие четыре байта указывают, что данные имеют тип 6 или строку с завершающим нулем. В следующих четырех байтах есть смещение, равное нулю, что означает, что данные для этого тега находятся первыми в хранилище. Наконец, последние четыре байта ( 0000 0001 ) показывают, что счетчик данных равен 1, что является единственным допустимым значением для данных типа STRING.
Чтобы найти данные, нам нужно взять смещение от начала первой записи индекса в заголовке (160) и добавить количество записей индекса (21), умноженное на размер записи индекса (10). ). Выполняя математические действия (помните, что все показанные значения представлены в шестнадцатеричном формате), мы получаем смещение в хранилище, шестнадцатеричное значение 370. Поскольку смещение для этой конкретной записи индекса равно нулю, данные должны начинаться со смещения 370: р>
00000370: 7270 6d00 322e 322e 3100 3100 5265 6420 об/мин.2.2.1.1.Красный
Поскольку тип данных для этой записи представляет собой строку с завершающим нулем, нам нужно продолжать считывать байты, пока мы не достигнем байта, числовое значение которого равно нулю. Находим байты 72, 70, 6d и 00 — ноль. Глядя на дисплей ASCII справа, мы видим, что байты образуют строку rpm , которая является именем этого пакета.
Теперь немного более сложный пример. Давайте посмотрим на следующую запись указателя:
00000250: 0000 0403 0000 0008 0000 0199 0000 0018 .
Тег 403 означает, что эта запись представляет собой список имен файлов. Тип данных 8 или STRING_ARRAY, кажется, подтверждает это. Из предыдущего примера мы обнаружили, что область данных для заголовка начинается со смещения 370. Добавление смещения к первому имени файла (199) дает нам 509. строки, содержащие имена файлов:
00000500: 696e 6974 6462 0a0a 002f 6269 6e2f 7270 initdb. /bin/rp 00000510: 6d00 2f65 7463 2f72 706d 7263 002f 7573 m./etc/rpmrc./us
Байт по смещению 509 равен 2f — символу "/". Прочитав до первого нулевого байта, мы обнаружим, что имя первого файла — /bin/rpm, за которым следует /etc/rpmrc. Это продолжается еще для 22 имен файлов.
Есть много других тегов, которые мы могли бы расшифровать, но все они выполняются одинаково.
В следующем списке показаны доступные теги вместе с их определенными значениями для использования в заголовке. Этот список актуален для версии 4.3 RPM. Самая последняя версия находится в файле lib/rpmlib.h в последней версии исходников RPM.
За заголовком следует архив. Архив содержит фактические файлы, составляющие пакет. Архив сжат с помощью GNU zip. Мы можем убедиться в этом, если посмотрим на начало архива:
В этом примере архив начинается со смещения d43 . Судя по содержимому /usr/lib/magic, первые два байта gzip-файла должны быть 1f8b, что, собственно, мы и видим. Следующий байт ( 08 ) является флагом, используемым GNU zip, чтобы указать, что файл был сжат методом «дефляции» gzip. Восьмой байт имеет значение 02, что означает, что архив был сжат с использованием настройки максимального сжатия gzip. Следующий байт содержит код, указывающий на операционную систему, под которой был сжат архив. 03 в этом байте указывает, что сжатие выполнялось в UNIX-подобной операционной системе.
Остальная часть файла пакета RPM представляет собой сжатый архив. После распаковки архив представляет собой обычный архив cpio в формате SVR4 с контрольной суммой CRC.
ПримечанияСледует отметить, что архитектура, используемая внутри RPM, фактически хранится в заголовке. Это значение предназначено исключительно для использования file(1).
Первоначально RPM расшифровывался как Red Hat Package Manager. Итак, RPM — это система управления пакетами. Название RPM по-разному относится к формату файла .rpm, файлам в этом формате, программному обеспечению, упакованному в такие файлы, и самому диспетчеру пакетов. RPM предназначался в первую очередь для дистрибутивов Linux; формат файла является базовым форматом пакета Linux Standard Base. RPM распространяется на условиях GPL.
Несмотря на то, что RPM был создан для использования в Red Hat Linux, теперь он используется во многих дистрибутивах GNU/Linux. Он также был перенесен на некоторые другие операционные системы, такие как Novell NetWare (начиная с версии 6.5 SP3) и IBM AIX (начиная с версии 4).
Пакет RPM может содержать произвольный набор файлов. Большая часть обнаруженных файлов RPM представляет собой «двоичные RPM» (или BRPM), содержащие скомпилированную версию некоторого программного обеспечения. Однако файлы RPM могут также содержать исходный код, который затем называется «исходными RPM» (или SRPM), используемыми для создания пакета. SRPM имеют соответствующий тег в заголовке файла, который отличает их от обычных (B)RPM, заставляя их извлекаться в /usr/src при установке. SRPM также обычно имеют расширение файла «.src.rpm» (.spm в файловых системах, ограниченных тремя символами расширения, т. е. старая DOS FAT).
Формат двоичный и состоит из четырех разделов:
- Лид, который идентифицирует файл как RPM-файл и содержит некоторые устаревшие заголовки.
- Подпись, которую можно использовать для обеспечения целостности и/или подлинности.
- Заголовок, который содержит метаданные, включая имя пакета, версию, архитектуру, список файлов и т. д.
- Файловый архив (полезная нагрузка), обычно в формате cpio, сжатый с помощью gzip. Инструмент rpm2cpio позволяет извлекать файл cpio без необходимости установки пакета RPM.
- Более поздние версии RPM также могут использовать сжатие bzip2, lzip, lzma или xz.
- Формат RPM 5.0 поддерживает использование xar для архивирования.
Открыть/извлечь файл RPM в Windows
Easy 7-Zip легко открывает/распаковывает RPM-файл в Windows. Easy 7-Zip был разработан на основе 7-Zip. 7-Zip — известный файловый архиватор с открытым исходным кодом. Easy 7-Zip — это простая в использовании версия 7-Zip. Бесплатное программное обеспечение с открытым исходным кодом сохраняет все функции 7-Zip и добавляет несколько полезных функций, которые делают программное обеспечение более удобным для пользователя.
Easy 7-Zip работает в Windows 10/8.1/8/7/Vista/2008/2003/XP/2000 (совместимы как с 32-разрядной, так и с 64-разрядной версиями).
- Скачать бесплатно Easy 7-Zip
- Установите Easy 7-Zip, следуя пошаговым инструкциям.
- При установке RPM автоматически свяжется с Easy 7-Zip.
- Дважды щелкните файл RPM, чтобы открыть файл RPM с помощью Easy 7-Zip.
Вы увидите файлы или папки в файле RPM, затем нажмите кнопку «Извлечь», чтобы извлечь файл RPM.ол>Ссылки для скачивания Easy 7-Zip:
Вы можете попробовать другие альтернативные бесплатные программы, которые открывают/распаковывают RPM-файл в Windows. Например:
- PeaZip
- TUGZip
- Бесплатный архиватор B1
- ИЗАрк
- Зипег
- Универсальный экстрактор
- Свободная дуга
- Бицер
Открыть/извлечь RPM-файл на Mac
B1 Free Archiver открывает/распаковывает RPM-файл на Mac. B1 Free Archiver — бесплатная программа для создания архивной папки и извлечения архивного файла. B1 Archiver работает на всех платформах — Windows, Linux, Mac и Android. Бесплатное ПО поддерживает большинство популярных форматов, включая RPM.
Бесплатный архиватор B1 совместим с:
- Mac OS X 10.9 Mavericks
- Mac OS X 10.8 Mountain Lion
- Mac OS X 10.7 Lion
- Mac OS X 10.6 Snow Leopard
Альтернативное бесплатное ПО, которое открывает/распаковывает RPM-файл на Mac.
- Разархиватор
- Zipeg для Mac
- ЭЗ 7з
- 7zX
Открыть/извлечь RPM-файл в Linux
RPM (менеджер пакетов RPM) — это популярная утилита для установки программного обеспечения в Unix-подобных системах, особенно в Red Hat Linux.
Установите пакет RPM в Linux, введите:
Обновите файл RPM, введите:
Удалить (стереть) RPM-пакет, введите:
Список всех установленных пакетов, введите:
Чтобы извлечь файлы пакета RPM без его установки, вам необходимо установить rpm2cpio. rpm2cpio извлекает архив cpio из пакета RPM Package Manager (RPM).
Установите rpm2cpio в CentOS и Fedora
Установите rpm2cpio в Debian и Ubuntu
Извлечь файл RPM в Linux
- -i: извлечь
- -d: создать каталоги
- -m: сохранить время модификации
- -v: подробно
Список файлов в пакете RPM:
Советы: в Debian или Ubuntu вы можете преобразовать пакет RPM в пакет DEB с помощью Alien и обработать пакет DEB с помощью dpkg; или обработайте RPM-файл напрямую с помощью smart.
Пакеты RPM поставляются с одним файлом на пакет. Все файлы RPM имеют следующий базовый формат из четырех разделов:
Идентификатор, также называемый лидом или rpmlead, указывает на то, что этот файл является RPM-файлом. Он содержит магическое число, которое команда файла использует для обнаружения файлов RPM. Он также содержит информацию о версии и архитектуре.
Идентификатор начинается с так называемого магического числа. Команда file считывает первые несколько байтов файла и сравнивает найденные значения с содержимым /usr/share/magic (/etc/magic во многих системах UNIX), базы данных магических чисел.Это позволяет команде file быстро идентифицировать файлы.
Идентификатор включает номер версии RPM, то есть версию формата файла RPM, используемого для пакета. Идентификатор также имеет флаг, который сообщает тип файла RPM, содержит ли файл двоичный или исходный пакет. Флаг архитектуры позволяет программному обеспечению RPM перепроверить, не пытаетесь ли вы установить пакет для несовместимой архитектуры.
Подпись появляется после раздела лида или идентификатора. Подпись RPM помогает проверить целостность пакета и, при необходимости, подлинность.
Подпись работает, выполняя математическую функцию над заголовком и разделом архива файла. Математическая функция может представлять собой процесс шифрования, например PGP (Pretty Good Privacy), или дайджест сообщения в формате MD5.
Раздел идентификатора больше не содержит достаточно информации для описания современных RPM. Кроме того, раздел идентификатора далеко не так гибок, как того требуют сегодняшние пакеты. Чтобы устранить эти недостатки, был введен раздел заголовка, содержащий дополнительную информацию о пакете.
Запись заголовка идентифицирует это как заголовок RPM. Он также содержит количество записей индекса и размер данных записи индекса.
Каждая запись индекса использует структуру, содержащую номер тега для содержащихся в ней данных. Сюда входят идентификаторы тегов для сообщения об авторских правах, имя пакета, номер версии и т. д. Номер типа идентифицирует тип элемента. Смещение указывает, где в разделе данных начинаются данные для этого элемента заголовка. Количество указывает, сколько элементов данного типа находится в этой записи заголовка. Вы можете умножить количество на размер типа, чтобы получить количество байтов, используемых для записи заголовка.
Большинство этих тегов говорят сами за себя; однако некоторые теги имеют особое значение. Тег RPMTAG_SIZE содержит размер всех обычных файлов полезной нагрузки. Тег RPMTAG_ARCHIVESIZE содержит несжатый размер раздела полезной нагрузки, включая необходимые заголовки cpio. Тег RPMTAG_COOKIE содержит непрозрачную строку.
Согласно стандартам LSB, RPMTAG_PAYLOADFORMAT всегда должен быть cpio. RPMTAG_PAYLOADCOMPRESSOR должен быть gzip. Значение RPMTAG_PAYLOADFLAGS всегда должно быть равно 9.
Тег RPMTAG_OPTFLAGS содержит специальные флаги компилятора, используемые для сборки пакета. Теги RPMTAG_PLATFORM и RPMTAG_RHNPLATFORM содержат непрозрачные строки.
Тег RPMTAG_HEADERSIGNATURES указывает, что это запись подписи. Тег RPMTAG_HEADERIMMUTABLE указывает элемент заголовка, который используется при вычислении подписей. Эти данные должны быть сохранены.
Раздел подписи реализован в виде структуры заголовка, но не считается частью заголовка RPM. В Таблице D-4 перечислены специальные теги, связанные с подписью.
Тег SIGTAG_SIGSIZE указывает размер разделов заголовка и полезных данных, а SIGTAG_PAYLOADSIZE содержит несжатый размер полезных данных.
Чтобы проверить подлинность пакета, тег SIGTAG_PGP содержит RSA-подпись OpenPGP Signature Packet версии 3 для областей заголовка и полезной нагрузки. Тег SIGTAG_GPG содержит подпись DSA пакета подписи OpenPGP версии 3 для областей заголовка и полезной нагрузки. SIGTAG_DSAHEADER содержит подпись DSA только для раздела заголовка. Если включен тег SIGTAG_DSAHEADER, должен также присутствовать тег SIGTAG_GPG. SIGTAG_RSAHEADER содержит подпись RSA только для раздела заголовка. Если тег SIGTAG_RSAHEADER включен, тег SIGTAG_PGP также должен присутствовать.
Набор тегов, специфичных для установки, сообщает программе rpm, как запускать сценарии до и после установки. В таблице D-5 перечислены эти теги.
В этой статье показано, как упаковать скрипт в RPM-файл для простой установки, обновления и удаления из ваших систем Linux. Прежде чем перейти к деталям, я объясню, что такое RPM-пакет и как его можно установить, запросить, удалить и, самое главное, создать самостоятельно.
В этой статье рассматриваются:
- Что такое пакет RPM.
- Как создать пакет RPM.
- Как установить, запросить и удалить пакет RPM.
Подробнее об автоматизации
Что такое пакет RPM?
RPM означает Диспетчер пакетов Red Hat. Он был разработан Red Hat и в основном используется в операционных системах Linux на базе Red Hat (Fedora, CentOS, RHEL и т. д.).
Пакет RPM использует расширение .rpm и представляет собой набор (набор) различных файлов. Он может содержать следующее:
- Двоичные файлы, также известные как исполняемые файлы (nmap, stat, xattr, ssh, sshd и т. д.).
- Файлы конфигурации ( sshd.conf , updatedb.conf , logrotate.conf и т. д.).
- Файлы документации ( README , TODO , AUTHOR и т. д.).
Имя пакета RPM имеет следующий формат:
Некоторые пакеты также включают сокращенную версию дистрибутива, для которого они были созданы, например:
Как создать пакет RPM
Для сборки RPM-пакета вам потребуются следующие компоненты:
- Рабочая станция или виртуальная машина, на которой запущен дистрибутив на основе RPM, например RHEL или Fedora.
- Программное обеспечение для создания пакета.
- Исходный код для упаковки.
- SPEC-файл для создания RPM.
Установка необходимого программного обеспечения
Для сборки пакета RPM необходимо установить следующие пакеты:
После установки rpmdevtools создайте дерево файлов, необходимое для сборки RPM-пакетов:
- Каталог BUILD используется в процессе сборки RPM-пакета. Здесь хранятся, перемещаются и т. д. временные файлы.
- Каталог RPMS содержит пакеты RPM, созданные для разных архитектур, и noarch, если он указан в файле .spec или во время сборки.
- Каталог SOURCES, как видно из названия, содержит исходники. Это может быть простой скрипт, сложный проект C, который необходимо скомпилировать, предварительно скомпилированная программа и т. д. Обычно исходники сжимаются в виде файлов .tar.gz или .tgz.
- Каталог SPEC содержит файлы .spec. Файл .spec определяет, как создается пакет. Подробнее об этом позже.
- Каталог SRPMS содержит пакеты .src.rpm. Пакет Source RPM не принадлежит архитектуре или дистрибутиву. Фактическая сборка пакета .rpm основана на пакете .src.rpm.
Пакет .src.rpm очень гибок, поскольку его можно собирать и пересобирать для любого другого дистрибутива и архитектуры на основе RPM.
Теперь вы знакомы с содержимым каждого каталога, так что теперь создайте простой скрипт для распространения:
При этом создается сценарий оболочки с именем hello.sh , который выводит на терминал "Hello world". Это просто, но достаточно, чтобы продемонстрировать упаковку.
Поместите скрипт в указанную папку
Чтобы собрать пакет для своего скрипта, вы должны поместить его в каталог, в котором система сборки RPM ожидает, что он будет находиться. Создайте для него каталог, используя семантическое управление версиями, как это делается в большинстве проектов, а затем переместите hello.sh в него:
Большая часть исходного кода распространяется в виде архива, поэтому используйте команду tar для создания файла архива:
Затем переместите только что созданный архив в каталог SOURCES:
Создайте файл .spec
Пакет RPM определяется файлом .spec. Синтаксис файла .spec строг, но rpmdev может сгенерировать для вас шаблонный файл:
При этом создается файл hello.spec , который необходимо переместить в каталог SPECS. Запустите дерево ~/rpmbuild, чтобы увидеть, как выглядит структура каталогов:
Сгенерированный файл hello.spec представляет собой хорошую отправную точку, но в нем нет конкретной информации о том, что вы создаете. Сгенерированный файл .spec предполагает, что я собираюсь компилировать и создавать программное обеспечение.
Вы упаковываете скрипт Bash, поэтому можете сделать некоторые упрощения. Например, нет процесса сборки, потому что нет кода для компиляции. Я добавил BuildArch: noarch, поскольку этот пакет действителен для 32-разрядной, 64-разрядной архитектуры, Arm и любой другой архитектуры ЦП, на которой работает Bash.
Я также добавил Requires: bash, чтобы пакет гарантировал установку Bash. Этот простой скрипт "hello world", конечно же, работает в любой оболочке, но это верно не для всех скриптов, так что это хороший способ продемонстрировать зависимости.
Как вы заметили, в файлах .spec есть много ярлыков. Они называются макросами, и в документации по пакету Fedora есть отличный список того, что доступно. Важно использовать макросы в ваших файлах .spec. Они помогают обеспечить согласованность во всех системах RPM, помогают избежать ошибок в именах файлов и нумерации версий, а также упрощают обновление файла .spec при выпуске новой версии скрипта.
Например, необходимо точно указать, какие файлы установлены в разделе %files. Здесь я явно поместил следующую строку:
Это работает, потому что я хочу, чтобы сценарий перешел к % (это макрос, который по умолчанию транслируется в /usr/bin, но настраивается, когда пользователи хотят установить в другое место, например, /usr/local/bin ). Вы можете проверить значения макроса, запустив:
Другие полезные макросы:
- % имя пакета (как указано в поле Имя:)
- % версии пакета (как определено в поле Версия:)
- % общих данных (по умолчанию /usr/sbin)
- % каталог конфигурации (по умолчанию /etc)
Проверка файла .spec на ошибку (rpmlint)
Команда rpmlint может находить ошибки в файлах .spec:
Сообщается о 2 ошибках, но обе допустимы.Кода для сборки не требуется, поэтому нет необходимости в разделе %build, а исходный архив представляет собой локальный файл и не имеет сетевого URL-адреса.
Все выглядит хорошо.
Сборка пакета (rpmbuild)
Чтобы собрать пакет RPM, используйте команду rpmbuild. Ранее в этом руководстве я упомянул разницу между .src.rpm (исходный пакет RPM) и пакетом .rpm.
Чтобы создать RPM-пакет .src:
Флаги -bs имеют следующие значения:
Чтобы создать двоичный пакет .rpm:
Флаги -bb имеют следующие значения:
Используйте -ba для создания обоих.
Установка пакета RPM
После успешной сборки пакета вы можете установить пакет RPM с помощью команды dnf:
В качестве альтернативы его можно установить с помощью команды rpm напрямую:
Убедитесь, что пакет установлен
Чтобы убедиться, что пакет установлен правильно, выполните следующую команду:
Также можно просмотреть запись %changelog о пакете:
Посмотрите, что находится в пакете RPM
Легко увидеть, какие файлы содержит RPM-пакет:
Удаление пакета RPM
Удалить пакет из системы так же просто, как и установить. Вы можете использовать команду dnf:
Читайте также: