Команда rpm в linux

Remove RPM Package

The RPM installer can be used to remove (or uninstall) a software package.

Enter the following into a terminal window:

The option instructs RPM to erase the software. Check RPM Dependencies

So far, this guide assumes the software either doesn’t have dependencies or already has them installed.

To check the .rpm file for dependencies using the following command:

The system should list all the dependencies:

– This option tells RPM to query the file
– This option lets you specify the target package to query
– This lists the requirements for the package

If there are any missing dependencies, you can install them from the standard repositories using yum or dnf. If your software requires other non-standard software, it will often be noted in the installation instructions.

Step 5. Verify data status post successful migration

To verify that you have not lost any of your data after successful migration from CentOS to Rocky Linux 8.4, check the OS-Release version;

# cat /etc/os-release
NAME="Rocky Linux"
VERSION="8.4 (Green Obsidian)"
ID="rocky"
ID_LIKE="rhel fedora"
VERSION_ID="8.4"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Rocky Linux 8.4 (Green Obsidian)"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:rocky:rocky:8.4:GA"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
ROCKY_SUPPORT_PRODUCT="Rocky Linux"
ROCKY_SUPPORT_PRODUCT_VERSION="8"
#

The above output verifies that we are running on the latest version of Rocky Linux, which is 8.4.

You can also verify that your applications still exist:

As you can see all our application data is intact and we have successfully migrated from CentOS 7 to Rocky Linux 8.

6.8 Раздел Files

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

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

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

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

Вилки

По состоянию на июнь 2010 года в разработке находятся две версии RPM: одна возглавляется Fedora Project и Red Hat, а другая — отдельной группой, возглавляемой предыдущим сопровождающим RPM, бывшим сотрудником Red Hat.

RPM.org

В rpm.org первый крупный пересмотр кода сообщества в июле 2007 года; версия 4.8 была выпущена в январе 2010 года, версия 4.9 — в марте 2011 года, 4.10 — в мае 2012 года, 4.11 — в январе 2013 года, 4.12 — в сентябре 2014 года и 4.13 — в июле 2015 года.

Эта версия используется такими дистрибутивами, как Fedora , Red Hat Enterprise Linux и производные , openSUSE , SUSE Linux Enterprise , Unity Linux , Mageia , OpenEmbedded , Tizen и OpenMandriva Lx (ранее Mandriva ).

RPM v5

Джефф Джонсон, сопровождающий RPM с 1999 года, продолжал разработку вместе с участниками из нескольких других дистрибутивов. Версия RPM 5 была выпущена в мае 2007 года.

Эта версия используется такими дистрибутивами, как Wind River Linux (до Wind River Linux 10), Rosa Linux и OpenMandriva Lx (бывшая Mandriva Linux, которая перешла на rpm5 в 2011 году), а также проектом OpenPKG, который предоставляет пакеты для других распространенных UNIX- платформы.

OpenMandriva Lx собирается вернуться к rpm.org для выпуска 4.0.

OpenEmbedded , последний крупный пользователь RPM5, снова переключился на rpm.org из-за проблем в RPM5.

Установка RPM пакетов в Linux

Давайте сначала рассмотрим синтаксис самой утилиты rpm:

$ rpm -режимопции пакет

Утилита может работать в одном из режимов:

-q, —query — запрос, получение информации;
-i, —install — установка;
-V, —verify — проверка пакетов;
-U, —upgrade — обновление;
-e, —erase — удаление.

Рассмотрим только самые интересные опции программы, которые понадобятся нам в этой статье:

-v — показать подробную информацию;
—vv — выводить отладочную информацию;
—quiet — выводить как можно меньше информации;
-h — выводить статус-бар;
—percent — выводить информацию в процентах о процессе распаковки;
—force — выполнять действие принудительно;
—nodeps — не проверять зависимости;
—replacefiles — заменять все старые файлы на новые без предупреждений;
-i — получить информацию о пакете;
-l — список файлов пакета;
-R — вывести пакеты, от которых зависит этот пакет;

