[Перевод] Kali Linux: модификация пакетов24.10.2017 15:18

Продолжаем переводить книгу «Kali Linux Revealed». Девятая глава посвящена расширенному использованию системы. В частности, изучив её, можно узнать о том, как создать из базового дистрибутива Kali именно то, что вам нужно. Сегодня мы публикуем перевод первого раздела этой главы. Речь пойдёт о модификации пакетов Kali.

d6ff3f56201df7a112b39a40a218a3d7.jpg


Глава 9. Расширенное использование системы


Kali создана как модульная настраиваемая среда, ориентированная на цели пентестинга, поддающаяся глубокой настройке и поддерживающая различные сценарии использования. Настройка системы может затрагивать множество уровней. Если нужно — начать можно с исходного кода. Будем считать этот уровень настройки первым. Исходный код пакетов Kali общедоступен. В этой главе мы покажем, как находить пакеты, как их модифицировать и собирать из них собственные пакеты, настроенные так, как нужно именно вам. Модификация ядра Linux — это своеобразная область настройки системы, поэтому ей посвящён отдельный раздел. В нём мы поговорим о том, где найти исходный код ядра, как настроить систему его сборки, и, наконец, как его скомпилировать и собрать необходимые пакеты ядра.

Второй уровень настройки системы заключается в сборке Live-образов. Мы покажем как, используя инструмент live-build, задействовать множество возможностей по тонкой настройке готовых ISO-образов. В том числе, речь пойдёт об использовании предварительно настроенных в соответствии с вашими нуждами пакетов Debian вместо пакетов, доступных на зеркалах.

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

9.1. Модификация пакетов Kali


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

Возможно, вы зададитесь вопросом о том, почему вам вообще нужно этим заниматься. В конце концов, если требуется модифицировать какое-то ПО, вы всегда можете загрузить его исходный код (обычно — с помощью git), изменить и запустить модифицированную версию. Такой подход позволяет достичь цели, но только тогда, когда это возможно, и когда вы используете для этой цели свою домашнюю директорию. Однако, если приложение нуждается в установке, делающей его доступным во всей системе (например, с использованием make install), тогда оно замусорит файловую систему файлами, неизвестными dpkg, и скоро станет источником проблем, которые невозможно обнаружить, основываясь на анализе зависимостей пакета. Более того, правильно подготовленные пакеты можно передавать кому-нибудь ещё, их гораздо легче разворачивать на множестве компьютеров, или отменять в них изменения после того, как обнаружилось, что они не дают нужного эффекта.

Итак, когда может понадобится модификация пакетов? Рассмотрим несколько примеров.

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

Вот ещё одна ситуация. Скажем, вам не удаётся заставить работать карту MIFARE NFC и вы хотите пересобрать libfreefare для того, чтобы включить отладочные сообщения и получить некие осмысленные данные, которые можно включить в отчёт об ошибках, который вы готовите.

И, наконец, представим, что программа pyrit вылетает с таинственным сообщением об ошибке. После поиска в интернете вы обнаруживаете коммит в Git-репозитории разработчиков, который, как вам кажется, может исправить эту проблему. Далее, вы собираетесь пересобрать пакет, включив в него найденное исправление.

Мы подробно рассмотрим эти ситуации ниже и постараемся обобщить объяснения таким образом, чтобы вы могли воспользоваться представленными методиками и в других случаях. Однако, надо понимать, что невозможно рассказать обо всём, с чем вы можете столкнуться. Если вы встретились с проблемой, постарайтесь найти решение или обратитесь за помощью на подходящие форумы (подробнее об этом можно почитать в Главе 6, которая рассказывает о том, как искать ответы на сложные вопросы).

Какими бы ни были изменения, которые вы хотите внести в пакет, общая последовательность действий всегда остаётся одной и той же. А именно, нужно загрузить исходный код пакета, распаковать его, внести изменения и собрать пакет. Однако, на каждом из этих шагов обычно можно воспользоваться множеством инструментов, предназначенных для решения одной и той же задачи. Здесь мы отобрали наиболее подходящие и наиболее популярные инструменты, однако, надо отметить, что есть и другие отличные средства, о которых мы здесь не пишем.

