Ubuntu Server 18.04 – Managing package repositories

Installing an FTP server

Often, the repositories that come pre-installed with Ubuntu will suffice for the majority of the Debian packages you’ll install via APT. Every now and then, though, you may need to install an additional repository in order to take advantage of software not normally provided by Ubuntu, or versions of packages newer than what you would normally have available. Adding additional repositories allows you to subscribe to additional sources of software and install packages from them the same as you would from any other source.

Adding additional repositories should be considered a last resort, however. When you install an additional repository, you’re effectively trusting the author of that repository with your organization’s server. Although I haven’t ever seen this happen first hand, it’s theoretically possible for authors of software to include back doors or malware in software packages (intentionally or unintentionally), and then make them available for others via a software repository. Therefore, you should only add repositories from sources that you have reason to trust.

In addition, it sometimes happens that a maintainer of a repository simply gives up on it and disappears. This I have seen happen first-hand. In this situation, the repository may go offline (which would show errors during apt transactions that it’s not able to connect to the repository), or worse, the repository stays online, but security updates are never made available, causing your server to become wide open for attack. Sometimes, you just don’t have a way around it. You need a specific application and Ubuntu doesn’t offer it by default. Your only option may be to compile an application from source or add a repository. The decision is yours, but just keep security in mind whenever possible. When in doubt, avoid adding a repository unless it’s the only way to obtain what you’re looking for.

Software repositories are essentially URLs in a text file, stored in one of two places. The main Ubuntu repository list is stored in /etc/apt/sources.list. Inside that file, you’ll find a multitude of repositories for Ubuntu’s package manager to pull packages from. In addition, files with an extension of .list are read from the /etc/apt/sources.list.d/ directory and are also used whenever you use apt. I’ll demonstrate both methods.

A typical repository line in either of these two files will look similar to the following:

deb http://us.archive.ubuntu.com/ubuntu/ bionic main restricted 

The first section of each line will be either deb or deb-src, which references whether the apt command will find binary packages (deb) or source packages (deb-src), there. Next, we have the actual URL which apt will use in order to reach the repository. In the third section, we have the code-name of the release; in this case, it’s bionic (which refers to the code-name for Ubuntu 18.04, Bionic Beaver).

Continuing, the fourth section of each repository line refers to the Component, which references whether or not the repository contains software that is free and open source, and is supported officially by Canonical (the company that oversees Ubuntu’s development). The component can be main, restricted, universe, or multiverse. Repositories with a main component include officially supported software. This generally means that the software packages have source code available, so Ubuntu developers are able to fix bugs. Software marked restricted is still supported but may have a questionable license. Universe packages are supported by the community, not Canonical themselves. Finally, multiverse packages contain software that is neither free nor supported, which you would be using at your own risk.

As you can see from looking at the /etc/apt/sources.list file on your server, it’s possible for a repository line to feature software from more than one component. Each repository URL may include packages from several components, and the way you differentiate them is to only subscribe to the components you need for that repository. In our previous example, the repository line included both main and restricted components. This means that, for that particular example, the apt utility will index both free (main) and non-free (restricted) packages from that repository.

You can add new repositories to the /etc/apt/sources.list file (and it will function just fine), but that’s not typically the preferred method. Instead, as I mentioned earlier, apt will scan the /etc/apt/sources.list.d/ directory for text files ending with the .list extension. These text files are formatted the same as the /etc/apt/sources.list file in the sense that you include one additional repository per line, but this method allows you to add a new repository by simply creating a file for it, and you can remove the repository by simply deleting that file. This is safer than editing the /etc/apt/sources.list file directly, since there’s always a chance you can make a typo and disrupt your ability to download packages from the official repositories.

In addition, you may need to install a GNU Privacy Guard (GnuPG) key for a new repository, but this process differs from one application to another. Typically, the documentation will outline the entire process. This key basically protects you in that it makes sure that you’re installing signed packages. Not all developers protect their applications this way, but it’s definitely a good thing to do.

Once you have the repository (and possibly the key) installed on your server, you’ll need to run the following command to update your package index:

sudo apt update

As mentioned earlier in this chapter, this command updates your local cache as to which packages are available on the remote server. APT is only aware of packages that are in its database, so you will need to sync this with that command before you’ll be able to actually install the software contained within the repository.

On the Ubuntu platform, there also exists another type of repository, known as a Personal Package Archive (PPA). PPAs are essentially another form of APT repository, and you’ll even interact with their packages with the apt command, as you would normally. PPAs are usually very small repositories, often including a single application that serves a single purpose. Think of PPAs as mini-repositories. A PPA is common in situations where a vendor doesn’t make their software available with their own repository and may only make their application available in the form of source code you would need to manually download, compile, and install. With the PPA platform, anyone can compile a package from source and easily make it available for others to download.

PPAs suffer from the same security concerns as regular repositories (you need to trust the vendor and so on), but are a bit worse considering that the software isn’t audited at all. In addition, if the PPA was to ever go down, you’d stop getting security updates for the application you install from it. Only use PPAs when you absolutely need to.

There is one use case for PPAs that may be compelling, specifically, for a server platform that standard repositories aren’t able to handle as well, and that is software versioning. As I mentioned earlier, a major server component such as PHP or MySQL may be locked to a specific major version with each Ubuntu Server release. What do you do if you need to use Ubuntu Server, but the application you need to run is not available in the version your organization requires? In the past, you would literally need to choose between the distribution or the package, with some organizations even using a different distribution of Linux just to satisfy the need to have a specific application at a specific version. You can always compile the application from source (assuming its source code is available), but that can cause additional headaches in the sense that you’d be responsible for compiling new security patches yourself whenever they’re made available. In a perfect world, the application would be available as a Snap package, which would be the safest way to install it. PPAs are a way to obtain software outside of the default repositories in a situation where a Snap isn’t available.

PPAs are generally added to your server with the apt-add-repository command. The syntax generally uses the apt-add-repository command, with a colon, followed by a username, and then the PPA name. The following command is a hypothetical example:

sudo apt-add-repository ppa:username/myawesomesoftware-1.0 

To begin the process, you would start your search by visiting Ubuntu’s PPA website, which is available at  https://launchpad.net/ubuntu/+ppas.

Once you find a PPA you would like to add to your server, you can add it simply by finding the name of the PPA and then adding it to your server with the apt-add-repository command. You should take a look at the page for the PPA, though, in case there are different instructions. For the most part, the apt-add-repository command should work fine for you. Each PPA typically has a set of instructions attached, so there shouldn’t be any guesswork required here.

So, what exactly does the apt-add-repository command do? Honestly, it’s not all that amazing. When you install a PPA, it’s essentially automating the process of adding a repository to your /etc/apt/sources.list.d directory and installing its key. Therefore, you can uninstall a PPA by simply deleting its file.

PPAs are one of the things that sets Ubuntu apart from Debian and can be a very useful feature if harnessed with care. PPAs offer Ubuntu a flexible way of adding additional software that wouldn’t normally be made available, though you will need to keep an eye on such repositories to ensure they are properly patched when vulnerabilities arise, and are used only when absolutely necessary. Always prefer packages from Ubuntu’s default repositories as well as Snaps, but PPAs offer you another option in case you can’t find what you need anywhere else.

Comments are closed.