Yocto и генерация изображений при использовании репозитория подписанных пакетов rpm - PullRequest
0 голосов
/ 26 апреля 2018

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

Первый вопрос : после запуска команды "bitbake my-image.bb" процесс сборки останавливается с таким сообщением об ошибке:

ERROR: myimage-1.0-r0 do_rootfs: [log_check] myimage: found 1 error message in the logfile:
[log_check] Failed to synchronize cache for repo 'yocto-rpm', disabling.

Удивительно, но эта ошибка возникает только тогда, когда сервер http, используемый для обслуживания пакетов rpm для запущенного дистрибутива (то есть nginx), останавливается (не слушает). Если http-сервер запущен (прослушивает), то сообщение об ошибке не появляется и генерация образа yocto работает нормально.

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

Второй вопрос : я настроил свой образ для использования dnf клиента для управления пакетами rpm. Чтобы настроить удаленное хранилище, используемое для обслуживания пакетов rpm, я создаю файл dnf _%. Bbappend, чтобы скопировать этот файл конфигурации в целевой каталог $ {D} /etc/yum.repos.d/

$ cat yocto-rpm.repo
[yocto-rpm]
name=Rocko Yocto Repo
baseurl=http://<HTTP_SERVER_IP>/rpm
enabled=1
gpgcheck=1

Когда переменная 'gpgcheck' установлена ​​со значением 0, изображение будет в порядке, даже если http-сервер (nginx) остановлен. Однако, если для gpgcheck установлено значение 1, изображение не будет работать нормально, если http-сервер (nginx) остановлен.

Как это возможно? Анализирует ли yocto содержимое файла, установленного на конечном образе, для настройки процесса сборки?

Чтобы предоставить всю информацию, связанную с этой проблемой, yocto знает об открытом ключе gpg, потому что он определен в distro.conf следующим образом:

INHERIT += "sign_rpm"
RPM_GPG_NAME = "gpgyocto"
RPM_GPG_PASSPHRASE = "XYZ"

INHERIT += "sign_package_feed"
PACKAGE_FEED_GPG_NAME = "gpgyocto"
PACKAGE_FEED_GPG_PASSPHRASE_FILE = "/etc/yocto.d/gpgyocto"

Ключ "gpgyocto" доступен на кольце ключей gpg:

$ gpg --list-keys
/home/<myuser>/.gnupg/pubring.kbx
----------------------------------
pub   rsa2048 2018-04-27 [SC] [expires: 2020-04-26]
      9112FBBF2073012C1463B8686235C65BD7C1F0D8
uid           [ultimate] gpgyocto <yocto@<mydomain.com>
sub   rsa2048 2018-04-27 [E] [expires: 2020-04-26]

Заранее спасибо за ваше время! :)

Ответы [ 2 ]

0 голосов
/ 13 июня 2018

Я наконец исправил свою проблему. Добавление пользовательского dnf _%. Bbappend было плохой идеей. Из-за этого возникли все проблемы.

Лучший способ решить эту проблему - полностью удалить dnf _%. Bbappend, а затем определить пользовательский PACKAGE_FEED_URIS в вашем local.conf, указывающий на ваш rpm-сервер. Процесс сборки Yocto автоматически создает файл конфигурации внутри $ {D} /etc/yum.repos.d/ со всем необходимым для использования этого удаленного репо с целевого устройства. Это все. Надеюсь, что это поможет кому-то еще, и спасибо за вашу поддержку.

0 голосов
/ 29 апреля 2018

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

Второй вопрос: для проверки gpg требуется открытый ключ для проверки подписи пакета, который необходимо загрузить. Если открытый ключ недоступен, rpm применяет криптологически слабые проверки (т. Е. Дайджест-проверку) и предпринимает «все возможное» по историческим причинам. Правильным «исправлением» было бы сбой при создании образа из пакетов, подпись которых не была проверена (поскольку требуемый открытый ключ не мог быть найден, поскольку «сервер» был «остановлен» или иным образом недоступен).

...