9.1.1. Загрузка исходного кода


Пересборка пакета Kali начинается с загрузки исходного кода. Пакет с исходным кодом состоит из множества файлов. Главный файл — это *.dsc (Debian Source Control), он содержит список сопутствующих файлов, среди которых могут быть файлы *.tar.{gz,bz2,xz}, иногда — файлы *.diff.gz, или *.debian.tar.{gz,bz2,xz}.

Пакеты с исходным кодом хранятся на зеркалах Kali, работать с которыми можно по HTTP. Вы можете воспользоваться браузером для загрузки необходимых файлов, но самый лёгкий способ решить эту задачу заключается в вызове команды apt source source_package_name. Эта команда требует строки deb-src в файле /etc/apt/sources.list и актуальных индексных файлов (для их обновления можно воспользоваться командой apt update). По умолчанию в Kali вышеописанные настройки не включены, так как очень немногим пользователям нужен исходный код пакетов, но привести всё в нужное состояние очень просто. Для этого надо добавить строку deb-src в файл /etc/apt/sources.list (сведения об этом можно найти в разделе 8.1.3 «Репозитории Kali», и в разделе 8.1.2. «Подробности о файле sources.list»).

$ apt source libfreefare
Reading package lists... Done
NOTICE: 'libfreefare' packaging is maintained in the 'Git' version control system at:
git://anonscm.debian.org/collab-maint/libnfc.git
Please use:
git clone git://anonscm.debian.org/collab-maint/libnfc.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 119 kB of source archives.
Get:1 http://archive-2.kali.org/kali kali-rolling/main libfreefare 0.4.0-2 (dsc) [2,090 B]
Get:2 http://archive-2.kali.org/kali kali-rolling/main libfreefare 0.4.0-2 (tar) [113 kB]
Get:3 http://archive-2.kali.org/kali kali-rolling/main libfreefare 0.4.0-2 (diff) [3,640 B]
Fetched 119 kB in 1s (63.4 kB/s)
gpgv: keyblock resource '/home/rhertzog/.gnupg/trustedkeys.gpg': file open error
gpgv: Signature made Tue 04 Mar 2014 06:57:36 PM EST using RSA key ID 40AD1FA6
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./libfreefare_0.4.0-2.dsc
dpkg-source: info: extracting libfreefare in libfreefare-0.4.0
dpkg-source: info: unpacking libfreefare_0.4.0.orig.tar.gz
dpkg-source: info: unpacking libfreefare_0.4.0-2.debian.tar.xz
$ cd libfreefare-0.4.0
$ ls
AUTHORS    CMakeLists.txt  COPYING   HACKING            m4           README
ChangeLog  configure.ac    debian    libfreefare        Makefile.am  test
cmake      contrib         examples  libfreefare.pc.in  NEWS         TODO
$ ls debian
changelog  copyright                libfreefare-dev.install  rules
compat     libfreefare0.install     libfreefare-doc.install  source
control    libfreefare-bin.install  README.Source            watch


В этом примере мы загружаем пакет с исходным кодом с зеркала Kali. Это — такой же пакет, как и в Debian, так как строка версии не содержит подстроки «kali.». Это означает, что в данный пакет не было внесено каких-либо специфичных для Kali изменений.

Если вам нужна конкретная версия пакета с исходным кодом, которая на момент загрузки недоступна в репозиториях, перечисленных в /etc/apt/sources.list, в таком случае легче всего загрузить её, предварительно выяснив URL её .dsc-файла, найдя его на http://pkg.kali.org и использовав его в команде dget (из пакета devscripts).

После нахождения URL для пакета с исходным кодом libfreefare, доступного в kali-bleeding-edge, вы можете загрузить его с помощью dget. Сначала будет загружен файл .dsc, после чего он будет разобран для того, чтобы выяснить, на какие ещё файлы он ссылается, затем будут загружены и эти файлы: 

