Создание RPM пакетов из исходников. Как создать пакет RPM из установленных файлов? Готовим SPEC файл

RPM пакеты имеют собственную структуру, отличную от других. Но зачем создавать свои RPM, если можно просто скомпилировать исходники? Ответ на этот вопрос в рутинной установке, а также помощи разработчикам Fedora или другим дистрибутивам. Устанавливая каждый раз одни и те же программы из исходников, можно написать скрипт для автоматизации этого, однако, если есть RPM, то не надо тратить много времени на установку, также как и необходимая программа будет постоянно доступна онлайн из репозитория (конечно же, если вы ее туда отправите).

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

# yum groupinstall "Development Tools"
# yum install rpmdevtools
На данной стадии происходит установка необходимых утилит и различных библиотек разработчика.

НИКОГДА НЕ СОЗДАВАЙТЕ RPM ОТ ROOT! (это может нарушить работу системы, увеличить возможность взлома и так далее)

После окончания установки, запустите

rpmdev-setuptree
Это приведет к создание ветки директорий
BUILD BUILDROOT RPMS SOURCES SPECS SRPMS

Из всех директорий нас интересует только SOURCES SPECS, информация в остальных, если все сделано верно, сгенерируется автоматически.

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

Сами исходники с патчами или без, копируем в SOURCES.

Когда все готово, запускаем компилирование и создание RPM

rpmbuild -ba ПУТЬ/NAME.spec для создания.src.rpm
rpmbuild -bi ПУТЬ/NAME.spec для создания бинарника или просто.rpm

Для установки и/или тестирования

# rpm -ivh sourcepackage-name*.src.rpm
или
# rpm -ivh package-name*.rpm
Если все сделано правильно, то программа установится с предупреждением, что rpb database изменена сторонней программой (правильно, мы же ее еще не залили на Fedora сервер).

Объяснение часто используемых областей в.spec файле

Name : Базовое имя пакета удовлетворяющее требованиям Packagen Naming Guidelines . После этого, макрос %{name} будет обращаться к данному разделу.

Version : Номер версии, при использовании даты в версии, используйте формат, гг.мм (пример 11.02). %{version} для последующего обращения к данной области.

Release : Должно быть 1%{?dist} , таким образом, число будет увеличиваться каждый раз, когда создается пакет для одной и той же версии дистрибутива.

Summary : Краткое описание пакета.

Group : Существующая группа пакетов, например Applications/Databases.

Чтобы узнать весь список
# less /usr/share/doc/rpm-*/GROUPS
Для документации будет соответственно группа Documentation.

License : Лицензия на программу, обязана быть для открытых исходников, например "GPLv2+" (GPL версии 2 или новее). Для нескольких лицензий используйте "and" или "or" "GPLv2 and BSD". Следует указывать лицензию максимально точно, можно указывать несколько лицензий с помощью "and" и "or", например "GPLv2 and BSD".

Source0 : Ссылка на архив с исходным кодом. Если указана полная ссылка, то одноименный пакет должен быть в папке SOURCES. Если источников исходного кода несколько, то используем Source1 , Source2 и т.д.

Patch0 : Название первого патча для программы, имя файла должно заканчиваться на.patch и лежать в директории ~/rpmbuild/SOURCES. Патчей может быть несколько.

BuildArch : Архитектура программы под определенные процессоры. Для универсальных пакетов "noarch".

BuildRoot : Место, выделенное для компиляции и установки исходников приложения во время выполнения процесса "%install". По стандарту Fedora, будет создана специальная директория в /var/tmp. Более новые версии RPM пропустят это значение и поместят build root в %{_topdir}/BUILDROOT/

