Raise your own package repository for Ubuntu (Debian)

In the life of any developing project, sooner or later (and better sooner) there comes a time when exploitation looks meaningfully at the development and offers to formalize the relationship. Further developments, as usual, depends on both sides. We will not discuss the bad today, we will immediately consider the case when the development is ready to use simple package building tools prepared for it by operation (templates debian / rules and debian / control, commands fakeroot, debuild, and so on). Only a little remains: to raise your own repository for the collected packages.

Since the study of the Internet suddenly showed that the topic, although it was covered , and even on Habré , can hardly be considered as clearly open, we will try to fill this gap.

First we need a key that will be signed by the repository. In this example, we create an RSA-key with a length of 4096 bits, which has no statute of limitations:

$ 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 

Since it is supposed to sign the repository with every change, it is better to leave the password on the key empty, otherwise the script will not update the repository, but if you want complete control, you can set it. Next, the key must be exported to a file and subsequently placed in the repository root for further import on clients.

 $ export PUBKEY_ID=`gpg --list-keys | awk '( $1 == "pub" ) { print $2 ; exit }' | cut -f 2 -d /` $ gpg --output keyFile --armor --export $PUBKEY_ID 

It's time to prepare the repository tree. We have only one Ubuntu distribution, only Intel x86_64 and no source packages, so we don’t worry about creating other elements of the tree. If the packages are built for different distributions and have different dependencies, the tree will turn out to be more spreading, and the assembly rules mentioned below will become more complicated.

 $ sudo mkdir -p /var/www/repo $ sudo mv keyFile !$ $ cd !$ $ sudo mkdir -p conf contrib/binary-amd64 dists/xenial 

Create a repository configuration file:

 $ 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 

It's time to set up an automatic update of the repository when new packages appear in it. The embedded signature InRelease file is requested by new batch managers, and a bunch of two Release and Release.gpg files are needed by the old ones. Dependencies need to be duplicated for all distributions that you plan to support.

 $ 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 

The repository is ready, it remains to configure getting all newly created packages in / var / www / repo / dists / xenial / contrib / binary-amd64 (beyond the scope of this article). However, is there much use from the repository, if it is strictly local? It is necessary to ensure its availability via 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 

And finally, we register our repository on clients:

 $ 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 

Session of black magic with disclosure is over, thank you all for your attention.