Теперь, когда вы уже имеете представление как работать с этой утилитой, может быть рассмотрена установка rpm пакета в Linux. Самая простая команда установки будет выглядеть вот так:

Для работы с командной текущей директорией должна быть папка с пакетом. Здесь мы устанавливаем режим установки и передаем файл пакета. При успешной установке утилита не выведет ничего, если произойдет ошибка, вы об этом узнаете.

Для того чтобы посмотреть более подробную информацию в процессе установки используйте опцию -v:

Также вы можете включить отображение статус бара в процессе установки:

Чтобы проверить установлен ли пакет, нам уже нужно использовать режим запроса:

Также сразу можно удалить пакет, если он не нужен:

Но у rpm так же как и у dpkg, есть один существенный недостаток. Программа не может разрешать зависимости. В случае отсутствия нужного пакета в системе, вы просто получите сообщение об ошибке и пакет не установится.

Для автоматической загрузки зависимостей во время выполнения установки rpm linux нужно использовать пакетный менеджер дистрибутива. Рассмотрим несколько команд для самых популярных RPM дистрибутивов. В RedHat и других дистрибутивах, использующих Yum используйте такую команду:

Первая опция отключает проверку GPG ключа, а вторая говорит, что мы будем выполнять установку локального пакета. В Fedora, с помощью dnf все делается еще проще:

Пакетный менеджер Zypper и OpenSUSE справляются не хуже:

Вот так очень просто выполняется установка rpm с зависимостями. Но не всем нравится работать в консоли, многие новые пользователи хотят использовать графический интерфейс для решения всех задач, в том числе и этой. Дальше мы рассмотрим несколько таких утилит.

Возможные ошибки

Например:

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

Решение: необходимо воспользоваться поисковиком, чтобы определить, какой именно пакет необходим для продолжения установки и воспользоваться командой yum install <имя пакета> для его установки.

2. Ошибка 127

Например: [include/generated/timeconst.h] Ошибка 127

Причина: как и с предыдущей ошибкой, в системе не установлен один из пакетов, содержащий необходимые библиотеки.

Решение: аналогично предыдущему примеру решения проблемы, необходимо воспользоваться поисковиком, чтобы определить, какой именно пакет необходим для продолжения установки и воспользоваться командой yum install <имя пакета> для его установки.

Step 2: Install RPM File on Linux

Install RPM File Using RPM Command

To install a .rpm package in CentOS Linux, enter the following:

The –i switch tells the package manager you want to install the file.

More information on the RPM installer can be found in the RPM documentation.

Install RPM File With Yum

Alternately, you can use the yum package manager to install .rpm files.

Enter the following:

The localinstall option instructions yum to look at your current working directory for the installation file.

Note: YUM stands for Yellowdog Updater Modified. Normally, yum looks to your enabled software repositories for new software packages to install. More recent verbiage suggests using install instead of localinstall, but it’s up to you.

Install RPM on Fedora

To install an .rpm package on Fedora Linux, enter the following:

Just as in CentOS, the –i switch tells RPM to install the software.

Another method is to use the dnf utility to install the package:

Unlike many Linux tools, DNF is not a set of initials. It is merely the next evolution of the yum package manager.

Структура пакета

Пакеты именуются по следующей схеме: . Распространяются пакеты в виде файлов, в название которых добавляется . Например, расшифровывается так: программа , версия , сборка , архитектура (неоптимизированное приложение под i386 совместимые процессоры). Номер сборки может включать название дистрибутива (FC3 в данном случае, а может и не включать). Архитектура означает скрипты, независимые от архитектуры процессора. Файлы содержат исходные тексты программ и устанавливаются особым образом.

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