$ dget http://http.kali.org/pool/main/libf/libfreefare/libfreefare_0.4.0+0~git1439352548.ffde4d-1.dsc
dget: retrieving http://http.kali.org/pool/main/libf/libfreefare/libfreefare_0.4.0+0~git1439352548.ffde4d-1.dsc
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   364  100   364    0     0    852      0 --:--:-- --:--:-- --:--:--   854
100  1935  100  1935    0     0   2650      0 --:--:-- --:--:-- --:--:-- 19948
dget: retrieving http://http.kali.org/pool/main/libf/libfreefare/libfreefare_0.4.0+0~git1439352548.ffde4d.orig.tar.gz
[...]
dget: retrieving http://http.kali.org/pool/main/libf/libfreefare/libfreefare_0.4.0+0~git1439352548.ffde4d-1.debian.tar.xz
[...]
libfreefare_0.4.0+0~git1439352548.ffde4d-1.dsc:
dscverify: libfreefare_0.4.0+0~git1439352548.ffde4d-1.dsc failed signature check:
gpg: Signature made Wed Aug 12 06:14:03 2015 CEST
gpg:                using RSA key 43EF73F4BD8096DA
gpg: Can't check signature: No public key
Validation FAILED!!
$ dpkg-source -x libfreefare_0.4.0+0~git1439352548.ffde4d-1.dsc
gpgv: Signature made Wed Aug 12 06:14:03 2015 CEST
gpgv:                using RSA key 43EF73F4BD8096DA
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./libfreefare_0.4.0+0~git1439352548.ffde4d-1.dsc
dpkg-source: info: extracting libfreefare in libfreefare-0.4.0+0~git1439352548.ffde4d
dpkg-source: info: unpacking libfreefare_0.4.0+0~git1439352548.ffde4d.orig.tar.gz
dpkg-source: info: unpacking libfreefare_0.4.0+0~git1439352548.ffde4d-1.debian.tar.xz


Стоит отметить, что dget не выполняет автоматическую распаковку пакетов с исходным кодом, так как он не может проверить PGP-подписи этих пакетов. Таким образом, нам нужно выполнить это вручную, воспользовавшись командой dpkg-source -x dsc-file. Кроме того, вы можете активировать принудительное извлечение пакетов с исходным кодом, применив опцию --allow-unauthenticated или -u. И наоборот, можно воспользоваться опцией --download-only для того, чтобы пропустить шаг распаковки.

▍Загрузка исходного кода из Git


Вы могли обратить внимание на то, что при вызове apt source вам сообщают о возможности использования Git-репозитория для поддержки пакета. Это может быть репозиторий Debian или репозиторий Kali.

Все пакеты, специально подготовленные для Kali, можно обнаружить в Git-репозиториях, расположенных на git.kali.org. Загрузить код из этих репозиториев можно с помощью команды вида git clone git://git.kali.org/packages/source-package. Если при выполнении этой команды то, что нужно, загрузить не удаётся, попробуйте переключиться на ветку kali/master командой git checkout kali/master.

В отличие от того, что можно загрузить с помощью команды apt source, в полученном дереве не будут автоматически применены патчи. Взгляните на debian/patches/ для того, чтобы узнать о возможных изменениях, сделанных в Kali.

$ git clone git://git.kali.org/packages/kali-meta
Cloning into 'kali-meta'...
remote: Counting objects: 760, done.
remote: Compressing objects: 100% (614/614), done.
remote: Total 760 (delta 279), reused 0 (delta 0)
Receiving objects: 100% (760/760), 141.01 KiB | 0 bytes/s, done.
Resolving deltas: 100% (279/279), done.
Checking connectivity... done.
$ cd kali-meta
$ ls
debian
$ ls debian
changelog  compat  control  copyright  rules  source

