In this lesson,
we're going to discuss repositories,
because most of the software packages that you're going to use
are going to be acquired from those repositories.
Now, most packages
are included in the official distribution repositories,
but there's also cases where packages can't be installed
due to dependencies,
and you're going to need to install
all the dependencies manually,
so you may have to create your own repository
and deploy your packages from it.
Knowing which repositories you're using
can also help you understand
how your system is managing its updates.
So let's go ahead and discuss how you configure repositories
using various local command line tools to meet your needs.
Repositories, also known as repos,
are storage locations for available software packages.
Now, repositories are checked by package managers,
like YUM, DNF, and APT,
whenever you're installing or upgrading software.
There are three kinds of repositories
that you're going to find.
These are local repositories,
centralized internal repositories, and vendor repositories.
Local repositories
are stored on the system's local storage drive.
Installation is easy,
but version control is much more difficult
because of the decentralized nature
of these local repositories.
If you manage 20 Linux servers, for example,
each one is going to have its own repository
that you have to maintain.
Instead, you might move to a centralized
internal repository.
These centralized internal repositories
are stored on one or more systems
within your internal local area network,
and they're managed by a Linux system administrator.
This centralized approach makes version control much simpler
across your organization.
So again, let's say you're managing 20 Linux servers,
one can host all the repositories for all the other 19.
This way, that one server is your central repository
internal to your own local area network,
and all of your Linux servers will go to that server
to download their packages from it.
Now, the third type we have is known as a vendor repository.
These are maintained on the internet,
often by the distribution vendor themself.
Version control here is very difficult though,
because the vendor gets to decide
what package versions are being made available
to everyone in the world inside of their vendor repository.
Therefore, if you're working as a Linux system administrator
on an enterprise network, most of the time,
you're going to find that you're using a centralized
internal repository.
That way, you can control
exactly what versions are being used
on all of your Linux servers.
Now, system administrators can also designate
a specific location as a yum repository
to be able to create this internal repository.
To do this, you're going to use the createrepo command.
This command is going to update the XML files
that are used to reference the repository's location.
This repository might be on the local storage drive,
which is going to be a local repository,
or it could be available from an Apache web server,
which becomes a centralized internal repository.
After running the createrepo command,
a .repo or repo configuration file is going to be created
and that provides additional information
about your repository.
The .repo files are going to be stored
in the /etc/yum.repos.d/ directory.
Some of the components of the .repo file
include the bracket repo-name bracket,
which is going to refer to the repository name.
name=Repository Name,
which refers to the human-friendly name of that repo.
baseurl=, which refers to the path to the repo.
enabled=1, which basically enables the repo.
If you set this to zero, it will disable the repo.
And gpgcheck=0, which disables GPG checking,
which is a form of encryption in digital certificates.
If you want to enable this, you could set this to one.
Another yum repository configuration file
is located at /etc/yum.conf,
so you should also look at that
to ensure it's configured correctly.
If you're using DNF as your package manager,
you should also check the /etc/dnf/dnf.conf file,
because it contains the configurations
for your repositories when using DNF.
Now, the yum command
also includes some additional sub commands
for viewing and using repositories.
If you use yum repolist, this is going to be used
to see all of the available repositories.
If you use yum makecache,
this is going to be used to locally cache information
about the available repositories.
And if you use yum clean all,
this command is going to be used
to clear all the out-of-date cache information
so you can download a new copy.
Yum also enables the synchronization
of an online repository to a local storage location too,
if you want to.
This is known as mirroring,
and it has the advantage of reducing the way-in traffic
and lessening the time to load things
from the parent repository.
This is done by using the reposync utility.
The reposync utility is going to be used
to manage this synchronization process,
and you can choose to synchronize
the parent repository once,
or you can cause it to update periodically.
For example, you as a system administrator
might want to synchronize the Red Hat Network
or RHN repository over to a local server that you control.
This then enables internal Red Hat servers
to use the local server as a repository,
instead of having to go over the internet
to the Red Hat Networks repository itself.
To do this, simply run the reposync command
by typing reposync and the options.
Like the yum package manager,
the APT package manager can also be configured
to access repositories
as part of the software management life cycle.
The repositories are going to be configured for APT
inside the /etc/apt/sources.list file,
and in the /etc/apt/sources.list.d/ directory.
Like the yum repositories, APT repositories
are also going to be able to be on the local system,
on a local network,
or hosted on the internet by a vendor.
When it comes to configuring your APT package manager,
you do want to check the configuration files for that
under /etc/apt.conf,
which contains the configuration file
for your APT package manager.