Сборка RPM пакета[править]
Для сборки пакетов(SRPM и RPM) необходимо наличие исходных файлов и файла-конфигурации, подробнее о том, что нужно для сборки пакетов
Структура команды для сборки пакета с исходниками(SRPM): mock —buildsrpm {—spec spec —sources src —symlink-dereference | —scm-enable}
Чтобы собрать пакет с исходниками(SRPM), на основе которого потом будет собираться бинарный пакет(RPM) с помощью утилиты mock, необходимо выполнить команду:
$ mock -r <имя_файла_конфигурации> --buildsrpm --spec=путь/к/spec_файлу.spec --sources=путь/к/исходникам --resultdir=место/куда/должен/собраться/SRPM_пакет
-r — опция, которая использует конфигурацию chroot, как определено в файле /etc/mock/<confug>.cfg
После сборки SRPM необходимо собрать бинарный пакет(RPM) с помощью команды:
$ mock --rebuild путь/к/пакету_SRPM.src.rpm --resultdir=место/куда/должен/собраться/RPM_пакет
Если в обеих командах не указывать —resultdir=, то пакеты установятся в папку /mock/../result
Сборка из исходников
Рассмотрим пример создания 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 — архитектура пакета.
Step 1: Download RPM Installation File
Typically, a web browser is used to locate and download a .rpm file. However, if a browser is not available you can still download a file if you know where it’s located.
You may need to install a software tool called .
To install in CentOS, enter the following in a terminal window:
To install in Fedora, enter the following:
Now, you can use the command to download the .rpm file you want. Enter the following:
The system should reach out to the website and download the file to your current working directory.
Note: You can look up the address of a particular .rpm file in a web browser on another system. Also, this is a handy way to install more recent software versions or special non-standard software. Also, take care when installing software packages! Make sure you trust the source before you install. Usually, a developer will include a verification method to make sure you’re getting authentic software.
Установка пакетов RPM с помощью yum
— это инструмент менеджера пакетов по умолчанию в CentOS. Он используется для установки, удаления, загрузки, запроса и обновления пакетов из официальных репозиториев CentOS, а также других сторонних репозиториев.
Первым шагом является загрузка файла RPM, который вы хотите установить:
Чтобы установить пакет, используйте команду пути к имени пакета:
запросит подтверждение. Ответьте и пакет RPM будет установлен при условии, что он совместим с вашей системой и соблюдены все зависимости.
Если пакет RPM зависит от других пакетов, которые в данный момент не установлены, и если эти пакеты доступны в репозиториях, включенных в вашей системе, установит все зависимости. В противном случае напечатает список всех недостающих зависимостей, которые вам нужно будет загрузить и установить вручную.
Вместо загрузки и последующей установки пакета RPM вы можете просто передать URL-адрес пакета RPM команде :
Чтобы обновить пакет RPM, который уже установлен с помощью yum, используйте ту же процедуру, что и при установке пакета.
Если по какой-то причине вы хотите удалить установленный пакет, используйте стандартную команду за которой следует имя пакета:
Добавление репозитория REMI
Установка репозитория REMI происходит в несколько этапов. Для выполнения команды, у вас должна быть установлена утилита wget.
yum install wget -y
# Скачиваем rpm-пакет, при помощи утилиты wget wget http://remi.mirror.ate.info/enterprise/remi-release-7.rpm 2016-09-22 04:48:28 (5.43 MB/s) - ‘remi-release-7.rpm’ saved [8147/8147] # файл пакета, ‘remi-release-7.rpm’ будет сохранен в ту директорию # в которой вы находитесь в данный момент, если вы root, то /root/remi-release-7.rpm # Устанавливаем репозиторий: rpm -Uvh remi-release-7.rpm
Существуют и другие репозитории, процесс их установки будет таким же. Все нужные ссылки, как правило, указываются на страничке проектов, так же как и инструкции по установке.
Установка пакетов RPM с помощью rpm
— это инструмент низкого уровня, который используется для установки, удаления, обновления, запроса и проверки пакетов RPM.
Чтобы установить пакет RPM, используйте команду за которой следует имя пакета RPM:
Параметр указывает отображать подробный вывод, а — отображать индикатор выполнения, отмеченный хешем.
Если пакет зависит от других пакетов, которые не установлены в системе, отобразит список всех недостающих зависимостей. Вам придется скачать и установить все зависимости вручную.
Вместо загрузки и установки пакета RPM вы можете использовать URL-адрес пакета RPM в качестве аргумента:
Чтобы обновить пакет, используйте параметр :
Если пакет, который вы пытаетесь обновить, не установлен, команда установит его.
Чтобы установить пакет RPM без установки всех необходимых зависимостей в системе, используйте параметр :
Чтобы удалить (стереть) пакет, используйте команду , за которой следует имя пакета:
Подготовка системы
Для работы по сборке пакетов лучше использовать отдельный компьютер, виртуальную машину или контейнер Docker.
1. Установим пакеты:
yum install rpmdevtools rpmlint
* где:
- rpmdevtools — позволит нам использовать утилиту rpmdev-setuptree, с помощью которой мы сможем создать рабочую среду в виде каталогов для сборки.
- rpmlint — позволяет протестировать пакет RPM.
А также ставим:
yum group install «Development Tools»
* данная группа пакетов включает все необходимое для сборки. Ее не рекомендуется ставить на рабочий компьютер, так как устанавливается много ненужного для стандартной системы мусора.
2. Создаем пользователя.
Делать готовые установочные сборки пакетов очень опасно от пользователя root. Если мы допустим ошибку с путями, файлы могут перетереть или удалить важные для работы директории. Стоит создать отдельного пользователя и работать под ним. Однако, если мы работаем в виртуальной среде или контейнере Docker, нам это не страшно. Тогда данный пункт можно пропустить и работать из под root.
Выполняем команду:
useradd builder -m
* в данном примере мы создадим пользователя builder. Опция -m сразу создаст домашний каталог для пользователя.
Теперь заходим под данным пользователем — последующие команды мы будем выполнять от него:
su — builder
3. Создадим структуру каталогов для сборки:
rpmdev-setuptree
В нашей текущем каталоге должна появиться папка rpmbuild — а в ней:
- BUILD — содержит все файлы, которые появляются при создании пакета.
- RPMS — сюда будут складываться готовые пакеты.
- SOURCES — для исходников, из которых и будут собираться RPM-пакеты.
- SPECS — для файлов с описанием процесса сборки.
- SRPMS — для исходников RPM-файлов.
Мы готовы к сборке.
Общая информация
В одной из статей уже рассматривалось использование пакетного менеджера Yum в операционной системе CentOS. Сейчас же разберемся с репозиториями, которые являются неотъемлемой частью инфраструктуры управления пакетами.
Репозиторий представляет собой централизованное хранилище скомпилированных и готовых к установке программ с метаданными об их совместимости и взаимозависимостях. Репозитории бывают:
- официальные — поддерживаемые разработчиками дистрибутива ОС. Содержат пакеты, являющиеся частью операционной системы, а также дополнительные программы, тесно в нее интегрированные;
- коммерческие — поддерживаемые разработчиками стороннего платного программного обеспечения. Доступ к таким репозиториям обычно требует наличия подписки;
- открытые — поддерживаемые энтузиастами, сообществом или разработчиками свободно-распространяемого ПО. Открыты для всех желающих.
Так как перечень программного обеспечения, включенного в состав операционной системы ограничен, и разработчики не всегда успевают вовремя тестировать и включать в свои репозитории свежие версии сторонних проектов (веб-серверы, почтовые серверы, СУБД и т.д.), зачастую приходится подключать дополнительные репозитории.
Есть два основных способа подключения. Наиболее предпочтительный — установка RPM-пакета репозитория. В ходе этой операции скачиваются и создаются все необходимые файлы, после чего новый репозиторий появится в списке подключенных (команда yum repolist). Другой способ — создать файл настроек репозитория самостоятельно в каталоге /etc/yum.repos.d/. Файл должен иметь расширение repo и содержать следующие параметры:
Описание параметров:
— краткое имя репозитория;name — полное имя репозитория;baseurl — ссылка на репозиторий (может быть заменена параметром mirrorlist или metalink — ссылка на список региональных зеркал репозитория);gpgcheck — проводить ли проверку цифровой подписи пакетов (если значение параметра 1 — проводить, если 0 — не проводить);gpgkey — местоположение открытого ключа репозитория, с помощью которого производится проверка подписи;enabled — используется ли репозиторий при поиске и установке пакетов (1 — используется, 0 — репозиторий отключен).
Все необходимые значения для указанных параметров обычно можно найти на веб-сайте соответствующего репозитория.
Написание .gear/rules[править]
Забегая вперёд, создайте правило для Gear:
echo "tar.gz: targetTag:hello" > .gear/rules git commit -m "Gear rules inserted." .gear/rules
Здесь ‘targetTag’ — некое, пока ещё «волшебное», имя. Это имя будет символизировать какой код, из какой ветки Вы хотите собрать и упаковать в RPM. Есть рекомендации составлять это имя из версии программы и номера сборки. Например: 0.0.1-alt4. Т.е. 0.0.1 — версия программы, alt4 — четвёртая сборка этой версии для ALT Linux. Я здесь выбираю это имя равным ‘targetTag’.
‘hello’ — это имя каталога, в котором будет находиться программный код внутри репозитория. Оно соответствует имени собираемого пакета. Код из этого каталога будет собран и упакован в пакеты.
Получение и пересборка пакета, не будучи при этом root-ом
Иногда вам просто необходимо пересобрать определенный пакет — возможно, лишь добавить конфигурационные опции, которые просто не существуют в основном пакете. Или потому, что вы нашли необходимый пакет, который отсутствует в репозитории, а на сайте разработчика RPMs для другого дистрибутива. Таким образом, вы должны получить src.rpm и востановить его под себя. Но в действительности вы не хотите делать этого в качестве суперпользователя. Итак, как пересобрать свои пакеты в вашей домашней директории под собственной учетной записью.
13.1 Метод А
Для начало необходимо настроить каталог для работы. Он имеет довольно полное сходство по структуре с каталогом /usr/src/redhat:
$ cd
$ mkdir -p redhat/{SRPMS,RPMS,SPECS,BUILD,SOURCES}
$ ls redhat/
BUILD RPMS SOURCES SPECS SRPMS
$
С помощью rpm макроса произведем подмену, для того чтобы rpmbuild узнал о нас и о том что нужно собрать:
$ echo "%_topdir /home/testuser/redhat" >> .rpmmacros $ echo "%packager Test User " >> .rpmmacros $ cat .rpmmacros %_topdir /home/testuser/redhat %packager Test User $
Именно так. Следующее действие — задание rpmbuild-у —rebuild foo.src.rpm, результат работы будет в файле ~/redhat/RPMS/i386 (или та архитектура с которой вы строили пакет).
13.2 Метод Б
Для CentOS-4, настроить репозиторий kbs-Extras repo (опционально добавить kbs-Misk) со страницы репозиториев и ‘yum install fedora-rpmdevtools’ под root-ом используя ‘sudo’ или ‘su -‘. Завести юзера (возможно вы захотите использовать специальный аккаунт для того, чтобы избежать проблем в своей обычной домашней директории) и выполнить «fedora-buildrpmtree» и ~/rpmbuild/…в дереве каталогов и ~/.rpmmacros файл будет автоматически создан. (Примечание «rpmbuild» против «RedHat» в методе А.)
Для CentOS-5 — пакет rpmdevtools отсутствует в наличии. В FC6 SRPM rpmdevtools-5.3-1.fc6.src.rpm собирается и работает.
Ниже представлен макрос для получения надлежащих имен некоторых пакетов (замените соответствующую версию дистрибутива для «el4» на свою):
$ echo "%dist .el4" >> .rpmmacros
Подготовка
При установке пакетов RPM убедитесь, что они созданы для вашей системной архитектуры и вашей версии CentOS .
Вам следует избегать использования этого метода для замены или обновления важных системных пакетов, таких как glibc, systemd или других служб и библиотек, которые необходимы для правильного функционирования вашей системы. Это может привести к ошибкам и нестабильности системы.
Чтобы установить пакеты RPM, вам необходимо войти в систему как пользователь root или пользователь с привилегиями sudo .
Обычно вы используете веб-браузер для поиска и загрузки файла RPM. Найдя файл, вы можете загрузить его с помощью браузера или инструмента командной строки, такого как или .
Проверка работы tls 1.3 и brotli в nginx
Запускаем nginx:
# systemctl start nginx
Проверяем версию openssl и наличие brotli модуля:
nginx -V
Для работы нового функционала, добавляем параметры в /etc/nginx/nginx.conf:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:ECDHE:!COMPLEMENTOFDEFAULT; ssl_prefer_server_ciphers on; ssl_stapling on; add_header Strict-Transport-Security max-age=15768000; brotli_static on; brotli on; brotli_comp_level 6; brotli_types text/plain text/css text/xml application/javascript image/x-icon image/svg+xml;
Обращаю внимание на настройки nginx. Если у вас в виртуальных хостах стоят разные настройки ssl, то могут возникнуть проблемы с работой tls 1.3
Изначально я тестировал все на отдельном виртуальном хосте, а остальные не трогал. Но у меня ничего не работало. Какие бы настройки ssl я не ставил, tls 1.3 не работал, только 1.2. Что я только не перепробовал — раз 10 пересобирал nginx с разными параметрами и версиями openssl.
Заработало все только после того, как я у всех виртуальных хостов убрал настройки ssl, кроме путей до сертификатов, и прописал глобальные настройки для всех в nginx.conf. После этого tls 1.3 заработал.
Проверяем конфигурацию на ошибки и перезапускаем nginx:
# nginx -t # nginx -s reload
Открываем тестовый сайт в последней версии chrome и проверяем с помощью dev tools.
Сравните с остальными сайтами. Сжатие в основном будет gzip, а версия tls -1.2. А мы теперь молодцы, на острие прогресса — у нас все самое новое.
Обращаю внимание на то, что проверять нужно в свежей версии браузера. Не все еще поддерживают работу с tls 1.3
К примеру, на момент написания статьи Сhrome уже поддерживал, а Яндекс.Браузер нет.
Добавление репозитория EPEL
EPEL — самый простой в установке репозиторий. Epel-release package включен в стандартный Extras repository и доступен по умолчанию. Для его установки достаточно выполнить команду:
yum install epel-release -y
В процессе установки будет создан файл «epel.repo», который будет содержать все данные для работы с репозиторием. Выполним команду выводящую содержимое файла.
cat /etc/yum.repos.d/epel.repo name=Extra Packages for Enterprise Linux 7 - $basearch #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch failovermethod=priority enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 name=Extra Packages for Enterprise Linux 7 - $basearch - Debug #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch/debug mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch failovermethod=priority enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 gpgcheck=1 name=Extra Packages for Enterprise Linux 7 - $basearch - Source #baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch failovermethod=priority enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 gpgcheck=1
Подписываем пакет
Установим на созданный файл цифровую подпись, чтобы можно было гарантировать на целевом для установки компьютере, что пакет собрали именно мы. Не все нижеописанные действия можно выполнять от пользователя 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
Проверка целостности 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’ку с ним, а она как раз и не сохранилась. Также может захотеться собрать по быстрому пакет с изменёнными под ваши нужды конфигурационными файлами.
Для решения этой проблемы следует воспользоваться утилитой rpmrebuild. Эта написанная на bash утилита доступна в contrib-репозитории РОСЫ.
Работать с ней крайне просто. Нужно отдать всего лишь команду:
Если какой-либо файл был изменён, то вам об этом сообщат, но процесс сборки не прервётся.
Rpmrebuild обладает огромным количеством параметров, например, вы можете изменять release пакета, changelog, скрипты, секции Requires, описания пакета и многое другое. Можете даже просто напросто изменить spec-файл, который скрипт сгенерирует сам. Он правда будет немного страшный, но это все же лучше, чем ничего.
Все параметры можно посмотреть при помощи
и
Подготовка репозитория Git[править]
Создание репозиторияправить
Создайте каталог, где будет находиться репозиторий с программой, создайте сам репозиторий:
mkdir ~/hello-git # Каталог-корень GIT репозитория. cd ~/hello-git git init
Далее, если не оговорено иного (в т.ч. через cd и т.п.) и нет ошибки, предполагается, что команды отдаются внутри каталога ‘~/hello-git’.
Создание ветокправить
Совсем необязательно, но удобно, когда оригинальный программный код расположен в отдельной ветке репозитория. Тогда код, в который вносятся изменения, файлы необходимые для сборки RPM пакета располагаются в своих, отдельных ветках. Если в этом нет нужды, то всё касающееся веток, дополнительных к ‘master’, можно пропускать, избирательно.
Например, можно сделать вот такие ветки:
- master — здесь будут находится служебные файлы, используемые при сборке RPM пакета: Spec файлы, файлы Gear (.gear/, и прочее). Программный код может быть, а может и не быть в этой ветке. По выбору собирающего пакет.
- upstream — оригинальный, авторский, распакованный программный код, как он был предоставлен. Этот код будет хранится в этой ветке неизменным.
- devel — ветка, в которую будет скопирован авторский код. Если потребуется вносить изменения в программу, то изменения будут внесены именно в этой ветке.
Наполнение репозиторияправить
Создайте необходимые ветки и заготовки файлов:
mkdir ~/hello-git/hello # Каталог под исходный код программы. mkdir ~/hello-git/.gear touch ~/hello-git/.gear/rules touch ~/hello-git/hello.spec git add ~/hello-git/.gear/rules ~/hello-git/hello.spec git commit -a -m "Initial." git branch upstream git branch devel
Можно проверить, что получилось:
git branch git status
GIT сообщает, что текущая(активная) ветка ‘master’ (помечена ‘*’ в выводе первой команды), что в отслеживаемых файлах нет изменений (вторая команда; она же — тоже указано имя текущей ветки).
Приложения[править]
Файл apt.conf для песочницыправить
Dir::Etc::main "/dev/null"; Dir::Etc::parts "/var/empty"; Dir::Etc::sourcelist "/directorySandbox/sources.list"; Dir::Etc::pkgpriorities "/directorySandbox/priorities"; Dir::Etc::sourceparts "/var/empty"; APT::Cache-Limit "67108864";
Файл sources.list для песочницыправить
В разных окружениях этот файл может быть разным. См. ‘/etc/apt/sources.list’ как пример. См. ‘man sources.list’, можно скопировать из ‘/etc/apt/sources.list.d/alt.list’:
rpm http://ftp.altlinux.org/pub/distributions/ALTLinux/p6/branch i586 classic rpm http://ftp.altlinux.org/pub/distributions/ALTLinux/p6/branch noarch classic
Или другой вариант ниже использует существующие локально на диске репозитории:
rpm file:/altair/ALT/Sisyphus i586 classic rpm file:/altair/ALT/Sisyphus noarch classic
Файл compile для песочницыправить
Файл ‘compile’ является скриптом-обёрткой для запуска описанных в статье команд сборки (в т.ч. с указанием архитектуры и т.д.). В каталоге с GIT репозиторием можно создать символическую ссылку на такой файл. Можно создать разноимённые ссылки на файлы-обёртки в разных песочницах и запускать их по мере надобности, не покидая каталог репозитория, без необходимости работы с полными именами файла, из-за местоположения скрипта в другом каталоге.
#!/bin/bash
#
# Alex Vesev @ ALT Linux, 2012-10-05
#
##
declare -r maintainerName="Not Shure"
declare -r maintainerMail="not.shure@localhost"
declare -r dirSandBoxTop="${HOME}/hsh-sandboxes/p6-hello-i586"
declare -r dirSandBoxHasher="${dirSandBoxTop}/hasher"
declare -r optDirRepoHasher="--repo=\"${dirSandBoxTop}/repo/...\"" # XXX - применение не реализовано.
declare -r archTarget="i586"
declare -r argNoCheck="--no-sisyphus-check"
function showDoc {
cat "${}"
}
"${#}" == \
&& showDoc \
&& exit 1
cliArgument="${1}"
cliOptionName="${cliArgument%%=*}"
cliOptionName="${cliOptionName#--}"
cliOptionValue="${cliArgument#*=}"
case "${cliOptionName}" in
shell|sh)
hsh-shell --mountpoints="/proc" "${dirSandBoxHasher}"
;;
build|bu)
gear \
--verbose \
--commit \
--hasher \
-- ${archTarget} \
hsh \
--verbose \
--nprocs=2 \
--packager="${maintainerName} <${maintainerMail}>" \
${argNoCheck} \
--target=${archTarget} \
--lazy-cleanup \
--mountpoints="/proc,/dev/pts,/sys" \
--apt-config="${dirSandBoxTop}/apt.conf" \
"${dirSandBoxHasher}"
;;
rebuild|reb|rebu)
gear \
--verbose \
--commit \
--hasher \
-- ${archTarget} \
hsh-rebuild \
--verbose \
${argNoCheck} \
--target=${archTarget} \
--mountpoints="/proc,/dev/pts,/sys" \
"${dirSandBoxHasher}"
;;
install|ins)
shift 1
hsh-install "${dirSandBoxHasher}" "${@}"
;;
clean-all)
hsh --cleanup-only "${dirSandBoxHasher}"
;;
esac
Репозитории в CentOS
Для начала давайте поясним, что такое репозитории и для чего они нужны. Вот что говорит wikipedia на этот счет:
Некоторое время назад Linux приложения выходили в виде исходного кода, который потом компилировали на сервере и получали готовые программы. На сегодняшний день большинство приложений выходят в виде так называемых пакетов. Это уже собранные приложения, которые можно сразу установить и пользоваться.
В нашем случае репозиторий — хранилище пакетов для операционной системы CentOS. Существуют repository от разработчика системы, их называют официальные. Набор rpm пакетов там обычно ограничен и версии не самые свежие. Для установки дополнительного софта используют сторонние репозитории. Их поддерживать могут как другие компании, так и группы энтузиастов.
Управлением пакетами и репозиториями в CentOS занимается утилита yum. Ее конфигурационный файл находится в /etc/yum.conf. Этот файл содержит секцию , в которой указываются глобальные настройки программы. Так же он может содержать одну или несколько секций , в которой хранятся настройки репозиториев. Тем не менее, рекомендуется информацию о репозиториях хранить в каталоге /etc/yum.repos.d/ в специальных файлах .repo.
Минимальное содержание файла .repo следующее:
name=repository_name baseurl=repository_url
| name | имя, описывающее репозиторий, может быть любым |
| baseurl | ссылка на расположение репозитория, может быть в виде http, ftp или file ссылки |
Другие ползные параметры, которые могут быть указаны в repo файле:
| enabled | принимает значение 1 или 0, 1 — репозиторий подключен, 0 — отключен |
| async | управляет загрузкой пакетов, auto — использует при возможности параллельную загрузку, on — использует только параллельную загрузку, off — параллельная загрузка отключена |
| mirrorlist | вместо ссылки на конкретный адрес репозитория может быть указана ссылка на список адресов, из которых при установке будет выбран наиболее подходящий |
| gpgcheck | принимает значение 1 или 0, 1- осуществлять проверку GPG подписи пакета из репозитория, 0 — не проверять |
| gpgkey | ссылка на GPG ключ репозитория |
Вот содержание стандартного файла с репозиториями CentOS /etc/yum.repos.d/CentOS-Base.repo:
name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 #released updates name=CentOS-$releasever - Updates mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 #additional packages that may be useful name=CentOS-$releasever - Extras mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 #additional packages that extend functionality of existing packages name=CentOS-$releasever - Plus mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus gpgcheck=1 enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Конфигурационные файлы репозиториев (*.repo)
Все конфигурационные файлы репозиториев расположены в директории /etc/yum.repos.d/. В конфигурационных файл *.repo. Типовой конфигурационный файл репозитория содержит следующие параметры:
- name — имя репозитория;
- baseurl — ссылка на репозиторий (может быть ftp://address, http://address, https://address или file://address для локального репозитория);
- enabled – нужно ли использовать данный репозиторий: 1 – репозиторий подключен, 0 – отключен;
- async – использовать ли параллельную загрузку пакетов (auto/on/off);
- gpgcheck – нужно ли выполнять проверку GPG (1 – проверять);
- gpgkey — ссылка на GPG ключ;
- exclude — список исключенных пакетов;
- includepkgs — список включенных пакетов;
- mirrorlist – список зеркал репозитория.
В минимальном случае repo файл может выглядеть так:
name=rep_name baseurl=rep_url
Например, после подключения репозитория REMII, в директории репозиториев появится несколько конфигурационных файлов Remi (remi-*.repo).
Как вы видите, Remi имеет отдельный конфигурационный файл для каждой версии php. Вам нужно включить нужную вам версию в конфигурационном файле, например у меня на сервере будет стоять версия php 7.3, для этого я включил именно этот репозиторий (в файле remi-php73.repo указал enabled=1):
Вы можете подключит репозиторий вручную, для этого нужно создать конфигурационный файл репозитория в директории /etc/yum.repos.d/. Подключим репозиторий MaruaDB.
Добавим в него данные, которое нам предоставляет разработчик пакета MariaDB:
name = MariaDB baseurl = http://yum.mariadb.org/10.4/centos73-amd64/ gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1