Вы можете использовать Git-репозитории как альтернативный способ загрузки исходного кода и, в целом, следовать другим рекомендациям из этого раздела. Но когда разработчики Kali работают с этими репозиториями, они используют другой процесс подготовки пакетов и инструменты из пакета git-buildpackage, о которых мы здесь не рассказываем. Подробности об этих инструментах можно найти здесь.


9.1.2. Установка зависимостей для сборки


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

В каждом пакете исходного кода зависимости сборки объявлены в поле Build-Depends файла debian/control. Используем apt для установки этих зависимостей (предполагается, что вы находитесь в директории, содержащей распакованный пакет с исходным кодом): 

$ sudo apt build-dep ./
Note, using directory './' to get the build dependencies
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  autoconf automake autopoint autotools-dev debhelper dh-autoreconf
  dh-strip-nondeterminism gettext intltool-debian libarchive-zip-perl
  libfile-stripnondeterminism-perl libtool po-debconf
0 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
Need to get 4 456 kB of archives.
After this operation, 14,6 MB of additional disk space will be used.
Do you want to continue? [Y/n]
[…]


В этом примере все зависимости сборки можно разрешить с помощью пакетов, которые доступны APT. Так может быть не всегда, так как инструменты сборки kali-rolling не проверяют возможность установки зависимостей сборки (во внимание принимаются только зависимости бинарных пакетов). На практике бинарные зависимости и зависимости сборки часто тесно связаны и для большинства пакетов достаточно зависимостей сборки.

9.1.3. Внесение изменений в код пакетов


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

Первое, что надо сделать, заключается в изменении номера версии пакета. Это нужно для того, чтобы новые пакеты можно было отличить от исходных, присутствующих в Kali или Debian. Для того, чтобы это сделать, мы обычно добавляем суффикс, идентифицирующий того, кто выполняет изменения (обычно это частное лицо или компания). Так, например, мой ник в IRC — buxy, поэтому я буду использовать его как суффикс. Подобное изменение лучше всего производить с помощью команды dch (Debian CHangelog) из пакета devscripts. В моём случае вызов этой команды будет выглядеть как dch --local buxy. Эта команда вызывает текстовой редактор (sensible-editor, который запускает редактор, указанный в переменной окружения VISUAL или EDITOR, в противном случае вызывается /usr/bin/editor), который позволяет задокументировать изменения, вносимые в конкретную сборку. В данном случае видно, что команда dch действительно изменила файл debian/changelog: 

$ head -n 1 debian/changelog
libfreefare (0.4.0-2) unstable; urgency=low
$ dch --local buxy
[...]
$ head debian/changelog
libfreefare (0.4.0-2buxy1) UNRELEASED; urgency=medium

  * Enable --with-debug configure option.

 -- Raphael Hertzog  Fri, 22 Apr 2016 10:36:00 -0400

libfreefare (0.4.0-2) unstable; urgency=low

  *  Update debian/copyrtight.
     Fix license to LGPL3+.


Если вы выполняете подобные изменения регулярно, возможно, есть смысл внести в переменные окружения DEBFULLNAME и DEBEMAIL, соответственно, ваше полное имя и адрес электронной почты. Эти данные могут быть использованы множеством инструментов для работы с пакетами, включая dch, который внедрил их в строку, начинающуюся с »--» в вышеприведённом коде.

▍9.1.3.1. Применение патчей


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

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

▍9.1.3.1.1. Применение патча к распакованному пакету с исходным кодом


Итак, вы выполнили команду apt source pyrit и у вас есть папка pyrit-0.4.0. В такой ситуации можно применить патч напрямую, воспользовавшись командой patch -p1< patch-file: 

$ apt source pyrit
[...]
$ cd pyrit-0.4.0
$ wget https://github.com/JPaulMora/Pyrit/commit/14ec997174b8e8fd20d22b6a97c57e19633f12a0.patch -O /tmp/pyrit-patch
[...]
$ patch -p1


