Как подписать репозиторий debian. Как сделать?

Несмотря на то, что в официальных репозиториях Debian можно найти почти всё, что может понадобиться, иногда всё-таки приходится самостоятельно собирать пакеты. Я стараюсь не замусоривать систему программами, установленными из исходных текстов и модулями различных языков программирования, установленными через их стандартные инструменты, вроде cpan, pip или gem.

Собирать пакеты приходится по нескольким причинам:

• В репозитории нет нужного пакета. Иногда бывает можно найти неофициальные репозитории для нужного релиза операционной системы.
• Через репозитории дистрибутива доступна только старая версия пакета, в которой не хватает нужных функций. В этом случае иногда помогают официальные репозитории backport с более свежими версиями пакетов, собранными для предыдущих релизов операционной системы.
• В пакете из репозитория есть ошибка. Даже в стабильном дистрибутиве встречаются ошибки, которые не исправляются ментейнерами. Тут придётся либо обновлять пакет, либо исправлять в нём ошибку.
• В репозитории есть нужная версия пакета, но собранная без поддержки определённой функции. Тут без вариантов — нужно дорабатывать и пересобирать пакет.

Например, в 2013 году я начал настраивать на работе серверы под Debian Wheezy. С тех пор у меня накопилось некоторое количество самосборных пакетов:

• python-grab — не было в репозитории
• python-flask-httpauth — не было в репозитории
• python-pycurl — не было в репозитории
• libdancer-plugin-database-core-perl — не было в репозитории
• libnet-ssh-expect-perl — не было в репозитории
• wordpress-plugin-simple-ldap-login — не было в репозитории
• python-mysqldb — модуль версии 1.2.3 заменён на более свежую версию 1.2.5 из-за некорректной работы с collation utf8_bin: python-mysqldb: utf8_bin collation will not convert to Unicode strings
• libsnmp и компания — пакеты были пересобраны из-за того, что не все производители оборудования с поддержкой SNMPv3 обеспечивают монотонный рост счётчика количества перезагрузок и времени с момента перезагрузки: Стандарт SNMPv3 и суровая действительность USM_TIME_WINDOW
• python-netsnmp — модуль пересобран из-за ошибки в формировании SET-запросов со значениями типа IPv4: Исправление Python-прослойки библиотеки Net-SNMP
• php5 и компания — среди этих пакетов был пакет php5-snmp, зависящий от пакета libsnmp
• openntpd — в пакете была иcправлена ошибка в обработке таймаута ответов от серверов DNS: Таймаут DNS в OpenNTPd
• uwsgi — включена поддержка Linux capabilities: Пересборка uwsgi с поддержкой Linux Capabilities
• zabbix — собрана более свежая версия пакета, наложена серия нестандартных патчей. Например, добавлены отдельные настройки таймаута и количества повторов для опроса по протоколу SNMP: Установка и настройка Zabbix 2.2.0 в Debian Wheezy
• python-paramiko и python-ecdsa — модуль paramiko 1.7.7.1-3.1 обновлён до версии 1.16.0-1, т.к. версия paramiko из репозитория имела ошибки в поддержке протокола SFTP: python-paramiko: sftp connections hangs. Модуль python-ecdsa был тоже обновлён, т.к. более новая версия модуля paramiko требовала и более свежую версию модуля ecdsa.

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

Есть масса способов собрать пакет для Debian:

• Можно доработать пакет с исходными текстами и собрать как новый пакет с исходными текстами, так и собрать из него новые двоичные пакеты.
• Для сборки пакетов с модулями python существует утилита python-stdeb: Создание deb-пакетов для модулей Python
• Для сборки пакетов с модулями perl существует утилита dh-make-perl.
• Можно попробовать сконвертировать готовый пакет из другого формата при помощи утилиты alien.
• Можно попробовать собрать пакет при помощи утилиты checkinstall.
• Наконец, можно просто создать пакет вручную при помощи утилиты dpkg-deb: 5.13 Как мне сделать собственный .deb пакет?

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