PROVIDE – предоставляемая функциональность (например, “mail server”) плюс файлы пакета;
REQUIRENAME – необходимые для корректной работы пакеты, файлы и т.п. (то, что требуется в REQUIRENAME, должно присутствовать в PROVIDE ранее установленных пакетов);
OBSOLETES – список пакетов, которые могут быть удалены т.к. их функциональность и/или файлы заменяютя данным пакетом;
PREIN, POSTIN – скрипты, выполняемые до установки (например, остановка обновляемого демона), и скрипты, выполняемые после установки (например, правка конфигурационных файлов под конкретную машину);
PREUN, POSTUN – скрипты, выполняемые при удалении;
SUMMARY – краткое описание пакета;
DESCRIPTION – подробное описание.

и т.д.

Кроме того, каждый пакет принадлежит к некоторой группе Интернет, Разработка Программ, Развлечения и т.п. Просмотреть секции rpm файла можно в mc.

В дальнейших описаниях <пакет> означает имя пакета без (если установлена одна версия программы, то номер версии и сборки тоже можно опустить), а <файл> означает имя файла .rpm. В качестве файла можно указывать его URL, например,

Re-install grub on a multipath device

Follow the steps below when a server configured to boot from a Storage Area Network (SAN) using multipathed devices requires to have grub re-installed. Grub requires re-installation whenever the Master Boot Record (MBR) on the boot device is damaged or overwritten by other boot loaders. It is also required in situations where the boot device changes post-installation like when the boot from SAN configuration is enabled after the server has been installed or when a single-pathed SAN boot device is reconfigured to become multipathed.

1. Boot the server in rescue mode with multipathing enabled using the “linux rescue mpath” boot option. To view the current multipath configuration, you may run the following command from in a rescue environment:

# multipath -ll

2. Edit /etc/fstab to use multipath device names (/dev/mapper/mpathX) instead of plain names (/dev/sdY) to Mount /boot. We recommend using the UUID of /boot to make the device identification more reliable.

3. Add the multipath device containing /boot to grub and install the boot loader using:

# grub
grub> device (hd0) /dev/mapper/mpatha
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

Note: The grub-install command does not work for multipath devices.

4. Re-generate the initial ramdisk refering below post.

CentOS / RHEL 6 : How to rebuild Initial Ramdisk ImageCentOS / RHEL 5 : How to rebuild Initial Ramdisk Image

Использование yum через прокси

Yum для работы с репозиториями программ использует протокол HTTP/1.1. Если ваш Linux сервер имеет доступ в интернет только через HTTP прокси сервер, вы можете указать имя прокси сервера в конфигурационном файле /etc/yum.con в секции :

Если прокси-сервер требует авторизацию, добавьте строки:

Для проверки работы yum через прокси сервер воспользуйтесь командой

Для проверки я указал публичный прокси сервер с Германии и при установке, сработал плагин fastestmirror, нашел зеркала с которых скорость будет выше:

Если нужно использовать прокси только для некоторых репозиториев, не нужно править файл /etc/yum.conf, а настройки прокси указать в конфигурационном файле репозитория /etc/yum.repos.d/ваш_конфиг.repo.

Итак, в этой статье мы рассмотрели базовые возможности менеджера rpm пакета yum в Linux CentOS/ RHEL.

Местные операции

Пакеты могут поступать из определенного дистрибутива (например, Red Hat Enterprise Linux ) или создаваться для него другими сторонами (например, RPM Fusion для Fedora). Циклические зависимости между взаимозависимыми RPM (так называемый « ад зависимостей ») могут быть проблематичными; в таких случаях одна команда установки должна указать все соответствующие пакеты.

Репозитории

RPM-пакеты часто собираются централизованно в одном или нескольких репозиториях в Интернете. У сайта часто есть свои собственные репозитории RPM, которые могут действовать как локальные зеркала таких интернет-репозиториев или быть локально поддерживаемыми коллекциями полезных RPM.

Передние концы

Несколько внешних интерфейсов для RPM упрощают процесс получения и установки RPM из репозиториев и помогают в разрешении их зависимостей. К ним относятся:

