В жизни любого развивающегося проекта рано или поздно (и лучше рано) наступает момент, когда эксплуатация многозначительно смотрит на разработку и предлагает оформить отношения. Дальнейшее развитие событий, как водится, зависит от обеих сторон. О плохом сегодня не будем, рассмотрим сразу случай, когда разработка готова использовать нехитрый инструментарий сборки пакетов, подготовленный для нее эксплуатацией (шаблоны 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
Сеанс черной магии с разоблачением окончен, всем спасибо за внимание.
Автор: my2coins