Когда утилита aptly ещё не попалась мне на глаза, я делал репозитории при помощи утилиты apt-ftparchive. Не помню подробностей, но точно помню, что была она не очень удобной в использовании.

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

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

# apt-get install aptly

Утилита написана на языке go, в скомпилированном виде тянет за собой минимум зависимостей: это утилиты для работы с архивами и утилиты для манипуляции GPG-подписями.

Создание локальных репозиториев

Список репозиториев пока пуст:

$ aptly repo list
No local repositories found, create one with `aptly repo create ...`.

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

$ aptly repo create stretch

Local repo [stretch] successfully added.
You can run 'aptly repo add stretch ...' to add packages to repository.

Добавление пакетов в локальный репозиторий

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

$ aptly repo add stretch *.deb
Loading packages...
[+] libauthen-radius-perl_0.26-1ufanet_all added
[+] libnet-ssh-expect-perl_1.09-1_all added
[+] zabbix-agent-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-agent_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-frontend-php_1:3.4.12-1+stretch-ufanet2_all added
[+] zabbix-get-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-get_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-java-gateway_1:3.4.12-1+stretch-ufanet2_all added
[+] zabbix-proxy-mysql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-proxy-mysql_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-proxy-pgsql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-proxy-pgsql_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-proxy-sqlite3-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-proxy-sqlite3_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-sender-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-sender_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-server-mysql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-server-mysql_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-server-pgsql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 added
[+] zabbix-server-pgsql_1:3.4.12-1+stretch-ufanet2_amd64 added

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

$ aptly repo add stretch *.dsc
Loading packages...
[+] libauthen-radius-perl_0.26-1ufanet_source added
[+] libnet-ssh-expect-perl_1.09-1_source added
[+] zabbix_1:3.4.12-1+stretch-ufanet2_source added

По умолчанию программа размещает пакеты и базу данных в каталоге ~/.aptly

Публикация локальных репозиториев

Список опубликованных репозиториев пока пуст:

$ aptly publish list
No snapshots/local repos have been published. Publish a snapshot by running `aptly publish snapshot ...`.

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

$ aptly publish repo stretch ncc
ERROR: unable to publish: unable to guess distribution name, please specify explicitly

Посмотрим текущие настройки репозитория:

$ aptly repo show stretch
Name: stretch
Comment: 
Default Distribution: 
Default Component: main
Number of packages: 23

Укажем дистрибутив репозитория:

$ aptly repo edit -distribution="stretch" stretch
Local repo [stretch] successfully updated.

Опубликуем дистрибутив без PGP-подписи:

$ aptly publish repo -skip-signing=true stretch ncc
Loading packages...
Generating metadata files and linking package files...
Finalizing metadata files...

Local repo stretch has been successfully published.
Please setup your webserver to serve directory '/home/stupin/.aptly/public' with autoindexing.
Now you can add following line to apt sources:
  deb http://your-server/ncc/ stretch main
  deb-src http://your-server/ncc/ stretch main
Don't forget to add your GPG key to apt with apt-key.

You can also use `aptly serve` to publish your repositories over HTTP quickly.

Посмотрим список опубликованных репозиториев:

$ aptly publish list Published repositories:

ncc/stretch [amd64, source] publishes {main: [stretch]}

Опубликованные репозитории находятся в каталоге ~/.aptly/public, откуда их можно скопировать и разместить на веб-сервере. В примере выше локальный репозиторий stretch был опубликован в каталоге ncc, поэтому найти его можно будет в каталоге ~/.aptly/public/ncc

Поиск и удаление пакетов из локального репозитория

Для поиска пакетов, в имени которых присутствует слово zabbix и версия которых выше 1:3.4, а также пакетов, в имени которых присутствует подстрока -perl, можно воспользоваться следующей командой:

$ aptly package search '(Name (~zabbix), Version (>1:3.4)) | Name (~-perl)'

Как видно, скобки используются для группировки выражений, запятая соответствует логическому И, вертикальная черта соответствует логическому ИЛИ. Тильда обозначает совпадение с регулярным выражением, знак больше используется в своём обычном смысле. Более подробно правила фильтрации описаны в документации на странице: Package queries.

