Сборка rpm пакетов и настройка своего репозитория

Введение

RPM это Red Hat Package Manager (Менеджер пакетов
RedHat). Хотя он содержит Red Hat в своем имени, он полностью
предназначен работать как открытая пакетная система доступная для
использования кем угодно. Она позволяет пользователям брать
исходный код для нового программного обеспечения и упаковывать его
в форме исходного и двоичного кода, так что двоичные файлы могут
быть легко установлены и отслежены, а исходный код легко построен.
Эта система также сопровождает базу данных всех пакетов и их
файлов, что может быть использовано для проверки пакетов и запроса
информации о файлах и/или пакетах.

Red Hat Software поощряет создателей других дистрибутивов чтобы
они взглянули на RPM и использовали его для своих собственных
дистрибутивов. RPM является довольно гибкой системой и легкой в
использовании, хотя он обеспечивает основу для очень сложных
систем. Он также полностью открыт и доступен, и мы будем
увеличивать список найденных ошибок и исправлений. Разрешение дано
на свободное использование и распространение RPM без оплаты под
действием GPL.

Более полная документация о RPM доступна в книге Ed Bailey,
Maximum RPM. Эта книга доступна для скачивания или покупки с
www.redhat.com.

Сборка из исходников

Рассмотрим пример создания RPM из пакета, который нужно собирать из исходников с помощью команды make. Например, возьмем данную программу: github.com/brettlaforge/pg_redis_pubsub.

Создадим файл spec:

rpmdev-newspec rpmbuild/SPECS/pg_redis_pubsub.spec

Теперь откроем его и приведем к виду:

vi rpmbuild/SPECS/pg_redis_pubsub.spec

