Debian’s package manager, the Advanced Package Tool (APT) is also used by many derived distributions including Ubuntu. This means that managing package repositories on those systems is consistent and straightforward.
The repository list
Online package repositories for APT are listed in
/etc/apt/sources.list.d. The latter is a directory of snippet files ending
.list, for example
/etc/apt/sources.list.d/nodejs.list. The snippet files have the same syntax as the main configuration file but they make it easier for other packages, configuration management systems and operators to add and remove repositories without disturbing any others.
Each (non-comment) line in this file represents either a binary or source package repository. Unless you particularly need the source to a package, binary repositories are usually sufficient. They look similar to this:
deb http://ftp.uk.debian.org/debian/ stretch main
Debian repositories are divided into suites and components – in this example the suite is
stretch and the component is
main. A suite usually represents a Debian release by codename –
jessie, etc – whereas a component divides the repository into logical chunks. For Debian’s official mirrors, valid components are
non-free depending on how free the project considers those packages to be.
Most repositories are validated by cryptographic keys to protect users from malicious actors. For official Debian repositories, simply adding a repository entry is usually sufficient because the keys are already trusted (for example, to add a
backports repository of packages which will be available in the next release, built for the current release).
But third-party repositories don’t have a trust chain already in place, so
apt update results in an error like this:
Err:15 http://repo.percona.com/apt stretch InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 9334A25F8507EFA5
E: The repository 'http://repo.percona.com/apt stretch InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
As packages provided by a repository will have unrestricted root access to your system, strict verification of the key should always be done – that’s beyond the scope of this tip. To quote from the manual:
“It is critical that keys added manually via apt-key are verified to belong to the owner of the repositories they claim to be for otherwise the [package security] infrastructure is completely undermined.”
Adding a verified key to the trust list is a straightforward operation using the
apt-key command, or by placing a keyring file into the