Для удаления пакетов из репозиториев используются те же самые выражения, которые используются при поиске пакетов. Например, удалим все пакеты, в имени которых присутствует подстрока zabbix:

$ aptly repo remove stretch 'Name (~zabbix)'
Loading packages...
[-] zabbix-proxy-mysql_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-proxy-mysql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-sender-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-proxy-sqlite3-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-server-mysql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix_1:3.4.12-1+stretch-ufanet2_source removed
[-] zabbix-java-gateway_1:3.4.12-1+stretch-ufanet2_all removed
[-] zabbix-server-pgsql_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-agent-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-proxy-pgsql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-server-mysql_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-get_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-frontend-php_1:3.4.12-1+stretch-ufanet2_all removed
[-] zabbix-sender_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-get-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-server-pgsql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-agent_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-proxy-sqlite3_1:3.4.12-1+stretch-ufanet2_amd64 removed
[-] zabbix-proxy-pgsql_1:3.4.12-1+stretch-ufanet2_amd64 removed

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

$ aptly repo remove stretch 'Name (~-perl)'
Loading packages...
[-] libnet-ssh-expect-perl_1.09-1_all removed
[-] libauthen-radius-perl_0.26-1ufanet_source removed
[-] libauthen-radius-perl_0.26-1ufanet_all removed
[-] libnet-ssh-expect-perl_1.09-1_source removed

Перемещение пакетов между локальными репозиториями

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

Например, вот так можно выполнить перемещение всех пакетов, у которых в версии фигурирует подстрока stretch, из репозитория wheezy в репозиторий stretch:

$ aptly repo move wheezy stretch 'Version (~stretch)'
Loading packages...
[o] zabbix-server-pgsql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-sender_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-proxy-pgsql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-get-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-server-pgsql_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-proxy-pgsql_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-frontend-php_1:3.4.12-1+stretch-ufanet2_all moved
[o] zabbix-get_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-proxy-sqlite3-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-proxy-mysql_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-server-mysql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-java-gateway_1:3.4.12-1+stretch-ufanet2_all moved
[o] zabbix-server-mysql_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-sender-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-proxy-sqlite3_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-agent-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-agent_1:3.4.12-1+stretch-ufanet2_amd64 moved
[o] zabbix-proxy-mysql-dbgsym_1:3.4.12-1+stretch-ufanet2_amd64 moved

Обновление опубликованного репозитория

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

$ aptly publish update -skip-signing=true stretch ncc
Loading packages...
Generating metadata files and linking package files...
Finalizing metadata files...
Cleaning up prefix "ncc" components main...
Publish for local repo ncc/stretch [amd64, source] publishes {main: [stretch]} has been successfully updated.

Удаление устаревших пакетов

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

$ aptly db cleanup
Loading mirrors, local repos, snapshots and published repos...
Loading list of all packages...
Deleting unreferenced packages (23)...
Building list of files referenced by packages...
Building list of files in package pool...
Deleting unreferenced files (29)...
Disk space freed: 33.61 MiB...
Compacting database...

Удаление опубликованных репозиториев

Для удаления опубликованного репозитория можно воспользоваться соответствующей командой:

$ aptly publish drop stretch ncc
Removing /home/stupin/.aptly/public/ncc/dists...
Removing /home/stupin/.aptly/public/ncc/pool...

Published repository has been removed successfully.

Можно посмотреть в список опубликованных репозиториев и убедиться, что репозитория больше нет среди опубликованных:

$ aptly publish list
No snapshots/local repos have been published. Publish a snapshot by running `aptly publish snapshot ...`.

Удаление локального репозитория

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

$ aptly repo list
List of local repos:
 * [stretch] (packages: 0)

To get more information about local repository, run `aptly repo show <name>`.

Как видно, в репозитории нет пакетов, поэтому его можно удалить.

Для удаления локального репозитория stretch можно воспользоваться такой командой:

$ aptly repo drop stretch
Local repo `stretch` has been removed.

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