К этому моменту у вас имеется исходный код, пропатченный вручную, и вы можете собрать бинарный файл модифицированной версии пакета (о сборке мы поговорим ниже, в разделе 9.1.4). Но если вы попытаетесь собрать обновлённый пакет, произойдёт ошибка, в сообщении которой говорится о неожиданных изменениях кода пакета, подготовленного его разработчиками (unexpected upstream changes). Это произошло из-за того, что pyrit (как и большинство пакетов с исходным кодом) использует формат исходного кода (взгляните на файл debian/source/format), известный как 3.0 (quilt), где изменения в коде, вносимые разработчиками пакета, должны быть записаны в отдельных патчах, хранимых в debian/patches/, при этом файл debian/patches/series указывает на порядок, в котором эти патчи должны быть применены. Вы можете зарегистрировать внесённые изменения в виде нового патча, воспользовавшись командой dpkg-source --commit: 

$ dpkg-source --commit
dpkg-source: info: local changes detected, the modified files are:
 pyrit-0.4.0/cpyrit/pckttools.py
Enter the desired patch name: fix-for-scapy-2.3.patch
dpkg-source: info: local changes have been recorded in a new patch: pyrit-0.4.0/debian/patches/fix-for-scapy-2.3.patch
$ tail -n 1 debian/patches/series
fix-for-scapy-2.3.patch


▍Управление патчами с помощью quilt


Соглашение по работе с патчами, о котором идёт речь, стало популярным благодаря инструменту, который называется quilt. Формат пакета исходного кода »3.0 (quilt)», таким образом, совместим с этим инструментом — с небольшим изменением, которое заключается в том, что он использует debian/patches вместо patches. Этот инструмент можно найти в одноимённом пакете. Здесь можно почитать руководство по нему.


Если пакет с исходным кодом использует формат 1.0 или 3.0 (native), тогда требования по регистрации изменений в коде пакетов в виде патчей не выдвигаются. Сведения об изменениях автоматически встраиваются в получившийся пакет с исходным кодом.

▍9.1.3.1.2. Применение патча к коду, полученному из Git-репозитория


Если вы, для загрузки исходного кода, воспользовались Git, то ситуация осложняется. Существует множество способов организации работы с Git и связанных с ними инструментов, и совершенно очевидно то, что далеко не все Debian-пакеты готовят с использованием одних и тех же рабочих процессов и программных средств. Уже обсуждённое различие пакетов, касающееся формата файлов, применимо и здесь, но, работая с Git, необходимо выяснить, применены ли уже патчи в дереве исходного кода, или они лишь хранятся в debian/patches (при таком подходе они применяются в ходе сборки).

В данной ситуации самый популярный пакет — это git-buildpackage. Именно его мы используем для управления репозиториями на git.kali.org. Когда вы используете его, патчи не применяются предварительно в дереве исходного кода, вместо этого они хранятся в debian/patches. Вы можете вручную добавить патчи в эту директорию и внести их список в debian/patches/series, но пользователи git-buildpackage обычно применяют средство gbp pq для редактирования всей последовательности патчей как одной ветки, которую вы можете расширить или перекомпоновать в соответствии со своими потребностями. Посмотрите справку по gbp-pq(1) для того, чтобы разобраться с тем, как это сделать.

Инструмент git-dpm (и команда с тем же именем) — это ещё одно средство для работы с пакетами в Git, с которым вы можете встретиться. Оно записывает метаданные в debian/.git-dpm и поддерживает в актуальном состоянии патчи в дереве исходного кода, используя команду rebase в применении к ветке которую оно собирает из содержимого debian/patches.

▍9.1.3.2. Настройка параметров сборки


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

В подобных случаях изменения обычно ограничены debian/rules, где задаётся последовательность шагов процесса сборки пакета. В самых простых случаях строки, относящиеся к исходной конфигурации (./configure …), или сами команды сборки ($(MAKE) … или make …) найти несложно. Если эти команды не вызываются непосредственно, вероятно, их вызов выполняется через другие команды, вызываемые явно. В подобных случаях стоит обратиться к документации этих команд для того, чтобы узнать о том, как изменить их стандартное поведение. При работе с пакетами, которые используют dh, вам может понадобиться переопределить команды dh_auto_configure или dh_auto_build (посмотрите справку по ним для того, чтобы узнать о том, как это сделать).