yum используется в Fedora , CentOS 5 и выше, Red Hat Enterprise Linux 5 и выше, Scientific Linux , Yellow Dog Linux и Oracle Linux
DNF , представленный в Fedora 18 (по умолчанию с ), Red Hat Enterprise Linux 8 и CentOS Linux 8.
up2date используется в Red Hat Enterprise Linux , CentOS 3 и 4 и Oracle Linux
Zypper используется в Mer (и, следовательно, в Sailfish OS), MeeGo , openSUSE и SUSE Linux Enterprise
urpmi используется в Mandriva Linux , ROSA Linux и Mageia
apt-rpm , порт Debian Advanced Packaging Tool (APT), используемый в Ark Linux, PCLinuxOS и ALT Linux.
Smart Package Manager , используемый в Unity Linux, доступен для многих дистрибутивов, включая Fedora .
, утилита командной строки, доступная (например) в Red Hat Enterprise Linux

База данных локальной установки RPM

За кулисами диспетчера пакетов работает база данных RPM, хранящаяся в . В качестве серверной части он использует Berkeley DB . Он состоит из единой базы данных ( ), содержащей всю метаинформацию об установленных RPM. Несколько баз данных создаются для целей индексации, репликации данных для ускорения запросов. База данных используется для отслеживания всех файлов, которые были изменены и созданы, когда пользователь (с помощью RPM) устанавливает пакет, что позволяет пользователю (через RPM) отменить изменения и удалить пакет позже. Если база данных повреждена (что возможно, если клиент RPM убит ), индексные базы данных можно воссоздать с помощью команды.

Возможные ошибки

Рассмотрим примеры ошибко, с которыми мы можем столкнуться.

Installed (but unpackaged) file(s) found

Ошибка появляется в конце процесса сборки пакета.

Причина: обнаружены файлы, которые были установлены с помощью make install, но которые не были перечислены в %files. Таким образом, сборщик пакета не знает, что с ними делать.

Решение: секция %files должна содержать все файлы, необходимые для работы приложения. Их нужно перечислить.

Но если у нас есть полная уверенность, что мы перечислили все необходимое, а оставшиеся файлы нам ни к чему, то добавляем в файл spec:

%define _unpackaged_files_terminate_build 0

* в верхнюю часть.

6 ответов

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

Для каждого установленного пакета RPM вы можете запросить базу данных RPM для точных сценариев, которые входят в команду rpm :

Запуск этой команды в пакете ядра для CentOS 6 возвращается среди других:

new-kernel-package – инструмент для сценария установки ядра

После анализа скриптов в Fedora я понимаю, что путь к файлу конфигурации читается из символической ссылки /etc/grub2.conf . Правильная строка grub2-mkconfig :

В Fedora я использую:

, поскольку выполнение без опции readlink возвращает относительный путь и grub2-mkconfig выдает сообщение об ошибке:

Я использую параметр -e , так что если символическая ссылка не разрешает существующий файл, вывод выводится на stdout, поэтому я что-то пошло не так.

На странице man для readlink:

Символьная ссылка /etc/grub2.cfg указывает на версию BIOS. В системе UEFI используйте:

Вы также можете использовать:

отредактируйте файл grub с помощью vi или vim , сохранить изменения и закрыть редактор с помощью: wq!

Это то, что вам нужно запустить для обновления grub в RedHat или CentOS:

Скрипт update-grub в Ubuntu на самом деле просто заглушка для grub-mkconfig , и это могут быть адаптированы к другим дистрибутивам без большой боли. Здесь он полностью:

Это эффективно делает то, что рекомендуется в викторине CentOS и в другие ответы здесь – единственная разница в том, что вам нужно изменить grub на grub2 в команде и пути вывода.

In Ubuntu (and I guess in Debian too) there is a system script named update-grub which automatically executes grub-mkconfig -o with the correct path for the grub configuration file.

Is there any similar command for Red Hat based distributions?

If not, how do the system knows where is the grub configuration file to update when a new kernel version is installed?