$ aptly repo list
No local repositories found, create one with `aptly repo create ...`.

P. S.

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

Так, на работе всё тот же Debian Wheezy, который вышел в 2013 году, использовался мной аж до 2019 года. За это время успело выйти три новых релиза: Squeezy, Jessie, Stretch. Некоторые коллеги удивлялись, почему я продолжаю использовать этот устаревший релиз. Друге даже не догадывались об этом, т.к. им достаточно, чтобы обновлялся фасад здания, а с ржавыми трубами им дела иметь не приходилось. В 2018 году завершился срок продлённой поддержки Debian Wheezy. В 2019 году репозиторий пропал с зеркал и стало очевидно, что оттягивать обновление больше нельзя. Пришлось отложить всю текущую работу и заняться обновлениями, несмотря молчаливое и явное недовольство окружающих. Нельзя бесконечно копить технический долг — иногда нужно его возвращать.

У начинающих пользователей Linux часто возникает вопрос, каким же образом установить какое-либо программное обеспечение (ПО), которого нет в стандартных репозиториях дистрибутива? Такая необходимость возникает по нескольким причинам. Например, необходимо использовать самую актуальную версию ПО в то время как в репозиториях всё ещё имеется более старая. Или же нужно использовать экзотические программные продукты, поддержка которых изначально не предусмотрена разработчиками дистрибутива. В данной статье будет изложено на некоторых примерах, каким образом добавлять репозитории в Linux и устанавливать стороннее ПО для Debian-систем, таких, как Ubuntu.

Как известно, философия распространения и поддержки ПО в Linux основана на репозиториях — специализированных хранилищах пакетов, содержащих файлы какого-либо ПО. Эти хранилища могут быть как удалёнными, так и локальными. Практически любой дистрибутив Linux снабжается стандартными репозиториями. Которые, в свою очередь, содержат ПО, собранное, оптимизированное и протестированное для данного дистрибутива. Доступ к репозиториям осуществляется с помощью систем управления пакетами (СУП), также специфичными для каждого дистрибутива. Например, для систем Ubuntu, да и вообще для Debian-ориентированных дистрибутивов в качестве стандартной СУП является утилита APT. Любая СУП позволяет (во всяком случае должна) искать, устанавливать, удалять пакеты, очищать их конфигурацию, определять зависимости и как не трудно догадаться — добавлять и удалять репозитории. Для всех перечисленных задач можно использовать как командную оболочку, так и графические утилиты с удобным и наглядным пользовательским интерфейсом.

Для обеспечения безопасности пользователей репозитории должны подписываться ключами шифрования. Чтобы гарантировать, что установка пакетов ПО производится из надёжного источника. Владельцы репозиториев, подписав его своим закрытым ключом, выкладывают в общий доступ соответствующий открытый ключ для этого репозитория. Открытый ключ необходим для добавления удалённого подписанного репозитория, это контролируется средствами СУП. Как правило, открытый ключ необходимо импортировать отдельно. На первый взгляд это не очевидно, однако необходимо для обеспечения безопасности системы.

Добавление репозиториев в командной оболочке

Как это ни странно, но эффективнее и удобнее производить управление репозиториями из командной оболочки. Как правило, в Debian-системах используется СУП APT, поэтому все представляемые далее команды будут относиться к этой системе управления пакетами.

Пусть требуется добавить репозиторий для загрузки и установки интегрированной среды разработки «CodeLite». Информацию о репозитории и даже исчерпывающие инструкции по его настройке в системе приведены на официальной странице Wiki проекта. Итак, с помощью команды apt-add-repository (используя sudo) нужно добавить адрес репозитория. Эта команда попытается добавить соответствующую запись в файл /etc/apt/sources.list:

$ sudo apt-add-repository 'deb https://repos.codelite.org/ubuntu/ bionic universe'

