Creating a personal apt repo is a great idea for managing custom packages while still utilizing apt's management and dependency abilities. (We are not going to cover all the specifics of why one would want to create a custom apt repo, that should be self-explanatory.) Creating a secure apt repo accessible via apt is relatively straight forward, three items need to be setup: the repo dir, httpd, and GPG to sign the packages. Conventions
Setting up the repository directory The first step is to create the directory structure. In the conf directory there must be a configuration file called distributions. For the sake of simplicity, we are only defining one component to work with, called main. It works just like the main component of official repos from vendors like Debian and Ubuntu. (Note: for the time being we are not signing our packages just yet. Soon!) The other directories will be created as needed by the tool that adds packages to the repo, reprepro. Therefore you do not need to worry about them. Setting up httpd Regardless of what httpd you choose to use, you want to allow for HTTP access to the /home/jason/apt-repo directory. For apache use the following directory defintion: Adding packages to repo Adding packages to the repo is very easy: Use apt-get to fetch packages with your new repo You must tell your clients machines to use the new repo in order to fetch packages from it: If your packages are sane (which will be covered in another blog post!), you should have been able to install your packages without any problems. Almost .... did you get an error about your repository being unsigned? Read on! Signing the repo Dpkg packages do not have the ability to be individually signed the way RPM packages do. Instead, the package publisher must sign the contents of the repo the package comes in order to validate the authenticity of the package. The first step is to create a GPG key used to sign the repo. In the section below, the material in CAPS is example user input. If you haven't done so already, secure the permissions of your .gnupg directory. Now lets generate that key! We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. You should be able to see the key now: It is the latter part of the pub key ID we are concerned about, in this case EE519117 We want to add the following line to the distributions file: The next time you add a package to the repo, add it with the following command: Adding the package will cause the repo to be signed with the key. If you do not want to wait till you've added a package to sign the repo, you may do the following: Client configuration for the new key You need to publish your key and have the clients install it in order to use it. You can extract it like so: On your client machiness you can install it like so: You should be able to install packages with out any issues regarding security signatures! Future blog posts: Multi component repos Pass-phrase less repos (dangerous! but easy to manage in trusted environments) Custom dpkg packages Easy backporting of dpkg packages |
AuthorBrandorr Group LLC is a one-stop cloud computing solution provider, helping companies manage growth and ship new projects using cloud and scalability best practices.
Recent Posts
June 2019
|