Команда rpm в linux

6.8 Раздел Files

Это раздел где вы должны перечислить файлы для двоичного пакета. У RPM нет способа узнать какие двоичные файлы установлены как результат выполнения . НЕ существует способа сделать это. Некоторые предлагают выполнить команду до и после установки пакета. На многопользовательской системе это неприемлемо, так как другие файлы могут быть созданы в течении процесса построения пакета, которые не имеют ничего общего с самим пакетом.

Есть несколько доступных макросов для выполнения специальных действий. Они перечислены и описаны здесь:

• используется для обозначения документации в исходных текстах пакета, которую вы хотите установить при установке. Документы будут установлены в директорию . Вы можете перечислить много документов в командной строке этого макроса или вы можете перечислить все отдельно, используя этот макрос для каждого документа.
• используется для обозначения конфигурационных файлов в пакете. Этот список включает файлы подобные , , и т.п. Если вы позже удаляете пакет содержащий конфигурационные файлы, все неизмененные файлы будут удалены и все измененные будут переименованы со старыми названиями с добавлением к имени файла. Вы можете перечислять много файлов в этом макросе.
• обозначает единичную директорию в списке файлов включенную как директория которой владеет пакет. По умолчанию, если вы укажете имя директории БЕЗ макроса , то ВСЕ в этой директории будет включено в список файлов и позже установлено как часть пакета.
• позволит вам перечислить ваши файлы в некотором файле внутри директории построения исходных текстов. Это просто великолепно в случае когда у вас пакет, который может построить свой собственный список файлов. Затем вы просто включаете этот список файлов здесь и вы не должны специально перечислять файлы.

Наибольшое предостережение в списке файлов это перечисление директорий. Если вы случайно укажете , то ваш двоичный пакет будет содержать все файлы в директории на вашей системе.

Макроопределения

Теперь пора познакомиться поближе с макросами и переменными. Допустим, мы собираем пакет из SVN, в данном случае в релиз обычно включается дата ревизии. В самом начале spec-файла нужно определить переменную date:

Как мы видим, за определение переменных отвечает макроопределение %define. Теперь в любом месте spec-файла мы можем использовать нашу переменную в виде %{date} (скобки не обязательны, но в РОСЕ принято брать в скобки переменные, и не брать — макроопределения; так их проще различать). Например, определение основных параметров будет выглядеть примерно так:

Обратите внимание, что перед датой стоит , а после даты — число, которое и увеличивается при необходимости поднять релиз. Зачем так сделано? Когда наконец выйдет окончательная версия (в нашем случае — 0.5), ревизию можно будет убрать, а в релиз прописать просто 1

При этом литерально 1 больше, чем любая строка, начинающаяся на , и пакет будет считаться более новым, чем предварительные пакеты, собиравшиеся на основе ревизий SVN.

Крайне популярным макроопределением является конструкция

или просто %if без %else. Суть проста, если условие стоящее при %if истина, то выполняется , в противном случае выполняется .

Допустим, мы опять же собираем что-нибудь из SVN. Обычно внутри архива, если он из SVN, вместо каталога %{name}-%{version} указывают просто %{name} (архив внутри имеет каталог sim, так как финального релиза sim 0.9.5 не существует. Конечный же релиз будет иметь первым каталогом ). Чтобы всякий раз не переписывать spec-файл, можно сделать следующие макроопределения:

Если переменная svn не определена, то будет выполняться часть сценария после %else. Можно также использовать более строгое условие (не забудьте про кавычки):

Внутри всех секций spec-файла мы можем использовать любые команды Linux, без каких либо «наворотов», а вот в шапке файла не всё так просто. Например, нам нужно определить версию firefox для пакета (допустим epiphany) и прописать ее в секцию Requires:. Выглядеть это будет следующим образом:

Обратите внимание на то, что внешняя команда выполняется в %() (почти, как в bash — $()) и в spec-файле необходимо ставить два знака % в параметрах. Таким образом можно вызывать любые команды Linux, например, для определения версии ядра

Ещё одним популярным макроопределение является конструкция %ifarch .. %endif. Если архитектура соответствует указанной после %ifarch, то выполняется какое либо действие. Архитектуры бывают i386, i486, i586, i686, i?86, x86_64, и понятное дело некоторые другие, с которыми вы наверно не столкнётесь.