Здесь следует обратить внимание на ту часть записи, в которой указывается версия дистрибутива (bionic), в данном случае это Ubuntu 18.04 Bionic Beaver. Для каждой из версий существуют свои особенности в сборке ПО и формировании для неё пакетов. Обычно разработчики делают сборки для нескольких версий дистрибутивов и указывают соответствующие ссылки для них. Это следует учитывать, иначе пакеты могут быть некорректно установлены.
Далее необходимо обновить индекс базы данных состояния пакетов, поскольку был добавлен новый репозиторий:

$ sudo apt-get update

Теперь можно установить и сам пакет codelite:

$ sudo apt-get install codelite

В данном примере намеренно сначала добавляется репозиторий без импорта открытого ключа, чтобы продемонстрировать, что в случае отсутствия такого ключа APT заблокирует установку пакетов. При этом будет выдано соответствующее сообщение, предупреждающее, что репозиторий является непроверенным. О том, как добавлять ключи при настройке репозиториев, рассказывается в главе «Добавление ключей подписей репозиториев».

Как можно видеть, в данном случае выбрана ветка репозитория для версии Ubuntu 18.04 и соответствующие ей ссылки для загрузки готовых пакетов (и если нужно, также и архивов с исходными кодами) необходимо добавлять в файл /etc/apt/sources.list. Также указан отпечаток (Fingerprint — открытый ключ) для данного репозитория.

Использование графических утилит

В данном случае добавление репозиториев происходит далеко не так быстро, как в консоли. Но для новичков и малоопытных пользователей данный способ гораздо более прост и нагляден. В Ubuntu существуют различные менеджеры пакетов, такие как Muon (в основном для KDE), Synaptic (для любых окружений рабочего стола), а также стандартная графическая утилита «Программы и обновления» для окружения Unity. Все перечисленные инструменты объединяет наличие в главном меню пункта для настройки «Источников ПО» или «Другого ПО». Например, для Muon это выглядит так:

Редактирование списка репозиториев в Muon:

То же самое, но с использованием Synaptic. Доступ к редактированию репозиториев осуществляется через меню «Настройки» и далее, пункт «Репозитории»:

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

Добавление ключей подписи репозиториев

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

Ошибка: http://ppa.launchpad.net jaunty Release: Следующие подписи не могут быть проверены, так как недоступен открытый ключ: NO_PUBKEY BE80FFE08E782DB0

Чтобы добавить нужный открытый ключ необходимы 3 вещи:

1. Сам ключ (или последние его 8 символов), в данном случае это BE80DFE08E782DB0;
2. Результат запроса к серверу ключей, на котором хранится закрытая часть ключа;
3. Данные для добавления в систему открытого ключа.

Для второго пункта необходимо выполнить команду gpg с ключом «—keyserver». В качестве адреса нужно передать «keyserver.ubuntu.com»:

$ gpg --keyserver keyserver.ubuntu.com --recv 8E782DB0
gpg: запрашиваю ключ 8E782DB0 с hkp сервера keyserver.ubuntu.com
gpg: ключ 8E782DB0: открытый ключ “Launchpad PPA for YaTools” импортирован
gpg: Всего обработано: 1
gpg: импортировано: 1 (RSA: 1)

Данный вывод говорит о том, что запрос выполнен успешно. И теперь все необходимые данные для формирования открытого ключа есть. Теперь необходимо из данного набора данных выполнить экспорт открытой части ключа. И далее, добавить её в базу СУП APT. Это выполняется двумя командами, но удобнее их объединить сразу в один конвейер:

$ gpg --export --armor 8E782DB0 | sudo apt-key add –-

Теперь ключ добавлен и СУП сможет работать с репозиторием. Как видно, для добавления ключа использовалась команда APT apt-key add.
В заключение важно отметить, что при работе с ключами активно используется утилита gpg. Её значение для обеспечения безопасности и защиты данных среди свободных инструментов сложно переоценить. Умение работать с GPG, как можно видеть, существенно упрощает и работу с APT.

Читайте также:  Latest pending version

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Мы научились собирать пакеты и подписывать их. Теперь самое время сделать свой репозиторий с пакетами.