Установка пакетов RPM с помощью yum

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

Первым шагом является загрузка файла RPM, который вы хотите установить:

Чтобы установить пакет, используйте команду пути к имени пакета:

запросит подтверждение. Ответьте и пакет RPM будет установлен при условии, что он совместим с вашей системой и соблюдены все зависимости.

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

Вместо загрузки и последующей установки пакета RPM вы можете просто передать URL-адрес пакета RPM команде :

Чтобы обновить пакет RPM, который уже установлен с помощью yum, используйте ту же процедуру, что и при установке пакета.

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

RPM (Red Hat Package Manager)

Как мы уже говорили, RPM — это менеджер пакетов, используемый в операционных системах, основанных на Red Hat, это вся ветка дистрибутивов: Fedora, OpenSUSE, Red Hat, CentOS и т д. Изначально этот пакетный менеджер был разработан в компании Red Hat еще в 1997 году и только для их дистрибутива, но затем он распространился и в другие операционные системы. Вместо обычного сжатия здесь используется сжатие gzip по алгоритму cpio и особый формат файла архива, его мы рассмотрим ниже. Здесь в сравнении rpm или deb, первый кажется лучше, но не все так просто, если в системе нет нужных утилит, то вы не сможете распаковать такой пакет. Кроме cpio могут использоваться и другие алгоритмы сжатия, например, lzma или xz. В последнее время все программное обеспечение подписывается ключами для удостоверения подлинности, вот и RPM поддерживает подпись с помощью GPG и MD5. Технология PatchRPMs или DeltaRPMs позволяет грамотно обновлять RPM пакеты без больших затрат трафика.

Хоть и сказано, что файл rpm — это обычный архив, это не совсем так. Вначале файла находится заголовок, который идентифицирует файл как rpm архив, затем идет подпись, для проверки целостности и подлинности файла. Дальше идет заголовок, в котором содержаться данные о самом пакете, версия, архитектура, список файлов и т д. И только после всего этого идет сам архив с файлами пакета.

Для работы с RPM могут использоваться несколько различных пакетных менеджеров, это универсальная утилита rpm, пакетный менеджер zypper в OpenSUSE, dnf в Fedora, urpmi в Mageia, yum — во многих дистрибутивах, основанных на Fedora.

Рассмотрим основные особенности RPM:

Автоматическое разрешение зависимостей в большинстве случаев корректно
Файл архива имеет специальный формат
Не поддерживается реализация зависимостей с выбором завистимости от пакет1 или пакет2.
Не поддерживаются рекомендованные пакеты
Позволяет настроить зависимость от файла, а не пакета
Все данные об установленных пакетах хранятся в базе данных поэтому при надобности можно проверить контрольные суммы
Поддерживаются сценарии как до, так и после установки программ
Поддерживается формат SRPM, который содержит в себе исходники программы все патчи с инструкции по сборке, позволяющие собрать программу из исходников на локальной машине.
Отличная поддержка Multilib пакетов

Update GRUB2 using grub2-mkconfig

The older method of achieving this behaviour is still possible, but the existing value will need to be unset first:

# grep GRUB_CMDLINE_LINUX /etc/default/grub
GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet"

Here I will update in the GRUB2 configuration file

# grep GRUB_CMDLINE_LINUX /etc/default/grub
GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet ipv6.disable=1"

But as you see the existing kernelopts reflects old GRUB2 entry, so if we reboot the node or rebuild our GRUB2 then the new changes will not reflect on the node.

# grub2-editenv - list | grep kernelopts
kernelopts=root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet

So we need to unset the kernelopts which is an additional step here:

# grub2-editenv - unset kernelopts

next rebuild the grub configuration

# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
done

Next re-verify

# grub2-editenv - list | grep kernelopts
kernelopts=root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet ipv6.disable=1

So our changes are visible as expected.

6.4 Раздел Prep

