my2coins Nov 25 2016 at 18:07

Поднимаем собственный репозиторий пакетов для Ubuntu (Debian)

4 min

45K

Configuring Linux**nix*

From sandbox

+27

Comments 36

grossws Nov 25 2016 at 19:30

wget -O — http://repo/keyFile | sudo apt-key add -

За такое хочется бить по рукам. Добавлять в доверенные ключ полученный по http вредно. Возьмите letsencrypt и настройте https для отдачи ключа или расположите его на доверенном сервере, доступном по https.

UFO just landed and posted this here

grossws Nov 26 2016 at 02:30

Тогда не нужны и подписи, можно подключать репозиторий так deb [trusted=yes] http://repo/ xenial contrib и не париться.

kt97679 Nov 25 2016 at 21:44

Некоторое время назад мне понадобилось поднять репозиторий пакетов для убунту и центоса. Готовых решений под мои требования не нашлось, как следствие появилось вот это: https://github.com/hulu/urepo

grossws Nov 26 2016 at 02:32

С rhel/centos обычно проблемы-то и нет, дёрнуть createrepo да и выставить директорию по http.

kt97679 Nov 26 2016 at 06:29

urepo именно это и делает

bogolt Nov 25 2016 at 22:06

А что насчет сборки под разные дистрибутивы и архитектуры? Есть ли для этого какие-то удобные решения ( помимо того что поднимаем по виртукалке под каждую убунту, собираем, и выкладываем )?

Emily_Rose Nov 25 2016 at 22:34

https://github.com/jordansissel/fpm

nightvich Nov 25 2016 at 22:49

http://openbuildservice.org/

akamensky Nov 28 2016 at 18:20

Была бы возможность поставил бы здоровый плюс. Сейчас активно fpm использую в нашей компании, собираем 30+ пакетов с его помощью на одной машине сразу для yum и apt и никакой мороки с specfile и прочим.

Одно только проблема это написание хуков которые бы работали сразу с всеми менеджерами (yum ,dnf, apt-get).

nightvich Nov 25 2016 at 22:37

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

kt97679 Nov 25 2016 at 22:57

Я использую chroot. Хост система убунту, chroot среду собираю для разных версий убунту и центоса. Работает даже экзотический вариант, когда на 64-битной хост убунте собираются 32-битные пакеты для центоса.

iborzenkov Nov 25 2016 at 22:58

а чем reprepro не устроил?

kt97679 Nov 25 2016 at 23:19

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

eisaev Nov 28 2016 at 18:20

Я из-за этой особенности перешёл на mini-dinstall.

Erelecano Nov 26 2016 at 01:10

Зашел задать тот же вопрос. Много лет его использовал, был всем доволен.

dburmistrov Nov 28 2016 at 18:20

У reprepro, на мой взгляд, есть два существенных недостатка:
— не умеет хранить несколько версий одного пакета в рамках одного Suite/Component
— при попытке добавить пакет версии ниже существующей, молча скипает с exitcode 0

istui Nov 26 2016 at 00:06

А есть такой же мануал для CentOS?

grossws Nov 26 2016 at 02:48

rpm --addsign some-package-x.y.z-1.el6.rpm или rpmbuild -ba --sign path/to/package.spec + createrepo /path/to/repo требуют отдельного howto?

Есть, например, Fedora RPM Guide, где подробно описано как сгенерировать ключи и подписывать пакеты.

istui Nov 26 2016 at 19:25

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

За ссылки спасибо, но полный мануал все же был бы лучше.

grossws Nov 26 2016 at 21:31

Fedora RPM Guide и представляет собой полный мануал, который рассказывает об rpm, как оно устроено, как пишутся spec-файлы, какие есть триггеры и т. п.

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

nightvich Nov 26 2016 at 22:44

Есть, спросите у Google.

YourChief Nov 26 2016 at 00:39

dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz

MeGaPk Nov 26 2016 at 00:59

есть еще клевая утилита aptly, сам её юзал и буду юзать :).

olegbukatchuk Nov 28 2016 at 18:20

Присоединяюсь! К тому же Aptly позволяет создавать сколько угодно репозиторием в рамках одной установки. Очень удобно.

beTrue Nov 26 2016 at 18:36

статья про шелл скрипт на треть экрана, но спасибо.

-2

rudenkovk Nov 26 2016 at 21:40

контейнеры-шмонтейнеры. Описанный в статье вариант. Не решает частного варианта dependency hell в виде персборки при изменении зависимостей.

nightvich Nov 26 2016 at 22:52

Описанный вариант даже не затрагивает этого момента. Если у вас есть опыт решения данной задачи, расскажите, как вы это делаете?

rudenkovk Nov 27 2016 at 09:02

Для пакетов у меня стоит OBS (open build service), они решили вопрос сборки пакетов в docker, и стало возможным убрать в приватное облако.
С контейнерами сложнее, я сократил количество базовых контейнеров до минимума и сам прописал между ними связи.

nightvich Nov 28 2016 at 15:05

У нас сейчас используется самописная сборочная система, я тоже смотрю OBS, но пока не решился на попытку перебраться на него. Я собираю порядка 30+ пакетов из 60+ компонентов со сложным деревом зависимостей в рамках одного продукта.

rudenkovk Nov 28 2016 at 15:08

Попытка что-то написать у меня была, но света в конце туннеля я не увидел. Как раз в тот же момент OBS нормально научился собирать в докере.

Я даже не стал себе ломать голову, поддерживаю 1 машину с opensuse. Есть мысли обернуть запуск OBS демонов в какой-нибудь runit/supervisord и сделать докер образ.

Icewild Nov 28 2016 at 18:20

https://www.aptly.info/

UFO just landed and posted this here

eisaev Nov 28 2016 at 19:09

Ну или как вариант:

cat << EOF | sudo tee -a /var/www/repo/Makefile

Faunris Nov 28 2016 at 18:21

Мы храним локальное зеркало репы debian (благодаря этому получаем профит по скорости локальной сборки пакетов). Само зеркало делаем утилитой ftpsync.
А для хранения своих пакетов используем aptly. Он предоставляет очень удобное API для загрузки и публикации пакетов в репе. И не надо делать кучу магических скриптов :)

ncrmnt Dec 7 2016 at 22:12

Я для этих нужд использую aptly, skyforge, rsync и jenkins (debian package builder + docker build environment + самописный плагин для добавления артефактов в aptly). aptly делает внутренний снепшот репозитория, потом мы его препрод-тестируем на железках, а потом rsync'ом публикуем наружу, если preprod прошел.

Show the best of all time