По сути, есть 3 способа (более или менее «легальных») способа собрать свой репозиторий: dpkg-scanpackages, mini-dinstall и reprepo. dpkg-scanpackages — достаточно простая тулза, но требует много ручной работы. Я хоть и напишу про неё, но использовать её в промышленных масштабах не стоит. С reprepo я особенно не разобрался — официальная документация старовата и далека от вменяемости. Так что в основном здесь написано про mini-dinstall.

dpkg-scanpackages — утилита, которая индексирует каталог и создаёт для него файл Packages. Эту тулзу можно использовать как временную локальную замену (чтобы, например, проверить, что пакеты будут ставиться через apt-get), но не нужно использовать её там, где важна проверка подписи пакетов — dpkg-scanpackages сам по себе этого просто не умеет (хотя и можно подписывать репозиторий лапками).

Сам dpkg-scanpackages живет в пакете dpkg-dev, так что:

Тогда мы генерируем Packages.gz следующим образом:

Проверяем, что репозиторий работает:

Так в простейшем виде работает и mini-dinstall — генерирует Packages.gz. Но он умеет проверять подписи пакетов, работать по крону/демоном и прочие плюшки.

Повеселились, хватит. Давайте ставить mini-dinstall и другой софт, который пригодится:

Дальше всё я буду расписывать исходя из того, что заливать пакеты в репозиторий будет несколько пользователей. Конечно, можно использовать dput и всё делать под одним пользователем, но если у вас полтора разработчика — то такой вариант вас уже не устроит и захочется предоставить возможность заливать пакеты с подписями разных разработчиков. Поэтому мы создадим отдельного пользователя и отдельный gpg-ключ, которым будем подписывать репозиторий. А подписи пакетов будем проверять перед тем, как добавить их в репозиторий.
Mini-dinstall незачем работать под рутом (если запустить его под рутом — нам не придется вводить целую дополнительную команду по выставлению вменяемых прав на каталог incoming, гы). Создадим отдельного пользователя:

Пойдем под этого пользователя:

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

Напишем конфиг /home/repokeeper/.mini-dinstall.conf для нашей собиралки репозиториев:

Генерируем ключ уже знакомой нам командой:

Что там отвечать уже написано, стоит только заметить, что нам нужен именно новый ключ, а не ключ с теми же ответами. Ну там ник и почту измените для приличия.

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

Сначала экспортируем публичный ключ репозитория. Под пользователем repokeeper делаем такое:

Так же экспортируем ключ, которым мы подписываем пакеты и «добавим его» в валидные ключи для repokeeper (разрешив тем самым заливать пакеты, подписанные тем ключом). Под пользователем, из-под которого мы собираем пакеты, выполняем команду:

(напомню, что свою почту я использовал в прошлом примере)
Файл inkvizitor68sl.gpg нам нужно закинуть в каталог /home/repokeeper/keys на том сервере, где у вас будет работать mini-dinstall. О правах на файлы можно не сильно беспокоиться (в конце концов, это публичная подпись — обладая ей хуже вам не сделают).

Теперь под пользователем repokeeper импортируем ключ «разработчика»:

Так же нам понадобится скрипт, который будет запускаться для подписывания собранного репозитория. Подходящий скрипт есть в документации к mini-dinstall, утащим его себе:

Немного подправим для своих нужд:

В файл ~/.gnupg/passphrase нужно написать пароль от GPG ключа, который мы сгенерировали для репозитория.

Так как мы запускаем mini-dinstall не от рута, нам нужны корректные права на его incoming-каталог. При помощи chmod/chown надежно добиться у нас этого не получится (разработчики обязательно будут заливать с такими правами, что у mini-dinstall не будет хватать прав на удаление залитых файлов — и он будет падать с ошибкой), посему сделаем это через acl:

А так же создадим группу, присутствие в которой будет позволять системным пользователям заливать пакеты на сервер (от рута):

И выставим права этим пользователям на каталог incoming:

И добавим пользователя, от которого собираем пакеты в группу аплоадеров. Точнее, добавим пользователя, которому мы хотим дать права на заливание файлов в репозиторий. Это может быть и аккаунт разработчика, который будет заливать пакеты по sftp/scp через dupload.