Для того, чтобы приблизить эти объяснения к практике, применим их к одному из вышеупомянутых сценариев. А именно, мы собираемся модифицировать libfreefare, передав опцию --enable-debug скрипту ./configure для того, чтобы в результате можно было получить больше сведений от инструментов для работы с NFC и подготовить более качественный отчёт по карте MIFARE NFC, которую не удаётся распознать. Так как пакет, для управления процессом сборки, использует dh, нужно добавить (или, в данном случае, модифицировать) цель override_dh_auto_configure. Вот соответствующее извлечение из файла debian/rules libfreefare: 

override_dh_auto_configure:
	
dh_auto_configure -- --without-cutter --disable-silent-rules --enable-debug


▍9.1.3.3. Упаковка новой официальной версии пакета


Взглянем на ещё один пример, так как мы говорим об упаковке официальных версий пакетов. Скажем, вы — опытный пользователь SET и заметили, что вышел новый официальный релиз (7.4.5), который пока недоступен в Kali (тут имеется лишь версия 7.4.4). Вам хочется собрать и опробовать обновлённый официальный пакет. Так как произошло лишь небольшое увеличение версии пакета, вы не ожидаете, что изменение потребует каких-либо изменений на уровне упаковки.

Для того, чтобы обновить код, вы извлекаете новый архив рядом с текущим пакетом с исходным кодом и копируете директорию debian из текущего пакета в новый. Затем вы увеличиваете версию в debian/changelog.

$ apt source set
Reading package lists... Done
NOTICE: 'set' packaging is maintained in the 'Git' version control system at:
git://git.kali.org/packages/set.git
Please use:
git clone git://git.kali.org/packages/set.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 42.3 MB of source archives.
[...]
dpkg-source: warning: failed to verify signature on ./set_7.4.4-0kali1.dsc
dpkg-source: info: extracting set in set-7.4.4
dpkg-source: info: unpacking set_7.4.4.orig.tar.gz
dpkg-source: info: unpacking set_7.4.4-0kali1.debian.tar.xz
dpkg-source: info: applying edit-config-file
dpkg-source: info: applying fix-path-interpreter.patch
$ wget https://github.com/trustedsec/social-engineer-toolkit/archive/7.4.5.tar.gz -O set_7.4.5.orig.tar.gz
[...]
$ tar xvf set_7.4.5.orig.tar.gz
[...]
social-engineer-toolkit-7.4.5/src/wireless/wifiattack.py
$ cp -a set-7.4.4/debian social-engineer-toolkit-7.4.5/debian
$ cd social-engineer-toolkit-7.4.5
$ dch -v 7.4.5-0buxy1 "New upstream release"


Вот и всё. Теперь можно собрать обновлённый пакет.

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

9.1.4. Запуск сборки


Когда в исходный код пакета внесены все необходимые изменения, вы можете приступить к созданию бинарных файлов в формате .deb. Весь этот процесс проходит под управлением команды dpkg-buildpackage и выглядит так: 

$ dpkg-buildpackage -us -uc -b
dpkg-buildpackage: source package libfreefare
dpkg-buildpackage: source version 0.4.0-2buxy1
dpkg-buildpackage: source distribution UNRELEASED
dpkg-buildpackage: source changed by Raphael Hertzog
dpkg-buildpackage: host architecture amd64
[...]
   dh_builddeb
dpkg-deb: building package 'libfreefare0-dbgsym' in '../libfreefare0-dbgsym_0.4.0-2buxy1_amd64.deb'.
dpkg-deb: building package 'libfreefare0' in '../libfreefare0_0.4.0-2buxy1_amd64.deb'.
dpkg-deb: building package 'libfreefare-dev' in '../libfreefare-dev_0.4.0-2buxy1_amd64.deb'.
dpkg-deb: building package 'libfreefare-bin-dbgsym' in '../libfreefare-bin-dbgsym_0.4.0-2buxy1_amd64.deb'.
dpkg-deb: building package 'libfreefare-bin' in '../libfreefare-bin_0.4.0-2buxy1_amd64.deb'.
dpkg-deb: building package 'libfreefare-doc' in '../libfreefare-doc_0.4.0-2buxy1_all.deb'.
 dpkg-genchanges -b >../libfreefare_0.4.0-2buxy1_amd64.changes