Name:           pg_redis_pubsub
Version:        1.0.2
Release:        1%{?dist}
Summary:        Redis Publish from PostgreSQL
License:        X11 License
URL:            https://github.com/brettlaforge/pg_redis_pubsub
Source0:        %{name}-%{version}.tar.gz
BuildRequires:  postgresql-devel postgresql-server-devel
BuildRequires:  hiredis-devel
Requires:       postgresql
%if 0%{?rhel} < 8
Requires:       hiredis-last >= 0.13.3-1
%else
Requires:       hiredis = 0.15
%endif
%define         _build_id_links none
%description
Redis Publish from PostgreSQL
%prep
%{__rm} -rf %{name}-%{version}
%{__mkdir} -p %{name}-%{version}
%{__tar} -xzvf %{SOURCE0} -C %{_builddir}/%{name}-%{version} —strip-components 1
%build
cd %{name}-%{version}
%{__make}
%install
cd %{name}-%{version}
%{__make} install DESTDIR=%{buildroot}
%clean
%{__rm} -rf $RPM_BUILD_ROOT
%{__rm} -rf $RPM_BUILD_DIR/*
%files
%defattr(-,root,root)
%{_libdir}/pgsql/redis.so
%{_datadir}/pgsql/extension/redis.control
%{_datadir}/pgsql/extension/redis—0.0.1.sql
%doc %{_datadir}/doc/extension/redis.mmd
%changelog
* Fri Jul  9 2021 root
—

* чтобы понять, как заполнить spec-файл, рекомендуется для начала собрать и установить приложение вручную с помощью make и make install. Также необходимо изучить документацию устанавливаемого пакета или (при наличие возможности) поговорить с разработчиками программного обеспечения.

Установим зависимости, которые необходимы для сборки (BuildRequires):

yum-builddep rpmbuild/SPECS/pg_redis_pubsub.spec

* утилита yum-builddep сама читает зависимости, необходимые для сборки и устанавливает недостающие пакеты.

Теперь копируем исходник на свой компьютер. В моем примере клонируем репозиторий:

git clone https://github.com/brettlaforge/pg_redis_pubsub.git

Готовим архив и помещаем его в каталог rpmbuild/SOURCES:

tar -czvf rpmbuild/SOURCES/pg_redis_pubsub-1.0.2.tar.gz pg_redis_pubsub

Проверяем корректность SPEC-файла:

rpmlint rpmbuild/SPECS/pg_redis_pubsub.spec

В моем примере команда вернула ответ:

rpmbuild/SPECS/pg_redis_pubsub.spec: W: invalid-url Source0: pg_redis_pubsub-1.0.2.tar.gz
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

Данное предупреждение можно проигнорировать.

Выполняем сборку:

rpmbuild -bb rpmbuild/SPECS/pg_redis_pubsub.spec

Если она пройдет без ошибок, мы должны найти RPM-пакет в каталоге rpmbuild/RPMS/x86_64, где x86_64 — архитектура пакета.

6.1 Файл rpmrc

Настройка RPM доступна через файл . Пример
выглядит подобно:

Строка заставляет RPM найти строку
производителя. Она может быть из файла или из
заголовка самого spec-файла. Что выключить эту опцию, смените число
на . Тоже самое является правдой для строк
и .

Следующая строка это строка . Вы можете
определить ее здесь или позже в заголовке spec-файла. При
построении пакета для особого дистрибутива это хорошая идея
убедиться что строка правильна, даже хотя она требуется.
Строка обозначает тоже самое, но может быть чем
угодно (например, Joe’s Software and Rock Music Emporium).

RPM также сейчас поддержку для построения пакетов для множественных
архитектур. Файл может содержать переменную «optflags»
для построения вещей, которые требуют специфических для данной
архитектуры флагов для построения. Смотрите следующие разделы для
описания как использовать эту переменную.

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

Установка 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 с зависимостями. Но не всем нравится работать в консоли, многие новые пользователи хотят использовать графический интерфейс для решения всех задач, в том числе и этой. Дальше мы рассмотрим несколько таких утилит.

Опытным пользователям. Альтернативные способы установки программного обеспечения

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

Сторонние репозитории

Можно поискать сторонние репозитории для РОСА/Mandriva Linux. Они могут содержать программы, версии которых новее чем те, что содержатся в официальных репозиториях. Кроме того, можно найти пакеты, которых вообще нет в официальных репозиториях.

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

РОСА/Mandriva не может предоставить какую-либо поддержку для пакетов, предоставляемых третьими сторонами. При возникновении проблем, связанных с использованием таких пакетов, просьба обращаться за поддержкой к стороннему поставщику этих пакетов.

Очень многие пользователи жалуются: «Это приложение не работает!» На этот счёт можно дать несколько рекомендаций. Старайтесь использовать приложения из официальных репозиториев. Помните, что приоритетным является использование именно официальных репозиториев

Кроме того, использование новейшей версии пакета (и, возможно, содержащей ошибки) не так важно, как использование более старой, но лучше оттестированной версии. Если использование программы более новой версии так критично, её можно найти в backports.

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

Пересборка с помощью source RPM более позднего релиза РОСА Linux

Если необходим какой-либо пакет или его версия, отсутствующий в официальном или стороннем репозиториях для данного релиза РОСА Linux, но доступный для последующих релизов (включая Cooker), можно попробовать перекомпилировать SRPM из более позднего релиза. Source RPM можно найти на любом официальном зеркале РОСА в подкаталоге релиза /SRPMS, где имеется необходимый вам пакет. Для создания source RPM, следуйте инструкциям из Основы RPM: Вам нужно будет выполнить шаги из раздела «Предварительные задачи», а затем, следовать инструкциям раздела «Из существующих «исходников» RPM».

Установка программ с использование исходных кодов

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

Что такое пакеты

Как уже отмечалось, весь Linux состоит из пакетов. В RedHat работу
с пакетами выполняет программа rpm (RedHat Package Manager),
а сами файлы, содержащие пакеты, имеют расширение .rpm.
Кроме RedHat существует еще несколько дистрибутивов Linux, использующих
rpm; самые известные — Caldera, SuSE и KSI. Их так и
называют — rpm-системы.

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

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

Кроме того, само имя пакета состоит из собственно названия и версии.
Например, lynx-2.8.2-3.i386.rpm — программа lynx,
версия 2.8.2, build 3. К сожалению, формальных правил, позволяющих
понять, где кончается имя и начинается версия, нет.

Файлы пакетов обычно расположены в одном из трех мест — в
дистрибутиве, в разделе дополнений (updates) или в резделе
«пожертвований» (contrib). В ИЯФ для RedHat 5.2/Intel это соответственно

Пакеты с исходными кодами всегда лежат в директориях
SRPMS/, и содержат исходный код для всех архитектур.

оБЪЧБОЙС РБЛЕФПЧ

лБЦДЩК РБЛЕФ RPM ЙНЕЕФ ОБЪЧБОЙЕ, ЛПФПТПЕ УПУФПЙФ ЙЪ ОЕУЛПМШЛЙИ ЮБУФЕК:

• оБЪЧБОЙЕ РТПЗТБННЩ
• чЕТУЙС РТПЗТБННЩ
• оПНЕТ ТЕМЙЪБ (ЛПМЙЮЕУФЧП ТБЪ РЕТЕУВПТЛЙ РТПЗТБННЩ ПДОПК Й ФПК ЦЕ ЧЕТУЙЙ). фБЛЦЕ ЮБУФП ЙУРПМШЪХЕФУС ДМС ПВПЪОБЮЕОЙС ДЙУФТЙВХФЙЧБ, РПД ЛПФПТЩК УПВТБО ЬФПФ РБЛЕФ, ОБРТЙНЕТ mdv (Mandriva Linux) ЙМЙ fc4 (Fedora Core 4).
• бТИЙФЕЛФХТБ, РПД ЛПФПТХА УПВТБО РБЛЕФ (i386, ppc Й Ф. Д.)

уПВТБООЩК РБЛЕФ ПВЩЮОП ЙНЕЕФ ФБЛПК ЖПТНБФ ОБЪЧБОЙС:

<ОБЪЧБОЙЕ>-<ЧЕТУЙС>-<ТЕМЙЪ>.<БТИЙФЕЛФХТБ>.rpm

nano-0.98-2.i386.rpm

йОПЗДБ Ч РБЛЕФ ЧИПДСФ ЙУИПДОЩЕ ЛПДЩ. фБЛЙЕ РБЛЕФЩ ОЕ УПДЕТЦБФ ЙОЖПТНБГЙЙ ПВ БТИЙФЕЛФХТЕ, ПОБ ЪБНЕОСЕФУС ОБ src. оБРТЙНЕТ:

libgnomeuimm2.0-2.0.0-3.src.rpm

-develnoarch.rpm

Построение RPM для нескольких архитектур

Сейчас RPM может использоваться для построения пакетов для
Intel i386, Digital Alpha с работающим Linux и the Sparc. Также
было сообщено, что RPM работает на SGI и рабочих станциях HP.
Существует несколько свойств, которые делают построение пакетов не
всех платформах легким. Первое из этих свойств это директива
«optflags» в файле . Она может быть использована
для установки используемых для построения программного обеспечения
флагов в значения соответствующие определенной архитектуре. Другое
свойство это макрос «arch» в spec-файле. Оно может быть
использована чтобы делать разные вещи в зависимости от архитектуры
на которой производится посторонние. Еще одно свойство это
директива «Exclude» в заголовке.

Зачем это нужно?

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

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

Управление установленным ПО также сильно облегчается

Существует список всего
установленного ПО, что полезно, когда вы хотите посмотреть, установлено ли что-то.
Более важно, что задача обновления становится пустячным делом. И, наконец, упрощается
проверка ПО

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

Файлы .htaccess

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

и смените на . Так же добавьте:

для исключения в отображении на сайте.

Для можно использовать опции:

А вообще смените стандартное имя .htaccess на другое с помощью параметра :

Тут можно используя модуль Apache настроить внешний вид. Завернуть в тег и используя html5, css3, javascript, jquery, bootstrap, backbone, awesome сделать конфетку, как это сделал я:

Вот что будет при использовании в браузере без поддержки javascript или с отключенным:

Сами файлы web интерфейса нужно будет скрыть как от vsftpd так и от демонстрации на сайте, делается аналогичными способами что и для сокрытия файла.

Настроить внешний вид листинга через или в nginx:

1. http://www.oglib.ru/apman/mod/mod_autoindex.html
2. https://habr.com/post/353478/

Настройка доступа по ftp

Запускаем службу и прописываем ее в автозапуск:

Настройка службы:

Настроем SeLinux:

Перезапустим службу:

В случае использования файла — продублируйте, чтобы файл был надежно защищен от доступа по ftp:

Сборка пакета

Теперь перейдём непосредственно к сборке пакета. Исходники и патчи должны лежать в каталоге SOURCES, а spec файл в каталог SPECS. После этого нужно отдать команду:

 rpmbuild -ba spec-файл

После этого пакет соберётся (или не соберётся, а вывалится с ошибками), и в подкаталогах каталога RPMS появятся бинарные пакеты, а в каталоге SRPMS появится исходник.

Очень часто, перед самым завершением сборки, rpmbuild выдаёт сообщение о найденных, но неупакованных файлах. Это означает, что вы просто не указали их в секции %files. Необходимо просто
добавить их туда. Если же вы не хотите чтобы эти файлы попадали в пакет, то можно воспользоваться одним из следующих способов:

Добавить в секцию %files макроопределение

%exclude путь_к_файлу/файл

Добавить в начало spec-файла макроопределение

%define _unpackaged_files_terminate_build 0

Если необходимо собрать только бинарник или только исходник, то вместо -ba следует использовать -bb и -bs соответственно. Из полезных параметров rpmbuild можно отметить -clean (удалить весь мусор), -rmsource (удалить исходники из каталога SOURCE) и -target=архитектура (собрать пакет под конкретную архитектуру).

Можно также выполнять сценарии только в определённой секции. Описывать подобные параметры мы здесь не будем, см. man rpmbuild.

Раздел 10. Расширенные возможности RPM

10.1 Зависимости пакета 10.1.1 Имена зависимостей 10.1.2 Установка предварительных требований 10.1.3 Зависимости сборки 10.1.4 Автоматизация создания списка зависимостей 10.2 Установка триггеров 10.3 Написание проверочных скриптов 10.4 Создание субпакетов 10.4.1 Предоставление информации о субпакетах 10.4.2 Скрипты в субпакетах 10.4.3 Сборка субпакетов 10.5 Создание пакетов с переопределяемыми путями 10.5.1 Задание префикса 10.5.2 Редактирование секции files 10.5.3 Проблемы создания пакетов с переопределяемыми путями 10.6 Условная сборка 10.6.1 Условные макросы 10.6.2 Условные блоки 10.6.3 Архитектурно-зависимые условия

Использование rpm

Хотя rpm выполняет все функции работы с пакетами
(включая создание .i386.rpm из .src.rpm), сейчас рассмотрим лишь
основные действия.

Установка.
Для установки пакета используется команда rpm -i
(Install), которой указывается полное имя файла, содержащего пакет.
Пример:

Если пакет уже установлен, rpm откажется его устанавливать.
Если же это новая версия (т.е. делается не установка, а обновление), то
надо воспользоваться командой rpm -U (Upgrade); фирма
RedHat рекомендует «для красоты» использовать форму
rpm -Uvh — при этом «прогресс» в установке показывается
индикатором из символов «#«. Пример:

bobby:~# rpm -Uvh wu-ftpd-2.4.2b18-2.1.i386.rpm
wu-ftpd                     ##################################################
bobby:~# _

Если требуется установить несколько пакетов, то можно указать их все
в одной команде (через пробелы). Иногда это нужно — например,
при обновлении программы, состоящей из нескольких пакетов (например,
Netscape), чтобы rpm не выдавал ошибок из-за зависимостей
пакетов.

Удаление.
Для удаления установленного пакета используется команда
rpm -e (Erase). Ей указывается имя пакета (можно без
версии), и без суффикса «.i386.rpm». Пример:

При удалении нескольких пакетов их также стоит указать все вместе в
одной команде, чтобы rpm не «ругался» на удаление пакета, от
которого зависит другой пакет.

Информация.
Чтобы узнать, установлен ли некий пакет, служит команда
rpm -q (Query). Ей также указывается имя пакета, а она
выдает его полное имя, если он установлен. Примеры:

bobby:~# rpm -q lynx
lynx-2.8.1-5
bobby:~# rpm -q seyon
package seyon is not installed
bobby:~# _

Маленькие и заглавные буквы в именах пакетов различаются. Поскольку
часто не помнишь точное имя пакета (и уж тем более, какие буквы там на
каком регистре), можно воспользоваться командой rpm -qa
(Query All packages — показать все пакеты) в сочетании с командой
grep:

bobby:~# rpm -qa | grep -i after
AfterStep-1.5-0.7
AfterStep-APPS-1.5-0.3
bobby:~# _

<< Предыдущий раздел | /\  | >> Следующий раздел

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

ПРОВЕРКА ЦИФРОВОЙ ПОДПИСИ И ДАЙДЖЕСТА

Общая
форма
команд rpm по
работе с
цифровой
подписью
приведена
ниже

rpm —import PUBKEY …

rpm {—checksig} [—nosignature]
[—nodigest] PACKAGE_FILE …

Опция —checksig
проверяет
все
дайджесты
и подписи,
содержащиеся
в PACKAGE_FILE для
проверки
целостности
и
происхождения
пакета.
Обратите
внимание,
что
подписи
теперь
проверяются
при каждом
чтении
пакета и
опция —checksig
полезна
для
проверки
всех
дайджестов
и подписей,
ассоциированных
с пакетом. Цифровые
подписи не
могут быть
проверены
без
публичных
ключей.
Публичный
ключ в ASCII
формате
может быть
добавлен в
базу
данных rpm
при
использовании
команды —import.
Импортированный
публичный
ключ
заносится
в
заголовок
и
управление
ключами
проводится
аналогично
управлению
пакетами.
Например,
все
импортированные
ключи
можно
просмотреть
при
помощи:

Цифровые
подписи не
могут быть
проверены
без
публичных
ключей.
Публичный
ключ в ASCII
формате
может быть
добавлен в
базу
данных rpm
при
использовании
команды —import.
Импортированный
публичный
ключ
заносится
в
заголовок
и
управление
ключами
проводится
аналогично
управлению
пакетами.
Например,
все
импортированные
ключи
можно
просмотреть
при
помощи:

rpm -qa gpg-pubkey*

Подробная
информация
о
конкретном
публичном
ключе
после
импорта
может быть
отображена
при
запросе.
Информация
о ключе Red Hat GPG/DSA:

rpm -qi gpg-pubkey-db42a60e

Наконец,
публичный
ключ может
быть
удален
после его
импорта
также как
пакет.
Удаление
ключа Red Hat GPG/DSA:

Synopsis

Querying and Verifying Packages:

rpm {-q|—query} [select-options] [query-options]

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

rpm —import PUBKEY …

rpm {-K|—checksig} [—nosignature] [—nodigest] PACKAGE_FILE …

Installing, Upgrading, and Removing Packages:

rpm {-i|—install} [install-options] PACKAGE_FILE …

rpm {-U|—upgrade} [install-options] PACKAGE_FILE …

rpm {-F|—freshen} [install-options] PACKAGE_FILE …

rpm {-e|—erase} [—allmatches] [—nodeps] [—noscripts] [—notriggers] [—test]
PACKAGE_NAME …

Miscellaneous:

rpm {—initdb|—rebuilddb}

rpm {—addsign|—resign} PACKAGE_FILE…

rpm {—querytags|—showrc}

rpm {—setperms|—setugids} PACKAGE_NAME …

select-options

[PACKAGE_NAME] [-a,—all] [-f,—file FILE]
[-g,—group GROUP] {-p,—package PACKAGE_FILE]
[—fileid ID] [—hdrid SHA1] [—pkgid MD5] [—tid TID]
[—querybynumber HDRNUM] [—triggeredby PACKAGE_NAME]
[—whatprovides CAPABILITY] [—whatrequires CAPABILITY]

query-options

[—changelog] [-c,—configfiles] [-d,—docfiles] [—dump]
[—filesbypkg] [-i,—info] [—last] [-l,—list]
[—provides] [—qf,—queryformat QUERYFMT]
[-R,—requires] [—scripts] [-s,—state]
[—triggers,—triggerscripts]

verify-options

[—nodeps] [—nofiles] [—noscripts]
[—nodigest] [—nosignature]
[—nolinkto] [—nofiledigest] [—nosize] [—nouser]
[—nogroup] [—nomtime] [—nomode] [—nordev]
[—nocaps]

install-options

[—aid] [—allfiles] [—badreloc] [—excludepath OLDPATH]
[—excludedocs] [—force] [-h,—hash]
[—ignoresize] [—ignorearch] [—ignoreos]
[—includedocs] [—justdb] [—nodeps]
[—nodigest] [—nosignature] [—nosuggest]
[—noorder] [—noscripts] [—notriggers]
[—oldpackage] [—percent] [—prefix NEWPATH]
[—relocate OLDPATH=NEWPATH]
[—replacefiles] [—replacepkgs]
[—test]

6.9 Построение пакета

Дерево директорий исходных текстов

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

Построение пакета с помощью RPM

• обозначает просто запуск раздела spec-файла.
• это проверка списка, который делает некоторые проверки раздела .
• выполняет раздел prep и компиляцию. Это полезно в случае, когда вы не уверены будут ли ваши исходные тексты построены. Это выглядит бесполезно, потому-что вы можете захотеть просто самому поиграть с исходными текстами до их построения и затем начать использовать RPM, но когда вы привыкнете использовать RPM вы найдете случаи когда этот ключ используется.
• выполняет prep, компиляцию и установку.
• выполняет prep, компиляцию, установку, и построения двоичного пакета.
• строит все (и двоичный пакет и пакет с исходными текстами).

• будет пропускать действия до указанной стадии (может использоваться с ключами и ).
• удаляет дерево построения когда все сделано.
• будет сохранять все временные файлы и скрипты, которые созданы в . Вы можете в действительности посмотреть какие файлы созданы в директории используя опцию .
• не выполняет никакую реальную стадию, но делает keep-temp.

Сертификат от Let’s Encrypt

Пока у нас свой сертификат и это не красиво, так что получим сертификат от Let’s Encrypt:

При ответе на вопросы, выбираем использование rewrite для перенаправления всех на https. В результате в файле изменяться строки у VirtualHost для http:

и у VirtualHost для https:

Строку закомментируем.

Тут стоит напомнить о необходимости добавить файл с параметрами Диффи-Хеллмана в конец сертификата:

И изменить заголовок HKPK (HTTP Public Key Pinning):

И изменим соответственно строку в конфигурации:

Проверим конфигурацию и перечитаем конфигурацию:

Есть еще одна проблема. Для обновления сертификата добавим запись в крон:

Но этого не достаточно, нужно еще дописать автоматическое добавление файла с параметрами Диффи-Хеллмана и параметры HKPK (HTTP Public Key Pinning).

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

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

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

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

и т.д.

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

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

Зачем нужен rpm

Как уже упоминалось в разделе «Добавление и
удаление пакетов», rpm (Redhat Package Manager) служит
для работы с пакетами — установка, удаление, проверка и т.д.

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

Такой подход к установке ПО имеет несколько достоинств, в частности:

• Унифицированная работа с разными пакетами (в частности, не надо
  помнить, куда какая-либо программа положила при инсталляции свои
  файлы — постоянная головная боль в Dos/Windows).

• Отслеживание зависимостей между пакетами выполняется автоматически
  (не надо помнить, что программа такая-то требует некоей библиотеки с
  версией не ниже какой-то — сравните с вечными проблемами, к примеру, с
  DirectX в Windows).

• Непротиворечивость между разными пакетами — в частности, корректно
  «разводится» ситуация, когда несколько пакетов содержат один и тот же
  файл (например, в /etc/).

Проверка

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

Команда rpm -V выполняет проверку пакета. Вы можете использовать любой из перечисленных Параметров выбора пакета, для указания пакетов, которые вы хотите проверить. Простым примером выполнения проверки является команда rpm -V foo, которая проверяет, что все в файлы в пакете foo находятся там, куда они были первоначально установлены. Например:

• Чтобы проверить пакет, содержащий конкретный файл, выполните:

  rpm -Vf /bin/vi

• Чтобы проверить ВСЕ установленные пакеты:

  rpm -Va

• Чтобы сравнить установленный пакет с файлом пакета RPM:

  rpm -Vp foo-1.0-1.i386.rpm

  Эта команда может быть полезно, если вы сомневаетесь в целостности баз данных RPM.

Если проверка проходит успешно, никакие сообщения на экране не появятся. В случае обнаружения каких-либо нарушений, вы увидите сообщения об этом. Для каждого несоответствия на экран будет выведена строка из восьми символов ( c обозначает файл конфигурации), а затем имя файла. Каждый из восьми символов обозначает результат сравнения одного атрибута файла со значением атрибута, записанного в базе данных RPM. Одна . (точка) означает, что тест пройден. Следующие символы обозначают ошибки при выполнении определённых проверок:

• 5 — контрольная сумма MD5

• S — размер

• L — символическая ссылка

• T — дата изменения файла

• D — устройство

• U — пользователь

• G — группа

• M — режим (включая разрешения и тип файла)

• ? — файл не удалось прочитать

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

Запрос пакетов RPM

Опция -q указывает команде rpm выполнить запрос.

Чтобы запросить (выполнить поиск), установлен ли определенный пакет, передайте имя пакета в rpm команду -q. Следующая команда покажет вам, установлен ли в системе пакет OpenJDK 11:

sudo rpm -q java-11-openjdk-devel

Если пакет установлен, вы увидите что-то вроде этого:

java-11-openjdk-devel-11.0.4.11-0.el8_0.x86_64

Укажите параметр -i чтобы получить больше информации о запрашиваемом пакете:

sudo rpm -qi java-11-openjdk-devel

Чтобы получить список всех файлов в установленном пакете RPM:

sudo rpm -ql package

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

sudo rpm -qf /path/to/file

Чтобы получить список всех установленных пакетов в вашей системе, используйте опцию -a:

sudo rpm -qa