BuildRequires : Список необходимых приложений для сборки пакета (через запятую). Автоматически не определяются . Некоторые стандартные приложения могут быть опущены в данном списке. Полный список приложений, которые могут быть пропущены здесь (https://fedoraproject.org/wiki/Packaging/Guidelines).

Requires : Список необходимых приложений для работы после установки (через запятую). В большинстве случаев определяются автоматически rpmbuild .

%description : Описание программы, строки не должны быть длиннее 80 символов.
%prep : Скрипты для подготовки программы, распаковки и подготовки к сборке.
%build : Скрипты для сборки программы, компиляции и подготовки к установке.
%test : Скрипты для тестирования программы, выполняются после %build, но до %install.
%install : Скрипты для установки программы, команды скопируют файлы из "build directory" %{_builddir} (которая находится ~/rpmbuild/BUILD) в директорию buildroot %{buildroot}, которая обычно находится в /var/tmp.
%clean : Инструкции для очистки buildroot, например,
rm -rf %{buildroot}
%files : Список устанавливаемых файлов.
%changelog : Изменения в программе.

Статья подготовлена опираясь на официальный источник от

В данной статье будет подробно описан процесс создание rpm пакетов и организация репозитория. Прошу всех, кому интересна данная тема, пройти под кат.

Я взялся писать крайне подробно, так что Вы можете пролистать очевидные для Вас вещи.

Установка системы
Преднастройка
Подготовка площадки сборки
Собираем Tmux
Собираем fbida
Настройка доступа по ftp
Заключение

Установка системы

Театр начинается с вешалки

Наш сервис начинается с момента установки на него операционной системы. Естественно, что для сборки rpm пакетов мы выбираем rhel дистрибутив. В данном случае, был выбран CentOS 7 .

Скачать CentOS

Создадим директорию, где будет лежать образ и перейдем в нее:

mkdir ~/centos && cd $_

wget https://mirror.yandex.ru/centos/7/isos/x86_64/CentOS-7-x86_64-Everything-1708.iso wget https://mirror.yandex.ru/centos/7/isos/x86_64/sha256sum.txt.asc

или посредством torrent`а с помощью программы aria2 , которую для начала установим:

sudo yum install -y epel-release sudo yum install -y aria2 aria2c https://mirror.yandex.ru/centos/7/isos/x86_64/CentOS-7-x86_64-Everything-1708.torrent cd ~/centos/CentOS-7-x86_64-Everything-1708

Проверить образ

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

Скачаем ключ для CentOS 7:

wget http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-7

Посмотрим на ключ и импортируем его:

gpg --quiet --with-fingerprint RPM-GPG-KEY-CentOS-7 pub 4096R/F4A80EB5 2014-06-23 CentOS-7 Key (CentOS 7 Official Signing Key) Key fingerprint = 6341 AB27 53D7 8A78 A7C2 7BB1 24C6 A8A7 F4A8 0EB5 gpg --import RPM-GPG-KEY-CentOS-7 gpg: key F4A80EB5: public key "CentOS-7 Key (CentOS 7 Official Signing Key) " imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1)

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

gpg --verify sha256sum.txt.asc 2>&1 | grep "Good signature" gpg: Good signature from "CentOS-7 Key (CentOS 7 Official Signing Key) "

Как мы видим - все отлично и теперь можем проверить сам образ на целостность:

sha256sum -c sha256sum.txt.asc 2>&1 | grep OK CentOS-7-x86_64-Everything-1708.iso: OK

Запись образа на носитель

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

Запись образа на диск

Для записи данного образа, нам понадобится двухсторонний DVD. Допустим мы его нашли и записываем, установив предварительно wodim:

sudo yum install -y wodim sudo wodim dev=/dev/cdrom -eject -v CentOS-7-x86_64-Everything-1708.iso

Запись образа на флешку

Двухсторонний DVD это как то архаично, так что возьмем флешку на 16 гб и запишем образ на нее, но прежде /dev/sda тут - это флешка, а у Вас она может быть другой. Смотри команду fdisk:

sudo dd if=CentOS-7-x86_64-Everything-1708.iso of=/dev/sda bs=1M status=progress; sync eject /dev/sda

Если status=progress не поддерживается, то по старинке:

watch -n 10 "sudo kill -USR1 $(pgrep ^dd)"

или вот так:

watch -n 10 "sudo pkill -usr1 dd"

а можно воспользоваться pv:

sudo yum install -y epel-release sudo yum install -y pv sudo su dd if=CentOS-7-x86_64-Everything-1708.iso | pv | dd of=/dev/sda

Установка

Как поставить Centos 7, решать Вам, тут и за RAID подумать можно и за LVM и много чего еще,
я ставил минимальный пакет.

Процесс установки можно посмотреть в этом ролике .

Преднастройка

После установки системы, нам необходимо настроить наш сервер.

Обновление и установка пакетов

В начале мы обновим все установленные пакеты, далее установим репозиторий epel, в котором есть много что полезного для нас:

sudo yum update -y sudo yum install -y epel-release

Следующим шагом установим группу пакетов, которые понадобятся нам для сборки, а так же ряд пакетов необходимые для развёртывания репозитория.

sudo yum groupinstall -y "Development Tools" sudo yum install -y glibc-static tree wget vim createrepo sudo yum install -y httpd httpd-devel mod_ssl python2-certbot-apache vsftpd

SSH

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

Безопаснее пользоваться ключами, по этому мы и создадим себе ключи для доступа к серверу на своем рабочем компьютере:

ssh-keygen

и добавим ключ на сервер:

ssh-copy-id chelaxe@rpmbuild

или ручками:

mkdir ~/.ssh chmod 700 ~/.ssh vim ~/.ssh/authorized_keys ssh-rsa AAAA...tzU= ChelAxe (D.F.H.) chmod 600 ~/.ssh/authorized_keys

Необходимо еще закрутить гайки в самой службе. Создадим копию файла конфигурации и приступим к редактированию:

sudo cp /etc/ssh/sshd_config{,.bak} sudo vim /etc/ssh/sshd_config

В файле стоит добавить/изменить/раскомментировать следующие строки:

# Слушать будем на интерфейсе с адресом 192.168.0.2 ListenAddress 192.168.0.2 # Для авторизации хватит и 30 секунд LoginGraceTime 30 # Запретим подключение root пользователю PermitRootLogin no # Три неудачных попытки хватит MaxAuthTries 3 # Запретить авторизацию по паролю PasswordAuthentication no # Через 10 минут простоя разорвем сессию ClientAliveInterval 600 ClientAliveCountMax 0 # Разрешим вход только пользователю chelaxe AllowUsers chelaxe # Разрешим вход только пользователям из группы chelaxe AllowGroups chelaxe # Заставить sshd работать только с протоколом SSH2 Protocol 2

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

sudo systemctl restart sshd

Межсетевой экран

Важно ограничить доступ к нашему серверу. По этой причине настроим межсетевой экран:

sudo firewall-cmd --permanent --zone=public --remove-service=dhcpv6-client sudo firewall-cmd --permanent --zone=public --remove-service=ssh sudo firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="192.168.0.0/28" service name="ssh" accept" sudo firewall-cmd --permanent --zone=public --add-service=http sudo firewall-cmd --permanent --zone=public --add-service=https sudo firewall-cmd --permanent --zone=public --add-service=ftp sudo firewall-cmd --permanent --list-all public target: default icmp-block-inversion: no interfaces: sources: services: http https ftp ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" source address="192.168.0.0/28" service name="ssh" accept sudo firewall-cmd --reload

Подготовка площадки сборки

Подготовим саму площадку для сборки. Стоит отметить, что вернее всего сборку производить на отдельном виртуальном хосте, активно используя технологию snapshot"ов, но тут я опишу все в едином целом. Так же для сборки нужно выделить отдельного пользователя, не являющемся администратором (т.е. sudo ему недоступно).

Создание директорий

Создаем необходимые директории:

mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS} sudo mkdir /var/www/repo sudo chown -R chelaxe:chelaxe /var/www/repo ln -s /var/www/repo ~/rpmbuild/REPO tree ~/rpmbuild/ /home/chelaxe/rpmbuild/ ├── BUILD ├── BUILDROOT ├── REPO -> /var/www/repo ├── RPMS ├── SOURCES ├── SPECS └── SRPMS 7 directories, 0 files

Настройка PGP подписи

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

Ключ будем использовать свой или если его нет, то создадим. Создавать ключ стоит на своем рабочем компьютере.

Создадим ключ, если его у нас нет:

gpg --gen-key

Нас попросят ответить на ряд вопросов:
тип ключа, выбираем (1) RSA and RSA (default), размер ключа: 4096, срок действия: 6m, наше имя: Alexander F. Mikhaylov, Email: [email protected], комментарий, тут можно указать для чего нам ключ: repo и ждем...

Если вдруг после ответов на все вопросы получим это gpg: cancelled by user , то запускаем команду:

script /dev/null

и повторяем.

Посмотреть ключ:

gpg --fingerprint [email protected] pub 2048R/E6D53D4D 2014-05-07 Key fingerprint = EE2A FF9A 2BE3 318E 9346 A675 8440 3961 E6D5 3D4D uid ChelAxe (D.F.H.)

Сохраняем наш приватный ключ:

gpg --export-secret-keys --armor [email protected] > chelaxe-privkey.asc

Создадим ключ для отзыва:

gpg --output chelaxe-revoke.asc --gen-revoke [email protected]

Экспорт открытого ключа на keyserver:

gpg --keyserver pgp.mit.edu --send-keys E6D53D4D

Теперь ключ можно и импортировать на наш сервер:

gpg --import ~/chelaxe-privkey.asc rm -rf ~/chelaxe-privkey.asc

Смотрим где находится gpg утилита:

which gpg /usr/bin/gpg

и настроем файл для подписи пакетов:

vim ~/.rpmmacros %_signature gpg %_gpg_path /home/chelaxe/.gnupg %_gpg_name ChelAxe %_gpgbin /usr/bin/gpg

Создаем репозиторий

Теперь организуем сам репозиторий.

Создадим директорию, где будем хранить пакеты:

mkdir ~/rpmbuild/REPO/Packages

Экспортируем ключ в репозиторий:

gpg --export -a "ChelAxe" > ~/rpmbuild/REPO/RPM-GPG-KEY-chelaxe

Создаем сам репозиторий и подписываем метаданные:

createrepo ~/rpmbuild/REPO

Пакет для репозитория

Собираем пакет для автоматической установки репозитория в систему.

cd ~/rpmbuild/SOURCES mkdir chelaxe-release && cd $_

Файл репозитория для yum:

vim ~/rpmbuild/SOURCES/chelaxe-release/chelaxe.repo name=ChelAxe Official Repository - $basearch baseurl=https://repo.chelaxe.ru/ enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-chelaxe

Экспортируем ключ для пакета:

gpg --export -a "ChelAxe" > ~/rpmbuild/SOURCES/chelaxe-release/RPM-GPG-KEY-chelaxe

Собираем все в архив:

cd ~/rpmbuild/SOURCES tar -czf chelaxe-release.tar.gz chelaxe-release/

Создаем SPECS файл для пакета:

cd ~/rpmbuild/SPECS vim ~/rpmbuild/SPECS/chelaxe-release.spec Name: chelaxe-release Version: 1.0 Release: 1%{?dist} Summary: ChelAxe repository configuration Vendor: D.F.H. Packager: ChelAxe Group: System Environment/Base License: GPL URL: https://repo.chelaxe.ru Source0: https://repo.chelaxe.ru/%{name}.tar.gz BuildArch: noarch %description This package contains the ChelAxe official repository GPG key as well as configuration for yum. %prep %setup -q -n %{name} %install %__rm -rf %{buildroot} install -d -m 755 %{buildroot}%{_sysconfdir}/yum.repos.d install -p -m 644 chelaxe.repo %{buildroot}%{_sysconfdir}/yum.repos.d/chelaxe.repo install -d -m 755 %{buildroot}%{_sysconfdir}/pki/rpm-gpg install -p -m 644 RPM-GPG-KEY-chelaxe %{buildroot}%{_sysconfdir}/pki/rpm-gpg/RPM-GPG-KEY-chelaxe %post rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-chelaxe %clean %__rm -rf %{buildroot} %files %defattr(-,root,root,-) %{_sysconfdir}/yum.repos.d/chelaxe.repo %{_sysconfdir}/pki/rpm-gpg/RPM-GPG-KEY-chelaxe %changelog * Tue May 1 2018 ChelAxe (D.F.H.) - 1.0-1%{?dist} - Initial package.

Собираем пакет:

rpmbuild -ba --sign ~/rpmbuild/SPECS/chelaxe-release.spec

На этом этапе нас спросят пароль от нашего PGP ключа.

Копируем созданный пакет в репозиторий и обновляем его:

cp ~/rpmbuild/RPMS/noarch/chelaxe-release-1.0-1.el7.centos.noarch.rpm ~/rpmbuild/REPO/ createrepo --update ~/rpmbuild/REPO

gpg --detach-sign --armor ~/rpmbuild/REPO/repodata/repomd.xml

Теперь установим наш репозиторий в систему:

sudo yum install -y ~/rpmbuild/REPO/chelaxe-release-1.0-1.el7.centos.noarch.rpm

В дальнейшем данный пакет будет доступен по адресу: https://repo.chelaxe.ru/chelaxe-release-1.0-1.el7.centos.noarch.rpm

После установки должен появиться репозиторий chelaxe и PGP ключ:

rpm -q gpg-pubkey --qf "%{name}-%{version}-%{release} --> %{summary}\n" | grep ChelAxe gpg-pubkey-e6d53d4d-5369c520 --> gpg(ChelAxe (D.F.H.) )

Самое важное тут это SPEC файлы, расписывать о них не стану, но предоставлю ряд ссылок:

и одна полезная команда:

rpm --showrc

она отобразит готовые макросы для сборки.

Собираем Tmux

Теперь соберем, для примера, что нибудь полезное. Собирать будем tmux - терминальный мультиплексор, без которого работать мне не комфортно. Стоит отметить tmux есть в base репозитории CentOS 7, но версия там 1.8, а мы соберем 2.7. Так же у пакета из base репозитория есть зависимость libevent, мы же соберем tmux со статическими библиотеками последних версий.

Готовим исходники

Скачиваем исходники tmux и необходимых библиотек:

cd ~/rpmbuild/SOURCES wget https://github.com/tmux/tmux/releases/download/2.7/tmux-2.7.tar.gz wget https://github.com/libevent/libevent/releases/download/release-2.1.8-stable/libevent-2.1.8-stable.tar.gz wget https://github.com/libevent/libevent/releases/download/release-2.1.8-stable/libevent-2.1.8-stable.tar.gz.asc wget ftp://ftp.gnu.org/gnu/ncurses/ncurses-6.1.tar.gz wget ftp://ftp.gnu.org/gnu/ncurses/ncurses-6.1.tar.gz.sig

gpg --recv-keys 8EF8686D gpg --recv-keys F7E48EDB

Проверяем файлы:

gpg --verify libevent-2.1.8-stable.tar.gz.asc libevent-2.1.8-stable.tar.gz 2>&1 | grep "Good signature" gpg: Good signature from "Azat Khuzhin " gpg --verify ncurses-6.1.tar.gz.sig ncurses-6.1.tar.gz 2>&1 | grep "Good signature" gpg: Good signature from "Thomas Dickey "

Подготовим файл конфигурации tmux:

vim ~/rpmbuild/SOURCES/tmux.conf # Доступные параметры сервера: # Количество буферов set-option -g buffer-limit 50 # Массив пользовательских псевдонимов для команд set-option -g command-alias zoom="resize-pane -Z" # Терминал по умолчанию set-option -g default-terminal "screen-256color" # Ожидание после ввода escape set-option -g escape-time 500 # Отключать сервер без активности set-option -g exit-empty off # Отключать сервер без клиентов set-option -g exit-unattached off # Запрос фокусировки у терминала set-option -g focus-events off # Файл в котором хранится история команд set-option -g history-file ~/.tmux_history # Количество сообщений в журнале для каждого клиента set-option -g message-limit 100 # Устанавливать содержимое терминального буфера обмена с помощью escape set-option -g set-clipboard on # Массив описаний терминалов set-option -g terminal-overrides "xterm:colors=256" set-option -g terminal-overrides "xterm*:colors=256" set-option -g terminal-overrides "screen:colors=256" set-option -g terminal-overrides "screen*:colors=256" # Пользовательские сочетания клавиш # set-option -g user-keys "\e#{?session_many_attached,*,} #{version} # # " # Размер левой части строки состояния set-option -g status-left-length 20 # Стиль левой части строки состояния # Заменяет параметры: status-left-attr status-left-bg status-left-fg set-option -g status-left-style "default" # Позиция строки состояния set-option -g status-position bottom # Формат правой части строки состояния set-option -g status-right " # # %a %d %b %Y %H:%M:%S [%V/%j] " # Размер правой части строки состояния set-option -g status-right-length 40 # Стиль правой части строки состояния # Заменяет параметры: status-right-attr status-right-bg status-right-fg set-option -g status-right-style "default" # Стиль строки состояния # Заменяет параметры: status-attr status-bg status-fg set-option -g status-style "bg=green,fg=black" # Массив переменных окружения которые необходимо обновлять set-option -g update-environment "TERMINFO" # Массив пользовательских клавиш # set-option -g user-keys "\e,#{pane_current_command}}#{?pane_dead,,}" # Цвет отображения времени set-option -gw clock-mode-colour "green" # Формат отображения времени set-option -gw clock-mode-style 24 # Предотвращение изменениея размера окна до высоты set-option -gw force-height 0 # Предотвращение изменениея размера окна до ширины set-option -gw force-width 0 # Высота основной панели set-option -gw main-pane-height 24 # Ширина основной панели set-option -gw main-pane-width 80 # Стиль сочетаний клавиш в режиме копирования set-option -gw mode-keys vi # Стиль окона в режиме копирования # Заменяет параметры: mode-attr mode-bg mode-fg set-option -gw mode-style "bg=yellow,fg=black" # Мониторинг активности в окне set-option -gw monitor-activity on # Мониторинг "звонка" в окне set-option -gw monitor-bell on # Мониторинг "тишины" в окне. Время срабатывания. set-option -gw monitor-silence 0 # Высота других панелей set-option -gw other-pane-height 0 # Ширина других панелей set-option -gw other-pane-width 0 # Стиль рамки активной панели # Заменяет параметры: pane-active-border-attr pane-active-border-bg pane-active-border-fg set-option -gw pane-active-border-style "fg=green" # Начало нумерации панелей set-option -gw pane-base-index 1 # Формат строк состояния панелей set-option -gw pane-border-format "#{?pane_active,#,}#{?window_zoomed_flag,#,} #{pane_index}:#{=6:pane_current_command} #" # Положение строк состояния панелей set-option -gw pane-border-status top # Стиль рамки панели # Заменяет параметры: pane-border-attr pane-border-bg pane-border-fg set-option -gw pane-border-style "fg=green" # Не уничтожать окно по завершению программы set-option -gw remain-on-exit off # Синхронизация панелей на ввод с клавиатуры set-option -gw synchronize-panes off # Стиль активной панели set-option -gw window-active-style "default" # Стиль вкладки окна с активностью в строке состояния # Заменяет параметры: window-status-activity-attr window-status-activity-bg window-status-activity-fg set-option -gw window-status-activity-style "fg=red" # Стиль вкладки окна с "звуком" в строке состояния # Заменяет параметры: window-status-bell-attr window-status-bell-bg window-status-bell-fg set-option -gw window-status-bell-style "fg=red" # Формат вкладки текущего окна в строке состояния set-option -gw window-status-current-format " #{window_index}:#{window_name} " # Стиль вкладки текущего окна в строке состояния # Заменяет параметры: window-status-current-attr window-status-current-bg window-status-current-fg set-option -gw window-status-current-style "reverse" # Формат вкладок окон в строке состояния set-option -gw window-status-format " #{window_index}:#{window_name}#{?window_activity_flag,#,}#{?window_bell_flag,!,}#{?window_silence_flag,~,} " # Стиль вкладки предыдущего окна в строке состояния # Заменяет параметры: window-status-last-attr window-status-last-bg window-status-last-fg set-option -gw window-status-last-style "default" # Строка разделяющая вкладки окон в строке состояния set-option -gw window-status-separator "" # Стиль вкладок окон в строке состояния set-option -gw window-status-style "default" # Стиль панелей set-option -gw window-style "default" # Поиск внутри панели set-option -gw wrap-search on # Генерировать сочетания клавиш set-option -gw xterm-keys on # Настройк сочетаний клавиш # Выбор панелей по Alt + стрелки bind-key -rT root M-Up select-pane -U bind-key -rT root M-Down select-pane -D bind-key -rT root M-Left select-pane -L bind-key -rT root M-Right select-pane -R # Переход в режим копирования bind-key -T root M-PageUp copy-mode -eu # Включение синхронизации ввода с клавиатуры bind-key -T prefix M-s set-option -gw synchronize-panes\; display-message "Синхронизация ввода: #{?synchronize-panes,on,off}" # Блокировка сеанса bind-key -T prefix M-l lock-session # Обновление конфигурации bind-key -T prefix M-r source-file /etc/tmux.conf\; display-message "Обновление конфигурации" # Редактирование конфигурации # bind-key -T prefix M-e # Настройка сеанса # Создать сеанс new-session -s "work"

Готовим SPEC файл

Этот файл будет интереснее предыдущего SPEC файла:

cd ~/rpmbuild/SPECS vim ~/rpmbuild/SPECS/tmux.spec %define libevent 2.1.8 %define ncurses 6.1 Name: tmux Version: 2.7 Release: 1%{?dist} Summary: A terminal multiplexer Vendor: D.F.H. Packager: ChelAxe Group: Applications/System License: ISC and BSD URL: https://github.com/%{name}/%{name} Source0: https://github.com/%{name}/%{name}/releases/download/%{version}/%{name}-%{version}.tar.gz Source1: https://github.com/libevent/libevent/releases/download/release-%{libevent}-stable/libevent-%{libevent}-stable.tar.gz Source2: ftp://ftp.gnu.org/gnu/ncurses/ncurses-%{ncurses}.tar.gz Source3: tmux.conf BuildRequires: gcc, gcc-c++, make, glibc-static %description tmux is a "terminal multiplexer", it enables a number of terminals (or windows) to be accessed and controlled from a single terminal. tmux is intended to be a simple, modern, BSD-licensed alternative to programs such as GNU screen. %prep %setup -q -a1 -a2 %build %__mkdir "libs" pushd "libevent-%{libevent}-stable" %_configure \ --prefix="$(pwd)/../libs" \ --disable-shared %__make install popd pushd "ncurses-%{ncurses}" %_configure \ --prefix="$(pwd)/../libs" \ --with-default-terminfo-dir="/usr/share/terminfo" \ --with-terminfo-dirs="/etc/terminfo:/lib/terminfo:/usr/share/terminfo:$HOME/.terminfo" %__make install popd %_configure \ --enable-static \ --prefix="/usr" \ CFLAGS="-Ilibs/include -Ilibs/include/ncurses" \ LDFLAGS="-Llibs/lib -Llibs/include -Llibs/include/ncurses" \ LIBEVENT_CFLAGS="-Ilibs/include" \ LIBEVENT_LIBS="-Llibs/lib -levent" \ LIBNCURSES_CFLAGS="-Ilibs/include" \ LIBNCURSES_LIBS="-Llibs/lib -lncurses" %__make %install %__rm -rf %{buildroot} %make_install install -d -m 755 %{buildroot}%{_sysconfdir} install -p -m 644 %{SOURCE3} %{buildroot}%{_sysconfdir}/tmux.conf %clean %__rm -rf %{buildroot} %files %defattr(-,root,root,-) %doc README TODO CHANGES example_tmux.conf %config(noreplace) %{_sysconfdir}/tmux.conf %{_bindir}/tmux %{_mandir}/man1/tmux.1.gz %changelog * Fri Jun 29 2018 ChelAxe (D.F.H.) - 2.7-1%{?dist} - Rebuild for new version tmux. * Tue May 1 2018 ChelAxe (D.F.H.) - 2.6-1%{?dist} - Initial package.

Сборка

rpmbuild -ba --sign ~/rpmbuild/SPECS/tmux.spec cp ~/rpmbuild/RPMS/x86_64/tmux-2.7-1.el7.centos.x86_64.rpm ~/rpmbuild/REPO/Packages/ createrepo --update ~/rpmbuild/REPO

Не забываем подписать метаданные:

gpg --detach-sign --armor ~/rpmbuild/REPO/repodata/repomd.xml

Смотри что и как получилось:

tree ~/rpmbuild/ -L 2 /home/chelaxe/rpmbuild/ ├── BUILD │ ├── chelaxe-release │ └── tmux-2.7 ├── BUILDROOT ├── REPO -> /var/www/repo ├── RPMS │ ├── noarch │ └── x86_64 ├── SOURCES │ ├── chelaxe-release │ ├── chelaxe-release.tar.gz │ ├── libevent-2.1.8-stable.tar.gz │ ├── libevent-2.1.8-stable.tar.gz.asc │ ├── ncurses-6.1.tar.gz │ ├── ncurses-6.1.tar.gz.sig │ ├── tmux-2.7.tar.gz │ └── tmux.conf ├── SPECS │ ├── chelaxe-release.spec │ └── tmux.spec └── SRPMS ├── chelaxe-release-1.0-1.el7.centos.src.rpm └── tmux-2.7-1.el7.centos.src.rpm

Установка и запуск

Устанавливаем наш пакет:

sudo yum clean all sudo yum install -y tmux

Запускаем tmux и радуемся:

tmux attach-session

Собираем fbida

Собирать будем fbida - комплект приложений для просмотра изображений в консоли. Данный пакет не нашел под Centos 7.

Готовим исходники

Скачиваем исходники fbida:

cd ~/rpmbuild/SOURCES wget https://www.kraxel.org/releases/fbida/fbida-2.14.tar.gz wget https://www.kraxel.org/releases/fbida/fbida-2.14.tar.gz.asc

Экспортируем GPG ключи для проверки исходников:

gpg --recv-keys D3E87138

Проверяем файлы:

gpg --verify fbida-2.14.tar.gz.asc fbida-2.14.tar.gz 2>&1 | grep "Good signature" gpg: Good signature from "Gerd Hoffmann (work) "

Готовим SPEC файл

В этом SPEC файле будет больше зависимостей:

cd ~/rpmbuild/SPECS vim ~/rpmbuild/SPECS/fbida.spec Name: fbida Version: 2.14 Release: 1%{?dist} Summary: FrameBuffer Imageviewer Vendor: D.F.H. Packager: ChelAxe Group: Applications/Multimedia License: GPLv2+ URL: https://www.kraxel.org/blog/linux/fbida/ Source: https://www.kraxel.org/releases/fbida/fbida-%{version}.tar.gz BuildRequires: libexif-devel fontconfig-devel libjpeg-turbo-devel BuildRequires: libpng-devel libtiff-devel pkgconfig BuildRequires: giflib-devel libcurl-devel libXpm-devel BuildRequires: pixman-devel libepoxy-devel libdrm-devel BuildRequires: mesa-libEGL-devel poppler-devel poppler-glib-devel BuildRequires: freetype-devel mesa-libgbm-devel Requires: libexif fontconfig libjpeg-turbo Requires: libpng libtiff giflib Requires: libcurl libXpm pixman Requires: libepoxy libdrm mesa-libEGL Requires: poppler poppler-glib freetype Requires: mesa-libgbm ImageMagick dejavu-sans-mono-fonts %description fbi displays the specified file(s) on the linux console using the framebuffer device. PhotoCD, jpeg, ppm, gif, tiff, xwd, bmp and png are supported directly. For other formats fbi tries to use ImageMagick"s convert. %prep %setup -q %{__sed} -i -e "s,/X11R6,g" GNUmakefile %install %__rm -rf %{buildroot} %make_install PREFIX=/usr %clean %__rm -rf %{buildroot} %files %defattr(-,root,root,-) %doc Changes COPYING INSTALL README TODO VERSION %{_prefix}/* %changelog * Tue May 1 2018 ChelAxe (D.F.H.) - 2.14-1%{?dist} - Initial package.

Сборка

Собираем пакет и добавляем его в репозиторий:

sudo yum install -y libexif-devel fontconfig-devel libjpeg-turbo-devel libpng-devel libtiff-devel pkgconfig giflib-devel libcurl-devel libXpm-devel ImageMagick dejavu-sans-mono-fonts pixman-devel libepoxy-devel libdrm-devel mesa-libEGL-devel poppler-devel poppler-glib-devel mesa-libgbm-devel rpmbuild -ba --sign ~/rpmbuild/SPECS/fbida.spec cp ~/rpmbuild/RPMS/x86_64/fbida-2.14-1.el7.centos.x86_64.rpm ~/rpmbuild/REPO/Packages/ createrepo --update ~/rpmbuild/REPO

Не забываем подписать метаданные:

gpg --detach-sign --armor ~/rpmbuild/REPO/repodata/repomd.xml

Установка и запуск

Устанавливаем наш пакет:

sudo yum clean all sudo yum install -y fbida

Настройка доступа по http/https

Теперь обеспечим доступ к нашему репозиторию по http/https.

Настройка

Первым делом настроем наш Apache:

sudo mv /etc/httpd/conf.d/welcome{.conf,.bak} sudo cp /etc/httpd/conf/httpd{.conf,.bak}

sudo vim /etc/httpd/conf/httpd.conf # Слушать на определенном интерфейсе и порте Listen 192.168.0.2:80 # Email адрес и имя сервера ServerAdmin [email protected] ServerName repo.chelaxe.ru # Не светить версию Apache ServerSignature Off ServerTokens Prod sudo cp /etc/httpd/conf.d/ssl{.conf,.bak} sudo vim /etc/httpd/conf.d/ssl.conf # Слушать на определенном интерфейсе и порте Listen 192.168.0.2:443 https # OCSP (Online Certificate Status Protocol) SSLStaplingCache "shmcb:logs/stapling-cache(128000)"

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

sudo apachectl configtest Syntax OK

sudo systemctl start httpd sudo systemctl enable httpd

Настраиваем наш репозиторий:

# Создадим свой файл с параметрами Диффи-Хеллмана cd /etc/ssl/certs sudo openssl dhparam -out dhparam.pem 4096 # Готовим публичный ключ для HKPK (HTTP Public Key Pinning) sudo openssl x509 -noout -in /etc/pki/tls/certs/localhost.crt -pubkey | openssl asn1parse -noout -inform pem -out /tmp/public.key # Получаем отпечаток публичного ключа для HKPK (HTTP Public Key Pinning) openssl dgst -sha256 -binary /tmp/public.key | openssl enc -base64 aQxRkBUlhfQjidLUovOlxdZe/4ygObbDG7l+RgwzSWA= rm -rf /tmp/public.key

Настройка VirtualHost:

sudo vim /etc/httpd/conf.d/repo.conf ServerAdmin "[email protected]" ServerName "repo.chelaxe.ru" DocumentRoot "/var/www/repo" AllowOverride None Options Indexes SSLEngine on # HSTS (HTTP Strict Transport Security) Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload" # HKPK (HTTP Public Key Pinning) Header set Public-Key-Pins "pin-sha256=\"aQxRkBUlhfQjidLUovOlxdZe/4ygObbDG7l+RgwzSWA=\"; max-age=2592000; includeSubDomains" # Гнать поисковых роботов Header set X-Robots-Tag "none" # Защита от некоторых XSS-атак Header set X-XSS-Protection "1; mode=block" # Защита от кликджекинг-атак Header always append X-Frame-Options DENY # Защита от подмены MIME типов Header set X-Content-Type-Options nosniff # Защита от XSS-атак Header set Content-Security-Policy "default-src "self";" # OCSP (Online Certificate Status Protocol) SSLUseStapling on # Отключаем сжатие SSL (защита от атаки CRIME) SSLCompression off # Отключаем SSLv2 и SSLv3 SSLProtocol all -SSLv2 -SSLv3 # Набор шифров SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH # Предпочтения сервера при согласовании шифров SSLHonorCipherOrder on # Используем свой файл с параметрами Диффи-Хеллмана # cat /etc/ssl/certs/dhparam.pem >> /etc/pki/tls/certs/localhost.crt # для 2.4.8 и старше # SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem" SSLOptions +StrictRequire SSLCertificateFile "/etc/pki/tls/certs/localhost.crt" SSLCertificateKeyFile "/etc/pki/tls/private/localhost.key"

Т.к. в Centos 7 у нас Apache 2.4.6, а не 2.4.8, то параметры Диффи-Хеллмана необходимо вшить в сертификат:

sudo bash -c "cat /etc/ssl/certs/dhparam.pem >> /etc/pki/tls/certs/localhost.crt"

По этой же причине с HTTP/2 у нас ничего не получится, но теперь вы можете собрать сами свежий Apache и воспользоваться HTTP/2.

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

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

sudo certbot --apache --agree-tos --email [email protected] -d repo.chelaxe.ru

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

RewriteEngine on RewriteCond %{SERVER_NAME} =repo.chelaxe.ru RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI}

и у VirtualHost для https:

Include /etc/letsencrypt/options-ssl-apache.conf SSLCertificateFile /etc/letsencrypt/live/repo.chelaxe.ru/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/repo.chelaxe.ru/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/repo.chelaxe.ru/chain.pem

Строку Include /etc/letsencrypt/options-ssl-apache.conf закомментируем.

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

sudo bash -c "cat /etc/ssl/certs/dhparam.pem >> /etc/letsencrypt/live/repo.chelaxe.ru/cert.pem"

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

# Готовим публичный ключ для HKPK (HTTP Public Key Pinning) sudo openssl x509 -noout -in /etc/letsencrypt/live/repo.chelaxe.ru/cert.pem -pubkey | openssl asn1parse -noout -inform pem -out /tmp/public.key # Получаем отпечаток публичного ключа для HKPK (HTTP Public Key Pinning) openssl dgst -sha256 -binary /tmp/public.key | openssl enc -base64 aidlhfQjoxRkbvOlxdZLBUe/4ygOUDG7l+RgwzQbSWA= rm -rf /tmp/public.key

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

# HKPK (HTTP Public Key Pinning) Header set Public-Key-Pins "pin-sha256=\"aidlhfQjoxRkbvOlxdZLBUe/4ygOUDG7l+RgwzQbSWA=\"; max-age=2592000; includeSubDomains"

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

sudo apachectl configtest Syntax OK sudo systemctl reload httpd

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

sudo crontab -e SHELL=/bin/bash [email protected] @daily certbot renew >> /var/log/certbot-renew.log

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

Файлы.htaccess

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

sudo chown apache:apache ~/rpmbuild/REPO/.htaccess sudo chmod 600 ~/rpmbuild/REPO/.htaccess sudo chcon -R -t httpd_sys_content_t ~/rpmbuild/REPO/.htaccess

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

IndexIgnore .htaccess

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

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

hide_file={.htaccess} deny_file={.htaccess}

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

AccessFileName .acl

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

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

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

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

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

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

sudo systemctl start vsftpd sudo systemctl enable vsftpd

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

sudo cp /etc/vsftpd/vsftpd{.conf,.bak} sudo vim /etc/vsftpd/vsftpd.conf anonymous_enable=YES local_enable=NO write_enable=NO local_umask=022 dirmessage_enable=YES xferlog_enable=YES connect_from_port_20=YES xferlog_std_format=YES listen=NO pam_service_name=vsftpd userlist_enable=YES tcp_wrappers=YES force_dot_files=NO anon_root=/var/www/repo no_anon_password=YES hide_ids=YES sudo usermod -d /var/www/repo ftp

Настроем SeLinux:

sudo semanage fcontext -a -t public_content_t "/var/www/repo(/.*)?" sudo restorecon -Rv "/var/www/repo"

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

sudo systemctl restart vsftpd

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

sudo chcon -R -t httpd_sys_content_t ~/rpmbuild/REPO/.htaccess

Заключение

Собственно на этом все. Надеюсь, данный мануал будет Вам полезен.

Linux-сервер своими руками Колисниченко Денис Николаевич

19.5. Создание RPM-пакетов

Программа RPM предназначена для произведения всех видов операций с программным обеспечением, в том числе и для создания пакетов для установки (RPM-пакетов).

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

port - откомпилированный бинарный файл.

README - файл, который будет помещен в каталог /usr/doc/port-1.0-99.

port.1 - файл для справочной системы man.

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

Для создания пакета нужно создать файл спецификаций. В файле спецификаций указывается вся информация о создаваемом пакете: название, версия, файлы программ, файлы документации, действия, выполняемые при установке пакета и при его удалении. Мой файл спецификаций для программы port представлен в листинге 19.1

Листинг 19.1. Файл спецификации для программы port

Summary: Program to control your serial device

Group: Monitoring

Packager: Denis Kolisnichenko

URL: http://dkws.narod.ru

Программа port предназначена для мониторинга состояния последовательного

порта. При получении сигнала (1) на какой-нибудь контакт указанного порта,

port отправляет сообщение запустившему ее пользователю на указанный email

%doc /root/port/README

/root/port/port.1

Для построения пакета нужно ввести команду:

# rpm –bb /root/port/port.spec

Если вы не допустили никаких ошибок при создании файла спецификаций, на экране вы увидите примерно такое сообщение:

Executing(%install): /bin/sh –e /var/tmp/rpm-tmp.33439

Processing files: port-1.0-99

Finding Provides: (using /usr/lib/rpm/find-provides)…

Finding Requires: (using /usr/lib/rpm/find-requires)…

Requires: ld-linux.so.2 libc.so.6 libc.so.6(GLIBC_2.0)

Записан: /usr/src/RPM/RPMS/i686/port-1.0-99.i686.rpm

При этом будет создан пакет port-1.0-99.i686.rpm. Этот пакет будет помещен в каталог /usr/src/RPM/RPMS/i686.

При удалении такого пакета он будет удален из базы RPM, но удаления самих файлов не произойдет. Действия, которые нужно выполнить до и после удаления пакета из базы RPM, вы можете определить в макрокомандах %preun и %postun соответственно. Например

rm –f /usr/bin/port

rm –f /usr/man/man1/port.1

Такой подход - самый простой выход из положения, однако он является не очень корректным. Решение этой проблемы оставляю вам в качестве домашнего задания.

А сейчас проведем небольшой эксперимент. Запустите Midnight Commander (mc), перейдите в каталог /usr/src/RPM/RPMS/i686/ и «войдите» в пакет port-1.0-99.i686.rpm как в обычный каталог. В нем будет «подкаталог» INFO, в котором и содержится вся информация о пакете.

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

1. Извлечения исходных текстов программы из архива.

2. Компилирование программы из исходных текстов.

3. Создание RPM-пакета.

Первые два этапа можно пропустить, что мы и сделали при создании пакета. Такое можно сделать только в случае, если программа уже откомпилирована из исходных текстов.

Программа RPM использует файл конфигурации rpmrc. Поиск этого файла производится в каталогах /usr/lib/rpm, /etc, $HOME. Просмотреть этот файл можно с помощью команды:

Запись topdir файла конфигурации rpmrc содержит название каталога, в котором находится дерево подкаталогов, которое используется менеджером RPM для построения пакетов. Введите команду:

# rpm –-showrc | grep topdir

14 _builddir %{_topdir}/BUILD

14 _rpmdir %{_topdir}/RPMS

14 _sourcedir %{_topdir}/SOURCES

–14 _specdir %{_topdir}/SPECS

–14 _srcrpmdir %{_topdir}/SRPMS

–14 _topdir %{usrsrc}/RPM

У меня эти подкаталоги находятся в каталоге /usr/src/RPM. Как вы видите, в этом каталоге находятся подкаталоги BUILD, RPMS, SOURCES, SPECS, SRPMS.

В каталоге BUILD создается RPM-пакет. В каталоге SOURCES находятся сжатые исходные тексты программы. В каталог RPMS помещаются созданные пакеты. Точнее, они помещаются в один из его подкаталогов, в какой именно - это зависит от архитектуры. В каталог SRPMS помещаются пакеты, содержащие исходные тексты программы. В каталоге SPECS находятся файлы спецификаций. Обычно файл спецификации называется назва-ние_программы-версия-релиз.8рес.

Например, если у вас есть исходный текст программы в архиве, из которого вы хотите создать пакет RPM, скопируйте его в каталог SOURCES:

# ср source_code-1.0.tar.gz /usr/src/RPM/SOURCES.

По умолчанию менеджер RPM работает с пакетами, расположенными в каталоге с именем, совпадающим с названием пакета и его версией. Для нашего пакета port это будет каталог port-1.0-99. Менеджер пакетов будет компилировать наш пакет в каталог /usr/src/RPM/port-1.0-99.

Думаю, уже достаточно информации о каталогах RPM. Теперь перейдем к файлу спецификаций. Файл спецификаций состоит из четырех сегментов: заголовка, подготовительного, файлового, установочного. В заголовке указывается общая информация о пакете. В листинге 19.1 к сегменту заголовка относятся тэги Summary, Name, Version, Release, Group и License. На них мы останавливаться не будем, так как их назначение понятно из листинга 19.1.

Есть еще очень полезный тэг: BuildRoot. Он изменяет расположение дерева BUILD. Значением по умолчанию является /usr/src/RPM или другой каталог, задаваемый переменной окружения $RPM_BUILD_ROOT. В целях экономии дискового пространства полезно после установки удалить дерево %RPM_BUILD_ROOT. Но это дерево по умолчанию может содержать другие файлы, относящиеся к другим пакетам. Поэтому сначала с помощью тэга BuildRoot нужно задать какой-нибудь временный каталог, а после установки удалить его.

В каждом сегменте находятся макрокоманды. С некоторыми мы уже знакомы - это %description, %files, %doc, %install. В табл. 19.34 приведено полное описание макрокоманд.

Макрокоманды Таблица 19.34

Макрокоманда	Описание
%description	Полное описание пакета
%prep	Подготовка архива. Здесь задаются команды для извлечения исходного текста программы и его распаковки, дополнительная подготовка исходного текста. После макрокоманды %prep задаются обычные команды shell
%setup	Макрокоманда извлечения файлов из архивов. Опция –n позволяет указать каталог, в котором будет создаваться новый пакет. Обычно распаковывается архив, расположенный в каталоге SOURCES, в каталог BUILD
%build	Макрокоманда компилирования. Обычно здесь запускается программа make с необходимыми параметрами
%files	Задает список файлов, входящих в состав пакета. При указании имен файлов должен быть указан полный, а не относительный путь. Для указания полного пути можно использовать переменную окружения $RPM_BUILD_ROOT. Необходимые файлы уже должны быть помещены в каталог BUILD. Этого можно достичь с помощью макрокоманды %setup или с помощью макрокоманды %pre (см. ниже)
%config список	Задает список файлов, которые будут помещены в каталог /etc
%doc список	Задает список файлов, которые будут помещены в каталог /usr/doc/––
%install	Этап установки программного обеспечения. Здесь нужно записать команды, которые будут устанавливать файлы, входящие в состав пакета. Удобнее использовать команду install которую я использовал в листинге 19.1
%pre	Действия, которые будут выполнены до инсталляции пакета
%post	Действия, которые будут выполнены после инсталляции пакета
%preun	Действия, которые будут выполнены перед удалением пакета
%postun	Действия, которые будут выполнены после удаления пакета
%clean	Удаление дерева BUILD. Используется вместо опции - clean программы rpm. Обычно содержит одну команду: rm –rf $RPM_BUILD_ROOT

Нужно сделать небольшое замечание относительно макрокоманд %config и %doc. В этом случае список задается не так, как в макрокоманде %files. Если после макрокоманды %files можно было просто указать по одному файлу в каждой строке, то в макрокоманде %doc каждому файлу (или каждому списку) должна предшествовать команда %doc. Например:

%doc README TODO Changes

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

При создании пакета мы использовали опцию –bb программы rpm. При указании этой опции создается только двоичный RPM-пакет, если вы хотите создать также пакет, содержащий исходный текст программы, используйте опцию –ba. Созданный пакет помещается в каталог SRPMS и будет иметь имя port-1.0-99.src.rpm. To есть вместо названия архитектуры будет указано, что данный пакет содержит исходный текст программы. Для создания такого пакета в каталоге SOURCES должны находиться исходные тексты программы.

Для полноты картины осталось рассмотреть опции менеджера rpm, которые используются для создания пакетов (см. табл. 19.35).

Опции менеджера пакетов rpm Таблица 19.35

Опция	Описание
-ba	Создаются два пакета: двоичный и содержащий исходный текст. При этом не пропускается ни один этап установки, указанный в файле спецификаций
-bb	Создается только двоичный пакет. Не пропускается ни один этап установки, указанный в файле спецификаций
-be	Выполняются этапы %pre и %build. При этом пакет распаковывается и компилируется
-bi	Выполняются этапы %pre, %build, %install
-bl	Выполняется проверка списка файлов, указанных в макрокоманде
-bp	Выполняется только этап %pre, то есть распаковывается архив
--recompile package.src.rpm	Указанный пакет, содержащий исходные тексты, сначала устанавливается, а потом компилируется
--rebuild package.src.rpm	Устанавливается и компилируется пакет исходных текстов, а затем создается новый двоичный пакет
--test	Проверка файла спецификаций
--clean	Удаление дерева каталогов BUILD после создания пакета
--showrc	Выводит файл конфигурации

Из книги Fedora 8 Руководство пользователя автора

3.1. Менеджер пакетов yum 3.1.1. Основные понятие о пакетах Давайте сначала рассмотрим процесс установки программ в Windows. Как правило, дистрибутив Windows-программы состоит та установочного файла (обычно называется setup.exe или install.exe) и нескольких вспомогательных файлов (например,

Из книги 200 лучших программ для Linux автора Яремчук Сергей Акимович

3.2.4. Создание собственного сервера пакетов Данный параграф больше рассчитан на администраторов сетей, которые понимают, что они делают. Обычным пользователям его можно прочитать разве что для "общего развития", хотя приведенный способ можно удачно использовать не только

Из книги Skype: бесплатные звонки через Интернет. Начали! автора Гольцман Виктор Иосифович

3.3.3.1. Установка пакетов Для установки пакета (или пакетов - в командной строке можно указать несколько пакетов) используется опция -i:rpm - i пакетЕсли вы хотите наблюдать за процессом установки (это очень полезно, если устанавливается большой пакет или же производится

Из книги Linux-сервер своими руками автора Колисниченко Денис Николаевич

3.3.3.2. Удаление пакетов Для удаления пакета используется опция -е. При удалении не нужно задавать полное имя файла пакета, достаточно названия самой программы. Например, если изначально пакет назывался program-base-0.94-2.i386.rpm, то для его удаления достаточно ввести команду: rpm -e

Из книги UNIX: взаимодействие процессов автора Стивенс Уильям Ричард

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

Из книги Программирование на языке Ruby [Идеология языка, теория и практика применения] автора Фултон Хэл

Передача пакетов Следующий этап – это передача пакетов. Транспортировка цифрового трафика осуществляется через Интернет с помощью технологии TCP/IP. Термин TCP/IP обозначает целый набор технологий и прикладных программ, связанных с передачей данных через Интернет. Сюда

Из книги Linux: Полное руководство автора Колисниченко Денис Николаевич

1.7.7. Структура пакетов IP и TCP Вот теперь можно смело перейти к рассмотрению структуры пакетов IP и TCP. Протокол IP не ориентирован на соединение, поэтому не обеспечивает надежную доставку данных. Поля, описание которых приведено в табл. 1.6, представляют собой IP-заголовки и

Из книги Linux глазами хакера автора Флёнов Михаил Евгеньевич

14.3.2. Фрагментация пакетов Иногда передаваемый пакет слишком большой, чтобы его можно было бы передавать за один раз. Если такое происходит, то пакет делится на фрагменты, и эти фрагменты пересылаются. Компьютер, которому этот пакет предназначен, собирает эти фрагменты в

Из книги Linux Mint и его Cinnamon. Очерки применителя автора

19 Полезные команды и программы. Создание RPM-пакетов

Из книги Священные войны мира FOSS автора Федорчук Алексей Викторович

16.9. Форматы пакетов RPC На рис. 16.5 приведен формат запроса RPC в пакете TCP.Поскольку TCP передает поток байтов и не предусматривает границ сообщений, приложение должно предусматривать способ разграничения сообщений. Sun RPC определяет запись как запрос или ответ, и каждая запись

Из книги автора

Глава 17. Создание пакетов и распространение программ Все больше и больше продуктов - и в первую очередь аспирин - выпускается в упаковке, защищенной до такой степени, что потребитель уже и воспользоваться ими не может. Дэйв Бэрри Эта глава посвящена вопросу о том, как

Из книги автора

27.1.2. Структура пакетов IP и TCP Протокол IP не ориентирован на соединение, поэтому не обеспечивает надежную доставку данных. Поля, описание которых приведено в таблице 27.4, представляют собой IP-заголовок и добавляются к пакету при его получении с транспортного

Из книги автора

4.10.1. Фильтрация пакетов Итак, основной, но не единственной задачей сетевого экрана является фильтрация пакетов. В Linux уже встроен Firewall, и вам его не надо устанавливать отдельно. Точнее сказать, их даже два: iptables и ipchains. Они позволяют контролировать трафик, который проходит

Из книги автора

14.12.1. Дефрагментация пакетов С помощью фрагментированных пакетов хакеры производят очень много атак на серверы. В Linux можно сделать так, чтобы ОС объединяла приходящие пакеты. Если у вас монолитное ядро (без поддержки модулей), то необходимо прописать 1 в файл

Из книги автора

Формат пакетов Как уже было сказано, в дистрибутиве Mint принят deb-формат пакетов. Будучи разработан ещё в прошлом тысячелетии для дистрибутива Debian, формат этот был унаследован от него Ubuntu, во многом предопределив успех последней. А вслед за ней - и удачливость нашего

Во многих наших проектах используются open-source библиотеки. Когда разработка ведется под одну конкретную платформу, нет смысла собирать одни и те же библиотеки из исходников каждый раз, когда к проекту подключается новый разработчик. Кроме того, установка библиотек а-ля make && sudo make install считается плохим тоном, поскольку система засоряется «бесхозными» файлами, о которых нет информации в базе данных менеджера пакетов RPM.

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

Инструкция будет основываться на примере Red Hat Enterprise Linux 6, но с небольшими изменениями ее можно будет адаптировать и для других дистрибутивов. Для примера будем собирать пакет из библиотеки zeromq.

Перед сборкой пакета

Первое, что нужно сделать перед сборкой - убедиться, что нужный вам пакет не собрал кто-то до вас. Часто на таких ресурсах, как rpmfind.net и rpm.pbone.net можно найти то, что вам нужно. Но если не нашлось необходимой версии библиотеки или нет сборки под вашу платформу, то придется собирать пакет самому.

rpmbuild

Сборка пакетов осуществляется с помощью утилиты rpmbuild . Перед ее использованием необходимо сконфигурировать окружение сборки. Создадим необходимое дерево каталогов, например, в директории ~/rpmbuild:

$ mkdir ~/rpmbuild $ mkdir ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}

Создаем файл конфигурации утилиты rpmbuild, чтобы она узнала, где находится созданное дерево каталогов:

$ echo "%_topdir %(echo $HOME)/rpmbuild" >~/.rpmmacros

rpmbuild при запуске будет искать файлы пакета в директории ~/rpmbuild/BUILDROOT/<имя_пакета>. Разберемся, как именуются RPM-пакеты, на примере zeromq:

zeromq-3.2.4-1.rhel6.x86_64.rpm

zeromq - собственно, имя пакетируемого ПО;
3.2.4 - версия ПО;
1.rhel6 - номер сборки пакета (release number) - сколько раз данная версия ПО собиралась в rpm-пакет. Суффиксом rhel6 или el6 обычно обладают пакеты для Red Hat Enterprise Linux 6;
x86_64 - процессорная архитектура, под которую скомпилировано ПО.

Обратите внимание на знаки, разделяющие поля имени пакета. Они должны быть именно такими, как в примере.

Итак, создаем директорию для zeromq в BUILDROOT:

$ mkdir ~/rpmbuild/BUILDROOT/zeromq-3.2.4-1.rhel6.x86_64

Сборка библиотеки

Само собой, перед сборкой бинарного пакета, нужно скомпилировать саму библиотеку. Если библиотека использует систему сборки GNU Autotools, то обычно это делается командами:

$ ./configure $ make

Теперь устанавливаем библиотеку в созданную нами директорию в BUILDROOT:

$ make install DESTDIR="$HOME/rpmbuild/BUILDROOT/zeromq-3.2.4-1.rhel6.x86_64"

Параметр DESTDIR не всегда обрабатывается в мейкфайлах. Например, qmake генерирует мейкфайлы, которые игнорируют этот параметр. Если библиотека использует систему сборки, отличную от GNU Autotools, то прочитайте в соответствующем руководстве, какие параметры нужно передать при сборке, чтобы установить библиотеку в указанную директорию.

spec-файл для сборки пакета

В RPM-пакетах помимо заархивированного дерева файлов хранится метаинформация об этом пакете. При сборке она должна задаваться в spec-файле, который находится в папке ~/rpmbuild/SPECS. Рассмотрим пример файла zmq.spec для библиотеки zeromq:

Name: zeromq Version: 3.2.4 Release: 1.rhel6 Summary: Software library for fast, message-based applications Packager: My organization Group: System Environment/libraries License: LGPLv3+ with exceptions %description The 0MQ lightweight messaging kernel is a library which extends the standard socket interfaces with features traditionally provided by specialized messaging middle-ware products. 0MQ sockets provide an abstraction of asynchronous message queues, multiple messaging patterns, message filtering (subscriptions), seamless access to multiple transport protocols and more. This package contains the ZeroMQ shared library for versions 3.x. %post /sbin/ldconfig %postun /sbin/ldconfig %files %defattr(-,root,root) /usr/lib64/libzmq.so.3 /usr/lib64/libzmq.so.3.0.0 %package devel Summary: Development files for zeromq3 Group: Development/Libraries Requires: %{name} = %{version}-%{release} %description devel The zeromq3-devel package contains libraries and header files for developing applications that use zeromq3 3.x. %files devel %defattr(-,root,root) /usr/include /usr/share /usr/lib64/pkgconfig /usr/lib64/libzmq.so /usr/lib64/libzmq.a /usr/lib64/libzmq.la

В начале файла указывается минимальный набор полей с информацией о пакете. Из значений первых трех полей (Name , Version , Release ) формируется имя пакета, поэтому важно, чтобы там были указаны правильные значения. Если значения не будут соответствовать имени каталога с деревом файлов собираемого пакета, rpmbuild выдаст ошибку. Поле License также является обязательным - без него rpmbuild откажется собирать пакет.

Назначение секции %description очевидно. Секции %post и %postun содержат скрипты, выполняющиеся после установки файлов пакета в систему и после удаления файлов пакета из системы, соответственно. Это полезно, если пакет устанавливает динамические библиотеки (.so) в нестандартные директории (т. е. не в /lib, /usr/lib, /lib64 или /usr/lib64). В этом случае пакет должен предоставлять файл конфигурации для ldconfig и устанавливать его в /etc/ld.so.conf.d. Команда ldconfig обновляет кэш динамического загрузчика, добавляя в него все библиотеки, найденные в директориях, указанных в конфигурационных файлах.

В секции %files указывается список файлов, которые пакуются в rpm. Директива %defattr указывает атрибуты файлов по умолчанию в формате:

%defattr (, , ,

)

указывается в восьмеричном виде, например, «644» для rw-r--r--. Атрибут

может быть опущен. Вместо атрибутов, которые не должны меняться для устанавливаемых файлов, можно указать дефис. Директории, указанные в секции %files , будут внесены в пакет вместе со всем их содержимым.

Дальше самое интересное. Фактически существует два типа RPM-пакетов библиотек. В одних находятся собственно сами файлы динамических библиотек, необходимые для работы программ, которые скомпонованы с этими библиотеками. Например, пакет zeromq-3.2.4-1.rhel6.x86_64.rpm предоставляет только два файла: /usr/lib64/libzmq.so.3.0.0 и символьную ссылку на него, /usr/lib64/libzmq.so.3. Другой тип пакетов содержит файлы, необходимые для разработки приложений с использованием предоставляемой библиотеки. К имени таких пакетов добавляется суффикс "-devel", например, zeromq-devel-3.2.4-1.el6.x86_64.rpm. В таких пакетах обычно содержатся заголовочные файлы C/C++, документация, статические библиотеки (.a), и эти пакеты являются зависимыми от пакетов первого типа.

В приведенном выше spec-файле директива %package позволяет собрать «дочерний» пакет одним запуском rpmbuild. Значения полей заголовков дочернего пакета наследуются от родительского, но их можно переопределить. Поле Requires задает дополнительную зависимость от родительского пакета. Заметьте, что секция %files пакета zeromq-devel содержит файл /usr/lib64/libzmq.so. Это символьная ссылка на настоящий файл с динамической библиотекой. Он необходим компоновщику ld на этапе сборки приложения с использованием библиотеки, поскольку он ищет файлы динамических библиотек, начинающиеся на «lib» и заканчивающиеся на ".so".

Сборка

Перед сборкой нужно иметь в виду две вещи.
Первое: при успешной сборке пакета rpmbuild очистит директорию BUILDROOT. Так что на всякий случай сделайте резервную копию пакетируемых файлов.
Второе: никогда не собирайте пакеты с правами root. объясняется, почему так нельзя делать.

Теперь все готово для сборки пакета. Запускаем rpmbuild:

$ cd ~/rpmbuild/SPECS $ rpmbuild -bb zmq.spec

Параметр -bb означает «build binary», то есть, собрать бинарный пакет. Помимо бинарных пакетов есть еще пакеты исходных кодов, но они здесь не обсуждаются.

В случае успеха полученный rpm-пакет будет сохранен в папке RPMS.

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

$ rpm -qip package.rpm

Здесь «q» означает «режим запросов (query)», «i» - получение информации о пакете, «p» - получение информации об указанном файле пакета (без этой опции будет получена информация о пакете, установленном в системе, если он установлен).

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

$ rpm2cpio package.rpm | cpio -di

Утилита rpm2cpio пишет в стандартный вывод cpio-архив, хранящийся в rpm-пакете; утилита cpio распаковывает архив, принятый из стандартного ввода. Параметр «i» включает режим распаковки, а «d» создает нужные директории.

Посмотреть, какие файлы предоставляет пакет, можно и не распаковывая его, с помощью опции «f»:

$ rpm -qfp package.rpm

Итого

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

Иногда встречаются полезные программы, доступные только в виде исходных кодов (и/или в виде установочных пакетов для других ОС), но есть необходимость их установки на несколько компьютеров. Чтобы не выполнять компиляцию на каждом компьютере отдельно, можно на одном подготовить установочный пакет и установить его штатными средствами на других компьютерах.
Ниже приведён пример создания RPM пакета для Fedora 21 (для других версий Fedora процедура не отличается) из исходных текстов очень приятной и полезной программы Boomaga версии 0.7.0.

Готовим инструменты сборки RPM

Для начала я попытался установить необходимые инструменты (как мне посоветовала ):
sudo dnf install @development-tools но эта команда не выполнилась, ссылаясь на отсутствие группы development-tools. Тогда я установил всё другой командой, которую мне подсказала :
sudo dnf groupinstall "Development Tools" и ещё две команды из обеих вышеуказанных статей:
sudo dnf install rpmdevtools sudo dnf install fedora-packager Затем надо сгенерировать рабочее пространство для сборки RPM:
rpmdev-setuptree В результате этой команды создадутся необходимые каталоги в домашнем каталоге текущего пользователя (показываю содержимое нового каталога rpmbuild ):
$ ls ~/rpmbuild/ BUILD BUILDROOT RPMS SOURCES SPECS SRPMS В каталог SOURCES сразу перемещаю архив исходников (boomaga-0.7.0.tar.gz), как он есть. Кстати, тут есть небольшой подвох от github, - ссылка на закачку не даётся напрямую, а генерируется только после клика по ней. Из-за этого не получилось указать прямую ссылку на архив в интернете в SPEC файле, о котором пойдёт речь ниже.

Готовим SPEC файл

Для упаковки исходных текстов программы в RPM пакет нужен специальный файл с описанием необходимых действий. Сгенерируем шаблон:
rpmdev-newspec boomaga В результате этой команды будет создан файл boomaga.spec в каталоге ~/rpmbuild/SPEC. Тут важно название SPEC файла. Оно должно совпадать с названием программы (т.е. без номера версии). После автоматической генерации SPEC файла переходим к его редактированию. В моём случае это получилось так:
Name: boomaga Version: 0.7.0 Release: 1%{?dist} Summary: Boomaga is a virtual printer for viewing a document before printing License: GPLv2 and LGPLv2+ URL: http://boomaga.github.io Source0: %{name}-%{version}.tar.gz BuildRequires: cmake,cups-devel,poppler-devel,poppler-cpp-devel,qt5-qtbase-devel,qt5-qttools-devel,snappy-devel Requires: cups %description Boomaga (BOOklet MAnager) is a virtual printer for viewing a document before printing it out using the physical printer. The program is very simple to work with. Running any program, click “print” and select “Boomaga” to see in several seconds (CUPS takes some time to respond) the Boomaga window open. If you print out one more document, it gets added to the previous one, and you can also print them out as one. %prep %setup -q %build mkdir build cd build cmake .. %make_install %files %defattr(0755,root,root,-) /usr/lib/cups/backend/boomaga /usr/lib/cups/filter/boomaga_pstopdf /usr/local/bin/boomaga /usr/local/lib/boomaga/boomagabackend /usr/local/lib/boomaga/boomagamerger /usr/local/share/applications/boomaga.desktop /usr/local/share/boomaga/translations/boomaga_cs.qm /usr/local/share/boomaga/translations/boomaga_de.qm /usr/local/share/boomaga/translations/boomaga_el.qm /usr/local/share/boomaga/translations/boomaga_fr.qm /usr/local/share/boomaga/translations/boomaga_it.qm /usr/local/share/boomaga/translations/boomaga_lt.qm /usr/local/share/boomaga/translations/boomaga_pl_PL.qm /usr/local/share/boomaga/translations/boomaga_ru.qm /usr/local/share/boomaga/translations/[email protected] /usr/local/share/dbus-1/services/org.boomaga.service /usr/local/share/icons/hicolor/128x128/apps/boomaga.png /usr/local/share/icons/hicolor/16x16/apps/boomaga.png /usr/local/share/icons/hicolor/32x32/apps/boomaga.png /usr/local/share/icons/hicolor/64x64/apps/boomaga.png /usr/local/share/mime/packages/boomaga.xml /usr/share/ppd/boomaga/boomaga.ppd %attr(0644,root,root) %doc /usr/local/share/man/man1/boomaga.1.gz %changelog * Mon Jun 22 2015 Oleg - Всё, что идёт после знака процента является макросом (например, %build) или предопределённым значением (например, %{name}). Как сказано в документации Fedora , перечень и описание всех макросов можно найти в каталогах:

/etc/rpm/*
/usr/lib/rpm
/usr/lib/rpm/macros

Много полезной информации можно почерпнуть, выполнив команду
rpm --showrc Прокомментирую указанные значения.
Параметр Name должен совпадать с именем SPEC файла и названием программы (указывается без номера версии).
Параметр Source0 должен по-хорошему указывать на архив в интернете, который имеет такое же название, как и файл в каталоге ~/rpmbuild/SOURCES, но т.к. ссылки на boomaga-0.7.0.tar.gz в интернете я не нашёл, то указал локальную ссылку. Без пути. Только название файла и с использованием переменных (берутся из указанных выше одноимённых параметров).
Перед тем, как пытаться собрать RPM пакет, я пробовал скомпилировать программу обычным образом. Для этого понадобилось установить инструмент cmake и зависимости данной программы: cups-devel, poppler-devel, poppler-cpp-devel, qt5-qtbase-devel, qt5-qttools-devel, snappy-devel. Все эти пакеты я указал в параметре BuildRequires .
Т.к. boomaga может работать в роли виртуального принтера как прослойка между CUPS, то я указал cups в параметре Requires .
Далее идут макросы, которые будут выполняться при сборке RPM пакета.
После макроса %description делаем переход на новую строку и вставляем описание из родного сайта проекта.
Макрос %setup -q распаковывает исходные коды в каталог ~/rpmbuild/BUILD/%{name}-%{version}, т.е. в нашем случае - ~/rpmbuild/BUILD/boomaga-0.7.0
Далее начинается самое ответственное. Нужно описать всё для автоматической компиляции проекта. Я поступил так. Открыл официальную инструкцию по установке данного приложения и переделал под текущую ситуацию. Инструкция по установке оказалась весьма лаконичной и понятной:
mkdir ~/boomaga/build cd ~/boomaga/build cmake .. make && sudo make install В форме макросов в SPEC файле эти инструкции выразились так:
%build mkdir build cd build cmake .. %make_install Первый макрос %build отвечает за сборку исходников. В этой фазе создаём каталог build в текущем каталоге (т.е. в ~/rpmbuild/BUILD/boomaga-0.7.0) и перемещаемся в него. Потом запуск cmake для генерации Makefile. Т.е. всё то, что написано в инструкции по обычной установке данной программы.
Затем макрос %make_install собирёт всё каталоге в ~/rpmbuild/BUILDROOT/boomaga-0.7.0-1.fc21.R.x86_64 так, как если бы шла нормальная установка. Т.е. там создаётся каталог usr со всеми задействованными подкаталогами.
Операции макросов %files (тут нужно указать список всех файлов, входящих в RPM пакет) и %doc (вся документация) заполнил в соответствии с подсказками после первых неудачных запусков, - при сборке пакета выводилось сообщение:
Processing files: boomaga-debuginfo-0.7.0-1.fc21.R.x86_64 Проверка на неупакованный(е) файл(ы): /usr/lib/rpm/check-files /home/oleg/rpmbuild/BUILDROOT/boomaga-0.7.0-1.fc21.R.x86_64 ошибка: Обнаружен(ы) установленный(е) (но не упакованный(е)) файл(ы): /usr/lib/cups/backend/boomaga /usr/lib/cups/filter/boomaga_pstopdf /usr/local/bin/boomaga /usr/local/lib/boomaga/boomagabackend /usr/local/lib/boomaga/boomagamerger /usr/local/share/applications/boomaga.desktop /usr/local/share/boomaga/translations/boomaga_cs.qm /usr/local/share/boomaga/translations/boomaga_de.qm /usr/local/share/boomaga/translations/boomaga_el.qm /usr/local/share/boomaga/translations/boomaga_fr.qm /usr/local/share/boomaga/translations/boomaga_it.qm /usr/local/share/boomaga/translations/boomaga_lt.qm /usr/local/share/boomaga/translations/boomaga_pl_PL.qm /usr/local/share/boomaga/translations/boomaga_ru.qm /usr/local/share/boomaga/translations/[email protected] /usr/local/share/dbus-1/services/org.boomaga.service /usr/local/share/icons/hicolor/128x128/apps/boomaga.png /usr/local/share/icons/hicolor/16x16/apps/boomaga.png /usr/local/share/icons/hicolor/32x32/apps/boomaga.png /usr/local/share/icons/hicolor/64x64/apps/boomaga.png /usr/local/share/man/man1/boomaga.1.gz /usr/local/share/mime/packages/boomaga.xml /usr/share/ppd/boomaga/boomaga.ppd Ошибки сборки пакетов: Обнаружен(ы) установленный(е) (но не упакованный(е)) файл(ы): /usr/lib/cups/backend/boomaga /usr/lib/cups/filter/boomaga_pstopdf /usr/local/bin/boomaga /usr/local/lib/boomaga/boomagabackend /usr/local/lib/boomaga/boomagamerger /usr/local/share/applications/boomaga.desktop /usr/local/share/boomaga/translations/boomaga_cs.qm /usr/local/share/boomaga/translations/boomaga_de.qm /usr/local/share/boomaga/translations/boomaga_el.qm /usr/local/share/boomaga/translations/boomaga_fr.qm /usr/local/share/boomaga/translations/boomaga_it.qm /usr/local/share/boomaga/translations/boomaga_lt.qm /usr/local/share/boomaga/translations/boomaga_pl_PL.qm /usr/local/share/boomaga/translations/boomaga_ru.qm /usr/local/share/boomaga/translations/[email protected] /usr/local/share/dbus-1/services/org.boomaga.service /usr/local/share/icons/hicolor/128x128/apps/boomaga.png /usr/local/share/icons/hicolor/16x16/apps/boomaga.png /usr/local/share/icons/hicolor/32x32/apps/boomaga.png /usr/local/share/icons/hicolor/64x64/apps/boomaga.png /usr/local/share/man/man1/boomaga.1.gz /usr/local/share/mime/packages/boomaga.xml /usr/share/ppd/boomaga/boomaga.ppd В результате успешной сборки формируются RPM пакеты:
~/rpmbuild/RPMS/x86_64/boomaga-0.7.0-1.fc21.R.x86_64.rpm
~/rpmbuild/RPMS/x86_64/boomaga-debuginfo-0.7.0-1.fc21.R.x86_64.rpm
~/rpmbuild/SRPMS/boomaga-0.7.0-1.fc21.R.src.rpm
А вот, собственно, как запускать сборку:
rpmbuild --target=x86_64 -ba ~/rpmbuild/SPECS/boomaga.spec Команда отрабатывает за пару минут. В это время в консоли пролетают красивые разноцветные строчки.

Позже, когда дистрибутив Fedora обновится до следующей версии, можно будет попробовать перепаковать пакет boomaga-0.7.0-1.fc21.R.src.rpm такой командой:
rpmbuild --rebuild boomaga-0.7.0-1.fc21.R.src.rpm Теоретически это позволит сократить время сборки RPM пакета.
Для проверки SPEC файла и формируемого пакета можно перейти в каталог ~/rpmbuild/SPEC и воспользоваться командой:
rpmlint boomaga.spec ../SRPMS/boomaga* ../RPMS/*/boomaga* В результате будут показаны различные предупреждения и ошибки. В моём случае есть ошибки расположения файлов. Но для личного пользования подойдёт и так. Хотя с такими ошибками в официальные репозитории не пропустят.
Посмотреть описание ошибки можно, указав её название после ключа -I в следующей команде:
rpmlint -I hardcoded-library-path

Полезные ссылки

Различных параметров и макросов существует довольно много. В официальной документации Fedora есть исчерпывающие полезные и обширные материалы "How to create an RPM package " и "Packaging:Guidelines ". Также есть пример с пояснениями SPEC файла в материале "Annotated spec file ".

Делаем RPM лучше

Чтобы полученный RPM пакет не только выполнял свою функцию, но и делал это правильно, нужно избавиться от всех ошибок, на которые указывает rpmlint.

Основная ошибка состоит в том, что полученные файлы в системе устанавливаются не туда, куда положено. Во-первых, всё должно соответствовать стандарту Filesystem Hierarchy Standard , который недавно обновился . Во-вторых RPM пакет для Fedora должен соответствовать правилам этого дистрибутива.

Нужно избавиться от жёстко прописанных путей в секции %files. Для этого применяются макросы. В моём случае исходный код программы в нескольких местах имел жёстко прописанный путь в подкаталог lib, а для архитектуры x86_64 нужно было указывать lib64. Поэтому потребовалось немного подкорректировать исходный код программы .

В результате общения с разработчиками программы на github.com , SPEC файл пополнился также автоматическим прописыванием принтера в системе. Плюс программа Boomaga успела обновиться до версии 0.7.1. Результирующий SPEC файл:

Name: boomaga Version: 0.7.1 Release: 1%{?dist} Summary: A virtual printer for viewing a document before printing License: GPLv2 and LGPLv2+ URL: http://boomaga.github.io Source0: %{name}-%{version}.tar.gz BuildRequires: cmake,cups-devel,poppler-devel,poppler-cpp-devel,qt5-qtbase-devel,qt5-qttools-devel,snappy-devel Requires: cups,snappy %description Boomaga (BOOklet MAnager) is a virtual printer for viewing a document before printing it out using the physical printer. The program is very simple to work with. Running any program, click “print” and select “Boomaga” to see in several seconds (CUPS takes some time to respond) the Boomaga window open. If you print out one more document, it gets added to the previous one, and you can also print them out as one, and you can also print them out as one. Regardless of whether your printer supports duplex printing or not, you would be able to easily print on both sides of the sheet. If your printer does not support duplex printing, point this out in the settings, and Booklet would ask you to turn over the pages half way through printing your document. The program can also help you get your documents prepared a bit before printing. At this stage Boomaga makes it possible to: * Paste several documents together. * Print several pages on one sheet. * 1, 2, 4, 8 pages per sheet * Booklet. Folding the sheets in two, you’ll get a book. %prep %setup -q %build %ifarch x86_64 %cmake -DLIB_SUFFIX=64 -DCUPS_BACKEND_DIR=%{_libdir}/cups/backend -DCUPS_FILTER_DIR=%{_libdir}/cups/filter . %else %cmake -DCUPS_BACKEND_DIR=%{_libdir}/cups/backend -DCUPS_FILTER_DIR=%{_libdir}/cups/filter . %endif make %{?_smp_mflags} %install make install DESTDIR=%{buildroot} %__mkdir -p %{buildroot}%{_datadir}/%{name}/scripts %__install -m 755 scripts/installPrinter.sh %{buildroot}%{_datadir}/%{name}/scripts/ chmod +x %{buildroot}%{_datadir}/%{name}/scripts/installPrinter.sh # Add translation lang tags (cd %{buildroot} && find . -name "*.qm") | %__sed -e "s|^.||" | sed -e \ "s:$.*/translations/boomaga_$$\+$$.*qm$$:%lang(\2) \1\2\3:"\ >> %{name}.lang %pre # Start cups if is stopped if [ "$(systemctl is-active cups.service)" != "active" ]; then systemctl start cups sleep 2 fi %post # Install the printer to cups backends if [ $1 = 1 ]; then sh %{_datadir}/%{name}/scripts/installPrinter.sh fi %preun # Uninstall the printer lpadmin -x "Boomaga" %files %defattr(755,root,root,-) %{_libdir}/cups/backend/%{name} %defattr(-,root,root,-) %{_libdir}/cups/filter/boomaga_pstopdf %{_bindir}/%{name} %{_libdir}/%{name}/boomagabackend %{_libdir}/%{name}/boomagamerger %{_datadir}/applications/boomaga.desktop %{_datadir}/%{name}/translations/* %{_datadir}/dbus-1/services/org.boomaga.service %{_datadir}/icons/hicolor/* %{_datadir}/mime/packages/boomaga.xml %{_datadir}/ppd/%{name}/boomaga.ppd %{_datadir}/%{name}/scripts/installPrinter.sh %doc COPYING GPL LGPL README.md %{_mandir}/man1/boomaga.1.gz %changelog * Tue Jun 30 2015 Oleg Ekhlakov 0.7.1-1.fc21.R - Initial version of the package