Как уже отмечалось выше во всех секциях spec-файла вы можете использовать любые команды Shell, включая for, while, if и др.

Опции FTP / HTTP

rpm  может выступать в роликлиента FTP и / или HTTP, так что пакеты можно запрашивать или устанавливать из Интернета. Файлы пакета для операций установки, обновления и запроса могут быть указаны как URL-адрес в стиле ftp  или  http

FTP: // USER: ПАРОЛЬ @ HOST: PORT / путь / к / package.rpm

Если   часть : PASSWORD пропущена, будет запрошен пароль (один раз для пары пользователь / имя хоста). Если и пользователь, и пароль не указаны, используется анонимный  ftp  . Во всех случаях  выполняются пассивные (PASV)  передачи FTP .

rpm  позволяет использовать следующие параметры с URL-адресами ftp:

—ftpproxy  HOST

Хост-  хост  будет использоваться в качестве прокси-сервера для всех передач FTP, что позволяет пользователям проходить через FTP через брандмауэры, использующие прокси-системы. Эта опция также может быть указана путем настройки макроса  % _ftpproxy .

—ftpport  HOST

Номер TCP  PORT,  используемый для соединения ftp на прокси-сервере ftp вместо порта по умолчанию. Эта опция также может быть указана путем настройки макроса  % _ftpport .

rpm  позволяет использовать следующие параметры с  URL-  адресами http

—httpproxy  HOST

Хост-  хост  будет использоваться в качестве прокси-сервера для всех   передач HTTP . Эта опция также может быть указана путем настройки макроса  % _httpproxy .

—httpport  PORT

Номер TCP  PORT  для использования для  http-  соединения на прокси-http-сервере вместо порта по умолчанию. Эта опция также может быть указана путем настройки макроса  % _httpport .

ПРОБЛЕМЫ НАСЛЕДИЯ

Проверка целостности rpm пакета

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

Первая проверка очень важна при скачивании пакетов из интернета, а вторая при подозрении на взлом компьютера.

Публичные ключи для проверки подписи автоматически устанавливаются при установке из дистрибутива, а также полуавтоматически добавляются при установке rpm пакетов для подключения репозиториев . Файлы с ключами в CentOS устанавливаются в каталог . Можно добавить ключ вручную, указав путь к локальному файлу или его url. Файл с ключем должен иметь текстовый формат ‘ASCII armored’

После инсталляции к ключам применимы те же команды, что и к установленным пакетам

– список всех ключей – информация (в том числе имя хозяина) о конкретном ключе – удаление ключа

Проверка файла пакета на целостность

Проверка установленного пакета на целостность

После выполнения этой команды будет выдан список изменившихся файлов с указанием, что именно в них поменялось. Информация о типе изменений состоит из строки аббревиатур, включающих:

• S – размер (Size)
• M – тип файла или права доступа (Mode)
• 5 – контрольная сумма (MD5)
• D – мажор или минор устройства устройства (Device)
• L – содержимое символической ссылки (Link)
• U – владелец (User)
• G – группа (Group)
• T – время модификации (mTime)
• P – капабилити (caPabilities)

Преимущества и недостатки RPM [ править | править код ]

Основные недостатки

• Макропакеты между дистрибутивами могут существенно различаться;
• Раздробленность и несовместимость различных версий. Так, существуют проекты по разработке RPM 4 (rpm.org), RPM5 (rpm5.org), а также большое количество патчей на RPM в дистрибутивах. В частности, это приводит к:

• несовместимости spec-файлов между дистрибутивами (spec-файл ALT Linux чаще всего невозможно собрать на Red Hat или SuSE без значительных исправлений);
• несовместимости названий пакетных зависимостей при попытке установить пакет от другого дистрибутива (например, зависимости в RPM сборки Connectiva создаются по другим правилам, нежели в Mandriva).

Добавление модуля

Как говорилось выше, мы добавим модуль SPNEGO в нашу сборку. Для примера, мы будем использовать динамическое подключение данного модуля.

В моем примере необходимо клонировать проект из GIT-репозитория. Для этого необходимо установить одноименную утилиту:

yum install git

