В жизни любого развивающегося проекта рано или поздно (и лучше рано) наступает момент, когда эксплуатация многозначительно смотрит на разработку и предлагает оформить отношения. Дальнейшее развитие событий, как водится, зависит от обеих сторон. О плохом сегодня не будем, рассмотрим сразу случай, когда разработка готова использовать нехитрый инструментарий сборки пакетов, подготовленный для нее эксплуатацией (шаблоны debian/rules и debian/control, команды fakeroot, debuild, и так далее). Осталась самая малость: поднять для собранных пакетов собственный репозиторий.
Поскольку изучения интернетов внезапно показали, что тема, хоть и освещалась, и даже на Хабре, вряд ли может считаться внятно раскрытой, попробуем восполнить этот пробел.
Для начала нам потребуется ключ, которым будет подписан репозиторий. В данном примере мы создаем RSA-ключ длиной 4096 бита, который не имеет срока давности:
$ sudo apt install gpg $ gpg --gen-key Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? 4 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 4096 Requested keysize is 4096 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 0 Key does not expire at all Is this correct? (y/N) y You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form: "Zaphod Beeblebrox (Galactic President) <zbeeblebrox@pres.galaxy.com>" Real name: SnakeOil Admin Email address: admin@snakeoil.org Comment: You selected this USER-ID: "SnakeOil Admin <admin@snakeoil.org>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
Поскольку предполагается подписывать репозиторий при всяком изменении, пароль от ключа лучше оставить пустым, иначе скриптом репозиторий не обновишь, но если хочется полного контроля, можно и задать. Далее ключ нужно экспортировать в файл и в дальнейшем поместить в корень репозитория для дальнейшего импорта на клиентах.
$ export PUBKEY_ID=`gpg --list-keys | awk '( $1 == "pub" ) { print $2 ; exit }' | cut -f 2 -d /` $ gpg --output keyFile --armor --export $PUBKEY_ID
Пора подготовить дерево репозитория. У нас есть только один дистрибутив Ubuntu, только Intel x86_64 и нет пакетов с исходным кодом, поэтому о создании других элементов дерева мы не беспокоимся. Если пакеты собираются под разные дистрибутивы и имеют разные зависимости, дерево получится более развесистым, да и помянутые ниже правила сборки усложнятся.
$ sudo mkdir -p /var/www/repo $ sudo mv keyFile !$ $ cd !$ $ sudo mkdir -p conf contrib/binary-amd64 dists/xenial
Создадим файл конфигурации репозитория:
$ sudo cat > /var/www/repo/conf/distributions <<EOF Origin: SnakeOil Label: SnakeOil private Ubuntu repo Codename: xenial Architectures: amd64 Components: contrib Description: Our own and 3rd party software packaged internally EOF $ sudo echo SignWith: $PUBKEY_ID >> /var/www/repo/conf/distributions
Пора настроить автоматическое обновление репозитория при появлении в нем новых пакетов. Файл InRelease со встроенной подписью запрашивается новыми пакетными менеджерами, а связка из двух файлов Release и Release.gpg нужна старым. Зависимости нужно продублировать для всех дистрибутивов, которые вы планируете поддерживать.
$ sudo cat > /var/www/repo/Makefile <<EOF #!/usr/bin/make # # Update the repository every time when a new package arrives all: repo repo: dists/xenial/InRelease dists/xenial/Release.gpg dists/xenial/InRelease: dists/xenial/Release gpg --clearsign --digest-algo SHA512 -o dists/xenial/InRelease.new dists/xenial/Release mv dists/xenial/InRelease.new dists/xenial/InRelease dists/xenial/Release.gpg: dists/xenial/Release gpg -abs -o dists/xenial/Release.gpg-new dists/xenial/Release mv dists/xenial/Release.gpg-new dists/xenial/Release.gpg dists/xenial/Release: conf/distributions contrib/binary-amd64/Packages.gz cat conf/distributions > dists/xenial/Release apt-ftparchive release . >> dists/xenial/Release contrib/binary-amd64/Packages.gz: contrib/binary-amd64/Packages gzip --keep --force -9 ../../contrib/binary-amd64/Packages contrib/binary-amd64/Packages: contrib/binary-amd64/*.deb dpkg-scanpackages contrib/binary-amd64 > contrib/binary-amd64/Packages.new mv contrib/binary-amd64/Packages.new contrib/binary-amd64/Packages EOF
Репозиторий готов, осталось настроить попадание всех вновь создаваемых пакетов в /var/www/repo/dists/xenial/contrib/binary-amd64 (за рамками данной статьи). Однако много ли проку от репозитория, если он сугубо локальный? Надо обеспечить его доступность по HTTP:
$ sudo apt install nginx $ sudo cat > /etc/nginx/sites-available/repo.conf <<EOF server { listen 80; server_name repo repo.snakeoil.org; location ~ /(.*)/conf { deny all; } root /var/www/repo; } EOF $ sudo ln -s /etc/nginx/sites-available/repo.conf /etc/nginx/sites-enabled/ $ sudo service nginx restart
И, наконец, прописываем свой репозиторий на клиентах:
$ wget -O - http://repo/keyFile | sudo apt-key add - $ sudo echo 'deb [arch=amd64] http://repo/ xenial contrib' > /etc/apt/sources.list.d/mylovelyrepo.list $ sudo apt update
Сеанс черной магии с разоблачением окончен, всем спасибо за внимание.
ссылка на оригинал статьи https://habrahabr.ru/post/316158/
Добавить комментарий