Заодно по дороге запретим заливать файлы всем остальным:

«Зальём» наш собранный ранее пакетик в репозиторий. Сейчас мы это делаем при помощи простого cp, в будущем я напишу о том, как использовать dupload.

Наконец-то запускаем сборку нашего репозитория (обратите внимание, не от рута):

Если ошибок не видно, то проверяем содержимое файла Packages:

Как видим, у нас в репозитории появился наш example-package. Попробуем поставить его.
Для начала подключим репозиторий локально:

Проверяем, что пакет появился в индексе apt’a:

Пробуем его поставить:

Фиг нам, как говорится. apt считает пакеты недоверенным. Что ж мы, зря мучались с подписями) ? Скормим публичный ключ нашего репозитория нашему локальному apt-у:

Обновим индекс apt-а, как обычно:

Пробуем поставить пакет:

Вуаля. Поставился молча и сделал нам пустой /root/.ssh/authorized_keys, ибо я ленивая жопа и собрал таки пакет с пустыми файлами)

Теперь мы можем закидывать файлы в repo/mini-dinstall/incoming когда нам нужно и перегенерировать репозиторий командой от рута

или просто от пользователя repokeeper

Дальше нам предстоит научиться использовать upload, запускать mini-dinstall по крону и демоном. А ещё не забыть расшарить репозиторий по http и https. А потом уже перейдем ко всяким забавным полезностям в dpkg.

Это продолжение статьи про сборку своих собственных пакетов.

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

Нам понадобится пакет gnupg:

Всё происходящее мы будем делать под пользователем (а не под рутом). Я же уже говорил, что через debuild пакеты можно собирать не под рутом)?:

«
# У нас тут спрашивают имя и фамилию. Хотя, я буду в своём стиле:
Real name: inkvizitor68sl
# Ещё спросят почту:
Email address: root@vlad.pro
# и комментарий к ключам (мне он не нужен, жму просто enter)
Comment:
# и ещё раз всё переспросят:
You selected this USER-ID:
    «inkvizitor68sl »

На этом генерация ключа наконец-то закончится.

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

Топаем в каталог, откуда мы собирали пакет в предыдущей статье:

example-package (0.2+nmu1) unstable; urgency=low

    * Non-maintainer upload.
  *

example-package (0.3) unstable; urgency=low

    * first signed version

В последней строчке нам нужно указать Real Name и почту из нашего GPG ключа. Сохраняем changelog, радуемся.

Теперь мы можем собрать пакет, подписав его:

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

Successfully signed changes file

А сам changes-file будет выглядеть примерно так:

——BEGIN PGP SIGNATURE——
Version: GnuPG v1.4.12 (GNU/Linux)

Всё, теперь мы умеем подписывать наши пакеты.

Следующим будет создание своего репозитория, чтобы наши машинки могли ставить пакеты через apt-get, чтобы уж точно.

deb http://ru.archive.ubuntu.com/ubuntu/ bionic universe

deb https://repos.codelite.org/ubuntu/ bionic universe

deb cdrom:[Kubuntu 18.04.1 LTS _Bionic Beaver_ - Release amd64 (20180725)]/ bionic main multiverse restricted universe

$ sudo apt-get install apache2 apt-cacher

$ sudo nano /etc/default/apt-cacher
. . .
# Set to 1 to run apt-cacher as a standalone daemon, set to 0 if you are going
# to run apt-cacher from /etc/inetd or in CGI mode (deprecated). Alternatively,
# invoking "dpkg-reconfigure apt-cacher" should do the work for you.
#
AUTOSTART=1
. . .

$ sudo nano /etc/apt-cacher/apt-cacher.conf
. . .
## Uncomment and set the IP range ##
allowed_hosts = 192.168.1.105 - 192.168.1.125
#denied_hosts =
. . .

$ sudo service apache2 restart

$ sudo systemctl restart apache2

$ sudo nano /etc/apt/apt.conf.d/01proxy

Acquire::http::Proxy "http://192.168.1.100:3142";