Это второй раздел в spec-файле. Он используется чтобы сделать исходные тексты готовыми к построению. Здесь вам необходимо сделать все что угодно чтобы сделать исправления в исходных текстах и сделать настройку подобную той, которую необходимо сделать чтобы выполнить .

Одно замечание: Каждый из этих разделов в действительности просто место для выполнения скриптов оболочки. Вы должны просто сделать -скрипт и поместить его после тага для распаковки и исправления ваших исходных текстов. Однако мы добавили макросы чтобы помочь вам сделать это.

Первый из этих макросов это макрос . В своей простейшей форме (без командной строки), он просто распаковывает исходные тексты и делает в директорию исходных текстов. Он также принимает следующие опции:

установит имя директории где будет производиться построение пакета в . Значение по умолчанию равно . Другие возможные значения включают , , или что использует главный файл архива. (Заметим, что эти переменные с не являются настоящими переменными доступными внутри spec-файла. Они просто используются здесь вместо имен примеров. Вам необходимо использовать настоящие имена и версии в вашем пакете, а не эти переменные).
создаст указанную директорию до выполнения распаковки архивов.
будет выполнять распаковку Source# выполнения в директорию (и это делает нечувствительной к опции так что не делайте ее). Это полезно только в случае множества файлов исходных текстов.
будет выполнять распаковку Source# после перехода в директорию.
Эта опция отменяет действия по умолчанию при распаковке исходных текстов и требует опций или чтобы произвести разархивацию главного файла исходных текстов. Вам нужно это в случае наличия дополнительных файлов исходных текстов.
Не удалять директорию до распаковки. Это полезно только когда вы имеете больше одного макроса setup. Эта опция должна использоваться только в макросах setup после первого (но никогда не быть в первом макросе).
Не удалять директорию до распаковки. Это полезно только когда вы имеете больше одного макроса setup. Эта опция должна использоваться только в макросах setup после первого (но никогда не быть в первом макросе).

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

будет прикладывать Patch# как файл заплатки.
указывает количество отбрасываемых директорий для команды patch(1).
Действие по умолчанию — наложение Patch (или Patch0). Этот флаг запрещает действие по умолчанию и будет требовать , чтобы распаковать главный файл с исходными текстами. Эта опция полезна во второй (и последующих) макросах , которые требуют номера отличного от номера в первом макросе.
Вы также можете выполнять вместо выполнения команды:

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

Подключение rpmforge repo в CentOS

Полное название rpmforge репозитория — RepoForge. По информации с сайта wiki.centos.org этот архив больше не поддерживается и не рекомендуется к установке. Но лично я нигде больше не нашел об этом информацию, в том числе и на официальном сайте repoforge.org. Данный репозиторий содержит следующие наборы совместимых RHEL пакетов:

Servers (eg. monitoring, troubleshooting, management)
Desktops (eg. office, leisure, multi-media)
Development (eg. perl, python, ruby libraries)

Установка rpmforge на centos:

Устанавливаем GPG ключ:

# rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt

Идем на страницу загрузки и копируем ссылку rpm пакета под нужную нам архитектуру.

Устанавливаем скопированный rpm пакет:

# yum -y install http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

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

# yum -y install http://repository.it4i.cz/mirrors/repoforge/redhat/el7/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

По последним данным, репозиторий rpmforge закрыт и больше не поддерживается https://github.com/repoforge/rpms/issues/375 https://wiki.centos.org/AdditionalResources/Repositories/RPMForge

Проверяем директорию /etc/yum.repos.d:

# ls -l | grep rpmforge

-rw-r--r--. 1 root root 739 Jun 12 2014 mirrors-rpmforge
-rw-r--r--. 1 root root 717 Jun 12 2014 mirrors-rpmforge-extras
-rw-r--r--. 1 root root 728 Jun 12 2014 mirrors-rpmforge-testing
-rw-r--r--. 1 root root 1128 Jun 12 2014 rpmforge.repo

Все в порядке rpmforge репозиторий установлен.

Installing Grub using grub-install