dpkg-genchanges: binary-only upload (no source code included)
 dpkg-source --after-build libfreefare-0.4.0
dpkg-buildpackage: binary-only upload (no source included)


Опции -us -uc отключают подписи для некоторых из сгенерированных файлов (.dsc, .changes), так как эта операция даст сбой если у вас нет ключей GnuPG, связанных с идентификационными данными, помещёнными в файл changelog. Опция -b предназначена для организации процесса сборки, на выходе которого оказываются только бинарные файлы. При таком подходе не создаётся пакет с исходным кодом (.dsc), а создаются только бинарные .deb-пакеты. Используйте эту опцию для того, чтобы избежать сбоев на этапе сборки пакетов с исходным кодом: если вы не зарегистрировали соответствующим образом изменения в системе управления патчами, в ходе этой операции могут возникнуть предупреждения и процесс сборки будет прерван.

Как можно узнать из сообщений dpkg-deb, созданные бинарные пакеты теперь доступны в родительской директории (в той, в которой находится директория пакета с исходным кодом). Устанавливают такие пакеты с использованием команды dpkg -i или apt install.

$ sudo apt install ../libfreefare0_0.4.0-2buxy1_amd64.deb 
  ../libfreefare-bin_0.4.0-2buxy1_amd64.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libfreefare0' instead of '../libfreefare0_0.4.0-2buxy1_amd64.deb'
Note, selecting 'libfreefare-bin' instead of '../libfreefare-bin_0.4.0-2buxy1_amd64.deb'
The following packages will be upgraded:
  libfreefare-bin libfreefare0
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/69,4 kB of archives.
After this operation, 2 048 B of additional disk space will be used.
[...]


Мы предпочитаем использовать apt install, а не dpkg -i, так как apt позволяет легко справляться с проблемой отсутствующих зависимостей. Правда, не так давно приходилось использовать dpkg, так как команда apt не могла работать с .deb-файлами, которые расположены вне репозиториев.

▍Программы-оболочки для dpkg-buildpackage


Чаще всего Debian-разработчики, для сборки пакетов, используют программы-оболочки вроде debuild. Эта программа, например, запускает dpkg-buildpackage как обычно, но, кроме того, вызывает скрипт (lintian), который выполняет множество проверок сгенерированного пакета на соответствие правилам Debian. Этот скрипт, кроме того, очищает окружение, в результате локальные переменные окружения не могут повлиять на процесс сборки пакета. Команда debuild — это один из инструментов, входящих в состав пакета devscripts, инструменты которого, за счёт единообразия, облегчают жизнь тем, кто занимается поддержкой пакетов.


Итоги


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

Уважаемые читатели! Сталкивались ли вы с ситуациями, когда вам нужно было модифицировать и самостоятельно собирать пакеты для Linux? Если да — расскажите пожалуйста, зачем вам это было нужно и какими инструментами вы при этом пользовались.

Предыдущие части:

→ Часть 1. Kali Linux: политика безопасности, защита компьютеров и сетевых служб
→ Часть 2. Kali Linux: фильтрация трафика с помощью netfilter
→ Часть 3. Kali Linux: мониторинг и логирование
→ Часть 4. Kali Linux: упражнения по защите и мониторингу системы
→ Часть 5. Kali Linux: оценка защищённости систем
→ Часть 6. Kali Linux: виды проверок информационных систем
→ Часть 7. Kali Linux: формализация исследований и типы атак
→ Часть 8. Kali Linux: контрольные вопросы по исследованию защищённости систем

© Habrahabr.ru