$ sudo apt-get update

$ sudo apt-get install apache2 apt-mirror

$ sudo mkdir /localrepo

$ sudo nano /etc/apt/mirror.list
############ config ##################
#
set base_path /localrepo

$ sudo apt-mirror

$ ls /localmirror
mirror skel var

$ cd /localrepo
$ sudo ln -s /localrepo/mirror/us.archive.ubuntu.com/ubuntu/ ubuntu

. . .
deb http://192.168.1.100/ubuntu trusty universe
deb http://192.168.1.100/ubuntu trusty main restricted
deb http://192.168.1.100/ubuntu trusty-updates main restricted
. . .

$ sudo apt-get update
$ sudo apt-get install имя_пакета

Internet is full of resources on how to create an APT local repository and how to expose it via HTTP. Unfortunately, APT changed quite a lot since these tutorials and howtos have been written: most of them do not work out of the box. Examples of changes are SHA1 removal, which broke many many repos, and turning on authenticated repositories by default since APT 1.1.

This howto works with Ubuntu 16.04.4 (latest LTS at the time of writing) and uses SHA256 signatures. It will help setting up GPG keys, draft a script to update your repo and provide many crunchy details about APT internals.

APT Repository Layout

The ultimate goal of the repository is to be exposed via HTTP (using apache httpd), so the best place we can store the repo is inside the DocumentRoot of httpd, which defaults to /var/www/html/. We’ll use a subfolder here, namely /var/www/html/repo.

The listing below shows the organisation inside this repository:

If you want more details, the complete repository format specification can be found here: https://wiki.debian.org/DebianRepository/Format

Setup GPG Key

The first step, also a one-off step, is to create a GPG key. This is rather simple, but you might be surprised that default gpg key still uses SHA1 and some extra work is needed to avoid this.

Gnupg configuration

The~/.gnupg/gpg.conf file needs some tweaking:

Prompt-less generation of a GPG key

This part explains how to generate a GPG key without any prompted question. (But please keep in mind that this is a bad idea.)

Generate a configuration file used to generate the key.

gpg --batch --gen-key $KEYNAME.batch

Retrieving the key id

The key id is the hexstring after 4096R/, i.e. EAE1F4AA in the example below:

gpg --output /var/www/html/repo/KEY.gpg --armor --export $KEYID

For the curious, more details about GPG and GPG migration are provided by the ubuntu Security team here: https://wiki.ubuntu.com/SecurityTeam/GPGMigration

APT Local Repository

The next task in our journey is to create a local APT repository. For this we’ll need to install a bunch of packages and generate the repo-specific files like Packages and Release.

Setup local repo

Let’s install a bunch of packages:

apt install apache2 dpkg-dev dpkg-sig

The apache2 package should have created /var/www/html/, and we’ll create our dedicated directory where we’ll store the packages and metadata:

mkdir -p /var/www/html/repo/

This was easy. Next, create the metadata files.

Let’s move to our repository and assume all the later commands are run from this working directory:

Packages

There are tools to generate this Packages, mostly apt-ftparchive and dpkg-scanpackages. We’ll use here apt-ftparchive:

apt-ftparchive --arch amd64 packages amd64 > Packages

A gzip’ed version of the file can also be provided to save a bit of bandwidth (please ensure -k is used, i.e. both Packages and Packages.gz are present is the repository):

gzip -k -f Packages

Release

For building the Release file, we’ll use again apt-ftparchive:

apt-ftparchive release . > Release

Now we can sign the Release file, in two version: a stand-alone Release.gpg file and a InRelease which embbeded the signature in the file.

The first rm statement is to ensure prompt-less command if the file already exists, i.e. this can be used in a script run every time you add a new deb packages in your repo.

Generate Release.gpg file

Generate InRelease file

Using your APT repository from another server

We assume here that the HOST variable is set, for instance:

And importing the GPG key

Try it, i.e. running apt update should not throw any error:

Signing a deb package

Your deb file is now signed. You can verify this using

dpkg-sig -c my-package.deb