The easiest way to install Grub, if possible, is using the command grub-install.

This command will:

Install the necessary files in /boot/grub of the current partition.
Install the boot loader in the location indicated, using the traditional naming system.

Examples:

Command	Meaning
`grub-install /dev/sda`	Install Grub files in directory `/boot/grub` of current partition. Install boot loader in master boot record of first hard disk. This is the recommended way to install Grub.
`grub-install /dev/sda1`	Install Grub files in directory `/boot/grub` of current partition. Install boot loader in first partition of first hard disk.
`grub-install /dev/sda2`	Install Grub files in directory `/boot/grub` of current partition. Install boot loader in second partition of first hard disk.

# grub-install /dev/sda
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.

# this device map was generated by anaconda
(hd0)     /dev/sda
#

Подписываем пакет

Установим на созданный файл цифровую подпись, чтобы можно было гарантировать на целевом для установки компьютере, что пакет собрали именно мы. Не все нижеописанные действия можно выполнять от пользователя builder (под которым собирался пакет nginx), поэтому мы будем что-то делать от root (в начале команды #), а что-то от builder ($).

Подпись пакета

Устанавливаем пакеты (от пользователя root):

# yum install rpm-sign pinentry

Генерируем ключ (уже от пользователя builder).

а) В CentOS 7:

$ gpg2 —gen-key

б) В CentOS 8:

$ gpg2 —full-gen-key

Система выкинет запрос, на который мы отвечаем 4 (RSA ключ только для подписи):

Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
(14) Existing key from card
Your selection? 4

Размер ключа можно оставить по умолчанию:

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)

Мы можем указать период, в течение которого будет работать ключ или оставить значение 0 (бессрочно):

Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)

Подтвердим корректность данных:

Is this correct? (y/N) y

Вводим данные для ключа, например:

Подтверждаем корректность введенных данных:

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

Система запросит пароль — вводим дважды. Если мы увидим окно:

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

Необходимо выполнять различные действия, чтобы сгенерировалась последовательность. Просто открываем вторую сессию SSH и вводим команду:

dd if=/dev/sda of=/dev/zero

Ждем завершения генерации ключа. После его можно посмотреть командой:

$ gpg -K

Теперь открываем файл:

$ vi ~/.rpmmacros

И добавим:

%_signature gpg
%_gpg_name DMOSK
%_gpgbin /usr/bin/gpg2
%__gpg_sign_cmd %{__gpg} gpg —force-v3-sigs —batch —verbose —no-armor —no-secmem-warning -u «%{_gpg_name}» -sbo %{__signature_filename} —digest-algo sha256 %{__plaintext_filename}’

* где:

_signature — указывает с помощью чего будет создаваться подпись.
_gpg_name — имя ключа, которое мы указывали при его создании.
_gpgbin — путь до исполняемого файла gpg.
__gpg_sign_cmd — определяет команду, с помощью которой будет выполняться подпись пакета.

Можно подписывать пакет:

$ rpm —addsign rpmbuild/RPMS/x86_64/nginx-1.19.3-1.el7.ngx.x86_64.rpm

Система должна запросить пароль и подписать пакет.

Проверка подписи

На компьютере, где мы сгенерировали ключ, выполняем экспорт public key:

gpg2 -a —export DMOSK > RPM-GPG-KEY-dmosk

* где DMOSK — имя ключа; RPM-GPG-KEY-dmosk — файл, в который мы поместим открытый ключ.

В результате мы получим ключ RPM-GPG-KEY-dmosk. Переносим его на целевой компьютер, где выполняем проверку (например, с помощью WinSCP).

Импортируем ключ (нужны права root):

rpm —import RPM-GPG-KEY-dmosk

Проверяем подпись пакета:

rpm —checksig nginx-1.19.3-1.el7.ngx.x86_64.rpm

Мы должны получить что-то на подобие:

nginx-1.19.3-1.el7.ngx.x86_64.rpm: digests signatures OK