Note: Because this is an ongoing series, viewers will not receive a certificate of completion.
Skill Level Intermediate
- [Instructor] While creating a local repository to store packages can be useful for one person or one machine, if we need to distribute those packages to clients on the network or on the internet, we can set up a network facing repository, as well. This can be set up on a workstation, but it's best to keep it on a server with a reliably consistent IP address or domain name. It's no good if a repository you rely on keeps changing addresses. In this episode, we'll set up a bare-bones network repository. There are stricter requirements for other kinds of repositories, and if you need to host something for the public or packages designed for multiple architectures, it's a good idea to look up the requirements for supporting those features. Many of the steps for hosting a repository on a network are the same as for a local one, but there are some differences. So, where things are similar, I'll go through them pretty quickly, and where they're different, we'll spend some more time. If you haven't already, it might be a good idea to watch the episode in this series about local repositories if you have any questions about the steps here. The biggest difference in hosting a repository that's available remotely is that it's served up by a service like HTTP, and so we need to get that set up. In this episode, I'll use Apache, but you could use NGNX or something if you're more familiar with that. The web server part of this is really pretty minimal. Here in my Ubuntu machine, I'll write apt install apache2. Apache comes with a virtual host set up to serve the war/www/html directory on port 80. For this example, we'll use this, though you may want to take this a little bit further and set up the hosting with TLS. That's the best practice, but to stay focused on the repository part of this, I won't set up a certificate here. We use the web server to serve up the repository, and it can be located at the root of the web server or in a directory underneath it, and we can either build the repository there or simlink it from somewhere else. To keep things simpler here, I'll just build the repository inside a directory in the web root. To do that, I'll write mkdir /var/www/html and we'll call that folder repo. And to keep things simpler, I'll move over there and switch to the root user. In here, we'll set up a series of directories for specific architecture packages, if we're providing those. But the package that I'm providing is appropriate for all architectures, so I'll just put it in a directory called all. I'll make a directory called all and then copy my installer files from my home directory over to this all folder. Next, we need to create the packages file which lists the contents of the repository. To do that, I'll write apt-ftparchive and use the packages option. And then I'll set the path to the repository to look in, in this case, dot for the current directory, and I'll send the output of that command to a file called Packages. Next, we need to create the release file with apt-ftparchive and the release option, the current directory, and I'll put that to a file called Release. And then we need to go through the steps to sign the release file. I only have one key in my keychain, so I won't need to specify a key, but if you have a particular signing key to use, you may need to specify that by ID for these commands with a local user option and a key ID. To create the Release.gpg file, I'll write gpg --armor--output Release.gpg --detach-sign and use the release file as input. Then to create the inline sign file called InRelease, I'll write gpg --clearsign --output InRelease and we'll use that same release file as input. Generating the packages file and creating and signing the release file needs to be done any time the packages in the repository change. So if you do this a lot, you might consider wrapping up those steps, everything with the key export, in a script to save yourself some time. And if you're feeling fancy, it's not too much of a stretch to make it a general-purpose script where you just pass in the path to a repository and specify a particular signing key to use. And then if you haven't already made an exported copy of the key for the repository, you can do that with gpg --output, set the name of your key, and then use armor and export. Now we have all of the files we need for a secure trivial repository. In a moment, I'll switch to a client to use this repository across the network, but first I need to know the address of this machine. So I'll write ip a, and I can see this machine's IP address is 10.0.2.13. Over here on my client, the first thing I need to do is to download the key from my repository to the system so I can add it to my apt keychain. To do that, I'll write wget and then the address to the key, in this case, http://10.0.2.13/repo/mykey.gpg. Okay, now I'll use apt key add and specify that file. The next thing I need to do is to edit the configuration file to add the address of the repository. I'll write nano /etc/apt, and I'll choose to add this to sources.list. If you wanted to, you could add an entry in the sources.list.t directory instead. Down at the bottom, I'll write deb and then the address of the repository, http://10.0.2.13/repo and then a slash. I'll save that, quit nano, and then run apt update. There's my new repository. So let's take a look at the information for a package that I know is hosted on that repository. And here we go. Here's my app. Let's install it with apt install myapp. And there we go. Hosting a repository on your network or on the internet is a useful way to distribute your own software to your clients.