Теперь заходим под ранее созданным пользователем builder:

su — builder

Переходим в каталог для сборки. В нашем случае, это домашняя директория:

$ cd ~

Клонируем исходник модуля в директорию /tmp:

$ git clone https://github.com/stnoonan/spnego-http-auth-nginx-module.git /tmp/spnego-http-auth-nginx-module

Ранее мы уже скачивали исходники nginx, поэтому сразу открываем файл nginx.spec:

$ vi rpmbuild/SPECS/nginx.spec

Находим:

%define BASE_CONFIGURE_ARGS …

После последнего —with-… добавим:

—add-dynamic-module=/tmp/spnego-http-auth-nginx-module

Находим

%description

После него добавляем:

%package module-spnego
Group: %{_group}
Requires: nginx = %{?epoch:%{epoch}:}%{main_version}-%{main_release}
Summary: nginx spnego module
%description module-spnego
Dynamic Spnego module for nginx.

После:

%build

… добавляем:

echo ‘load_module «%{_libdir}/nginx/modules/ngx_http_auth_spnego_module.so»;’ \
    > %{buildroot}%{_sysconfdir}/nginx/modules/spnego-http-auth-nginx-module.conf

Находим разделы %files и после них добавим:

%files module-spnego
%{_libdir}/nginx/modules/spnego-http-auth-nginx-module.conf
%{_libdir}/nginx/modules/ngx_http_auth_spnego_module.so

Запускаем сборку:

$ rpmbuild -bb rpmbuild/SPECS/nginx.spec

Для установки нам понадобится 2 RPM-пакета:

1. nginx-1.19.3-1.el7.ngx.x86_64.rpm
2. nginx-module-spnego-1.19.3-1.el7.ngx.x86_64.rpm

Оба эти пакета будут находиться в каталоге RPMS.

После установки пакета выполняем команду:

nginx -V

Среди полученных опций сборки мы должны увидеть нашу:

… —add-dynamic-module=/tmp/spnego-http-auth-nginx-module …

Также мы должны будем отредактировать конфигурационный файл NGINX, чтобы наши модули подгружались:

vi /etc/nginx/nginx.conf

В корневой секции добавим:

user  nginx;
worker_processes  1;
error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;include /etc/nginx/modules/*.conf;
events {
…

* новая строчка отмечена красным.

Ниже по инструкции будет рассказано, как собрать пакет со своим конфигурационным файлом.

15.2.2. Установка

Обычно файлы, содержащие пакеты RPM, имеют имена вроде foo-1.0-1.i386.rpm. Имя файла включает название пакета (foo), версию (1.0), выпуск (1) и архитектуру (i386). Чтобы установить пакет, войдите в систему под именем root и введите в приглашении оболочки следующую команду:

rpm -Uvh foo-1.0-1.i386.rpm

Если установка пройдёт успешно, на экране появится следующее:

Preparing...                ########################################### 
   1:foo                    ########################################### 

Как вы видите, RPM выводит имя пакета, а затем, по мере установки пакета, последовательность символов «решётка», отражающую процесс установки.

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

error: V3 DSA signature: BAD, key ID 0352860f

Если это новая подпись только для заголовка появляется такое сообщение:

error: Header V3 DSA signature: BAD, key ID 0352860f

Если у вас не установлен ключ, подходящий для проверки подписи, сообщение об ошибке содержит слово NOKEY, например:

warning: V3 DSA signature: NOKEY, key ID 0352860f

За дополнительными сведениями о проверке подписи пакета обратитесь к разделу 15.3 Проверка подписи пакета.

Установка пакетов должна выполняться просто, но иногда вы можете встретить ошибки:

15.2.2.1. Пакет уже установлен

Если пакет той же версии уже установлен, вы увидите:

Preparing...                ########################################### 
package foo-1.0-1 is already installed

Если версия пакета, который вы пытаетесь установить, совпадает с версией уже установленного, но вы, тем не менее, хотите установить пакет, вы можете указать параметр --replacepkgs и RPM проигнорирует эту ошибку:

rpm -ivh --replacepkgs foo-1.0-1.i386.rpm

Этот параметр полезен, если файлы, установленные из пакета RPM, были удалены или вы не хотите, чтобы были установлены оригинальные файлы конфигурации RPM.

15.2.2.2. Конфликтующие файлы

Если вы пытаетесь установить пакет, который содержит файл, установленный другим пакетом или более ранней версий того же пакета, на экране появляется сообщение:

Preparing...                ########################################### 
file /usr/bin/foo from install of foo-1.0-1 conflicts with file from package bar-2.0.20

Чтобы RPM игнорировал эту ошибку, укажите параметр --replacefiles:

rpm -ivh --replacefiles foo-1.0-1.i386.rpm

ИСПОЛЬЗОВАНИЕ GPG ДЛЯ ПОДПИСАНИЯ ПАКЕТОВ

Чтобы подписывать пакеты с использованием GPG,  rpm  должен быть настроен для запуска GPG и возможности находить связку ключей с соответствующими ключами. По умолчанию  rpm  использует те же соглашения, что и GPG, для поиска связок ключей, а именно   переменную среды $ GNUPGHOME . Если ваши брелоки расположены не там, где их ожидает GPG, вам нужно настроить макрос  % _gpg_path  в качестве расположения брелоков GPG для использования.

Для совместимости со старыми версиями GPG, PGP и rpm должны быть настроены только пакеты подписи V3 OpenPGP. Могут использоваться алгоритмы проверки DSA или RSA, но предпочтительнее DSA.

Если вы хотите иметь возможность подписывать создаваемые вами пакеты, вам также необходимо создать собственную пару открытого и секретного ключей (см. Руководство GPG). Вам также нужно будет настроить   макросы rpm

%_подпись

Тип подписи. На данный момент поддерживаются только gpg и pgp.

% _gpg_name

Имя «пользователя», ключ которого вы хотите использовать для подписи ваших пакетов.

Например, чтобы иметь возможность использовать GPG для подписи пакетов от имени пользователя  «John Doe < [email protected] >»  из набора ключей, расположенного в  /etc/rpm/.gpg,  с использованием исполняемого файла  / usr / bin / gpg,  вы могли бы включают

в файле конфигурации макроса. Используйте  / etc / rpm / macros  для конфигурации для системы и  ~ / .rpmmacros для конфигурации для пользователя.

ПРОВЕРКА ВАРИАНТОВ

Общая форма команды проверки rpm:

rpm  { -V | —verify } [ select-options ] [ verify-options

Проверка пакета сравнивает информацию об установленных файлах в пакете с информацией о файлах, взятых из метаданных пакета, хранящихся в базе данных rpm. Помимо прочего, проверка сравнивает размер, сумму MD5, разрешения, тип, владельца и группу каждого файла. Любые несоответствия отображаются. Файлы, которые не были установлены из пакета, например, файлы документации, исключенные при установке с использованием параметра « —excludedocs », будут игнорироваться.

Параметры выбора пакета такие же, как и для запроса пакета (включая файлы манифеста пакета в качестве аргументов). Другие параметры, уникальные для проверки режима:

—nodeps

Не проверяйте зависимости пакетов.

—nodigest

Не проверяйте дайджесты пакетов или заголовков при чтении.

—файлов нет

Не проверяйте какие-либо атрибуты файлов пакета.

—noscripts

Не  выполняйте скриптлет% verifyyscript  (если есть).

—nosignature

Не проверяйте подписи пакетов или заголовков при чтении.

—nolinkto

—nomd5

—nosize

—nouser

—nogroup

—nomtime

—nomode

—nordev

Не проверяйте соответствующий атрибут файла.

Формат вывода — строка из 8 символов, возможный атрибут маркера:

из заголовка пакета, за которым следует имя файла. Каждый из 8 символов обозначает результат сравнения атрибута (ов) файла со значением этого атрибута (ов), записанного в базе данных. Один « . » ( Точка ) означает, что тест пройден, а один « ? » (Вопросительный знак) означает, что тест не может быть выполнен (например, права доступа к файлам препятствуют чтению). В противном случае символ (мнемонически em B oldded) обозначает провал соответствующего   теста —verify

Пакет RPM в системе Ubuntu / Debian

Изначально система управления пакетами RPM была создана для Red Hat Linux. Позже он стал популярным и доступен для Fedora, SuSE Linux и других дистрибутивов Linux на основе Red Hat. Поскольку Red Hat и Debian — это разные системы Linux и обе имеют свой репозиторий пакетов, вы должны быть осторожны при установке пакетов RPM в Ubuntu Linux, чтобы избежать ошибок зависимости. В этом посте будет показано, как вы можете установить пакеты RPM в Ubuntu и других дистрибутивах Debian Linux.

Шаг 1. Установите пакет Alien в системе Debian

В Linux приложение Alien представляет собой конвертер пакетов дистрибутива для Debian Linux. Он может конвертировать пакеты RPM в формат Debian. Вы можете запустить следующую команду в терминальной оболочке Ubuntu с правами суперпользователя, чтобы установить пакет Alien в вашей системе Debian.

sudo apt install alien

Шаг 2. Загрузите пакет RPM

Инструмент Alien позволит установить пакет RPM в вашей системе Ubuntu. Но вы не можете использовать команды YUM или DNF для установки пакетов RPM через репозиторий Red Hat; вам необходимо преобразовать пакет RPM в формат Debian.

Во-первых, вы должны загрузить желаемый RPM-пакет в свою систему. Давайте загрузим пакет RPM и преобразуем его в RPM. Здесь я загружу RPM-пакет Google Chrome, чтобы продемонстрировать процесс. Вы также можете выбрать другие пакеты RPM. Щелкните здесь, чтобы загрузить RPM-пакет Google Chrome.

Шаг 3. Установите RPM-пакеты в Debian Linux

Есть два метода установки пакета RPM в системе Ubuntu. Вы можете преобразовать пакет .rpm в пакет .deb или установить пакет RPM прямо в систему Debian с помощью инструмента Alien. Здесь мы рассмотрим оба способа установки пакета RPM в системе Debian Linux.

Метод 1: преобразование и установка пакета RPM в Ubuntu

После установки инструмента Alien в Debian Linux вы можете преобразовать пакет rpm, который вы скачали ранее. Вы можете выполнить приведенный ниже процесс, чтобы преобразовать пакет. Выполните следующую команду в оболочке терминала, чтобы преобразовать пакет RPM в формат Debian. Не забудьте заменить путь и имя пакета своими.

sudo alien google-chrome-stable_current_x86_64.rpm

Хотя преобразование прошло успешно, теперь вы можете запустить команду dpkg или команду apt install в оболочке терминала, чтобы установить пакет RPM в Ubuntu Linux.

Команда Dpkg для установки пакета в Ubuntu.

sudo dpkg -i google-chrome-stable_88.0.4324.96-2_amd64.deb

Команда apt для установки пакета в Ubuntu.

sudo apt install ./google-chrome-stable_88.0.4324.96-2_amd64.deb

Метод 2: установить пакет RPM непосредственно в Ubuntu

Это простой процесс установки пакета rpm на рабочий стол ubuntu. Сначала откройте каталог, в который вы загрузили пакет .rpm, затем выполните следующую команду Alien в оболочке терминала, чтобы установить пакет непосредственно в Ubuntu или других дистрибутивах Linux на основе Debian.

sudo alien -i google-chrome-stable_current_x86_64.rpm

Проверка

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

При нахождении различий печатается ключевая строка, с обозначением отличий и
имя файла, в котором они найдены.

Сравниваются следующие параметры:

5

Контрольная сумма (подсчитанная по алгоритму MD5)

S

Размер файла

L

Куда указывает символьный линк (если проверяемый файл является симлинком)

T

Время модификации

D

Устройство (раздел), на котором расположен файл

U

Владелец

G

Группа-владелец

M

Права доступа

Проверку лучше выполнять как «root«, так как некоторые файлы
(например, /usr/X11R6/bin/xterm) могут быть недоступны на чтение другим
пользователям и для них всегда будет выдаваться несовпадение по контрольной
сумме.

Пример:

bobby:~# rpm -y setup
S.5....T c /etc/exports
S.5....T c /etc/printcap
S.5....T c /etc/securetty
S.5....T c /etc/services
bobby:~# _

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

Аналогично команде rpm -q, rpm -y можно вместо
имени пакета указывать «-f файл» или «-a«.

Команда rpm -ya полезна для проверки всей системы, но ее
исполнение занимает много времени.