Package management

Why this matters

Everything you install, update or remove goes through a package manager, and it does far more than copy files: it resolves dependencies, verifies signatures, tracks what owns what, and knows how to take it all out again. Learning to work with it rather than around it is most of what separates a maintainable server from one nobody dares touch.

This objective also sweeps in the common services you will be installing — web, mail, DNS, time — so the second half is a tour of what those are and which package provides them.

The lesson

Installation, update and removal

The two families, side by side:

Underneath sit the low-level tools that handle a single package and do not resolve dependencies:

rpm -ivh package.rpm      # install a local file
rpm -qa                   # query all installed
rpm -qf /etc/nginx/nginx.conf   # which package owns this file?
rpm -ql nginx             # list a package's files
rpm -V nginx              # VERIFY against the package database

dpkg -i package.deb       # install a local file
dpkg -l                   # list installed
dpkg -S /etc/nginx/nginx.conf   # which package owns this file?
dpkg -L nginx             # list a package's files

dpkg -i frequently fails with unmet dependencies; apt install -f then fixes them up. That two-step is the normal way to install a downloaded .deb.

rpm -V is underused and genuinely valuable. It compares every installed file against the package's recorded checksum, size, permissions and ownership, and reports what has changed. During incident response, rpm -Va tells you which system binaries have been modified.

apt remove leaves configuration behind; apt purge removes it too. That distinction explains why reinstalling a package sometimes keeps your old settings — which is occasionally a relief and occasionally the bug.

Dependencies and conflicts

A package declares what it requires, what it provides, and what it conflicts with. The package manager solves that graph before touching the disk.

Two problems you will meet:

Unresolvable dependencies — the package needs a version of a library that would break something else. The manager refuses rather than half-installing. Forcing past it with rpm --nodeps or dpkg --force-depends produces a system that appears fine until the program runs and fails on a missing symbol. It is almost never the right answer.

Conflicts — two packages provide the same file, or explicitly declare they cannot coexist (nginx and apache2 both wanting port 80, for instance).

dnf deplist nginx          # what nginx needs
apt depends nginx
apt rdepends nginx         # what needs nginx — check before removing

apt rdepends before a removal saves you from discovering that half the desktop depended on the library you just took out.

Repositories

A repository is a server holding packages and an index. Source normally means the upstream origin of that content — either a source repository carrying the code the binaries were built from, or the third-party project supplying an add-on repo.

# RPM family
dnf repolist                       # enabled repositories
dnf repolist all                   # including disabled ones
dnf config-manager --set-enabled crb
dnf config-manager --set-disabled epel
dnf install epel-release           # add a well-known third party
# definitions live in /etc/yum.repos.d/*.repo

# Debian family
apt policy                         # configured sources and priorities
add-apt-repository ppa:user/ppa    # add a PPA
# definitions live in /etc/apt/sources.list and /etc/apt/sources.list.d/

Third-party repositories are the main way a stable system becomes unstable. They can carry a newer version of a core library than the distribution expects, and once installed it is difficult to go back. Enable them deliberately, prefer official ones (EPEL for RHEL, official vendor repos for Docker or PostgreSQL), and pin them where the tooling allows.

GPG signatures are what make any of this safe. Packages are signed by the repository's key; the manager verifies the signature before installing, so a tampered mirror is detected. Importing a third-party repo means importing its key, which is a real trust decision — you are saying that whoever holds that key may install software as root on your machine.

rpm --import https://example.com/RPM-GPG-KEY-example
rpm -qa gpg-pubkey*        # which keys are trusted

Disabling signature checking (gpgcheck=0) removes the only protection against a compromised mirror. Do not.

Traffic normally arrives over HTTP or HTTPS. Signature verification is why plain HTTP is survivable — the content is authenticated even if the transport is not — though HTTPS additionally hides which packages you are fetching. DHCP appears in this objective because a freshly imaged machine needs an address and a route before it can reach a repository at all; without working DHCP, package installation fails at the network layer rather than the package layer.

Language-specific package managers

Alongside the system package manager, each language ecosystem has its own — and they do not know about each other.

pip install requests            # Python
pip install --user requests     # into ~/.local, not system-wide
python -m venv .venv && source .venv/bin/activate   # isolated environment

npm install express             # Node.js, into ./node_modules
npm install -g typescript       # globally

cargo build                     # Rust, reading Cargo.toml
cargo install ripgrep           # a binary, into ~/.cargo/bin

The trap is mixing them with the system manager. pip install as root writes into the same site-packages the distribution manages, so a later dnf update python3-requests and your pip-installed version fight over the same files. On current distributions pip refuses to do this at all (PEP 668, "externally-managed-environment"), and the refusal is protecting you.

The rule that avoids all of it: system packages for system tools, a virtual environment or --user for anything your application needs. For Node, prefer a project-local node_modules over -g. Deploy with the language manager inside a directory you own, not into /usr.

Note also that these ecosystems do not verify signatures the way distribution repositories do — installing from them is trusting the registry and every transitive dependency in it.

Exclusions and alternatives

Sometimes you need a package to stay exactly where it is — a kernel that matches a driver, a database at a version your application is certified against.

# RPM family: in /etc/dnf/dnf.conf
exclude=kernel* postgresql*
dnf update --exclude=kernel*      # one-off

# Debian family
apt-mark hold postgresql
apt-mark unhold postgresql
apt-mark showhold

update-alternatives manages the case where several packages provide the same command — multiple Java versions, vi versus vim, several Python interpreters. It maintains a symlink farm so /usr/bin/java points at the one you chose.

update-alternatives --config java     # choose interactively
update-alternatives --list editor
update-alternatives --display java

(Red Hat calls it alternatives; same tool.)

Sandboxed applications

Distribution packages integrate tightly with the system. Sandboxed formats take the opposite approach: bundle the application with its dependencies and run it in a confined environment.

• Flatpak — desktop-focused, cross-distribution, sandboxed with portals for controlled access to files and devices.
• Snap — Canonical's format; also used for server software, with automatic updates.
• AppImage — a single executable file, no installation and no daemon.

They trade disk space and integration for isolation and independence from the distribution's release cycle. Useful when you need a newer version than your distribution ships and do not want a third-party repository touching system libraries.

Common services and what provides them

Installing is easy; knowing what you are installing is the point.

Web — Apache HTTP Server (httpd on RHEL, apache2 on Debian). Mature, module-based, per-directory configuration through .htaccess. Nginx is the lighter-weight alternative, event-driven rather than process-per-connection, very widely used as a reverse proxy and static file server. Both listen on 80 and 443, which is why installing the second one fails while the first is running.

DNS — the Domain Name System protocol resolves names to addresses over port

1. On a server you are usually a client of it (/etc/resolv.conf,

systemd-resolved); running a resolver means BIND (named) or dnsmasq.

Time — NTP and PTP. The Network Time Protocol keeps clocks synchronised to within milliseconds, which matters far more than it sounds: Kerberos authentication fails on clock skew, TLS certificates appear invalid, log correlation across hosts becomes impossible, and clustered databases misbehave. chrony is the current implementation on most distributions. Precision Time Protocol achieves sub-microsecond accuracy with hardware timestamping, and appears in finance and industrial control where NTP is not tight enough.

Mail — SMTP (port 25, or 587 submission) sends mail; Postfix and Exim are the common servers. IMAP4 (port 143, 993 with TLS) retrieves it, keeping messages on the server so several devices see the same mailbox — Dovecot being the usual implementation. The split matters: a machine that can send but not receive has an SMTP-only setup, which is normal for an application server.

dnf install httpd nginx bind chrony postfix dovecot
apt install apache2 nginx bind9 chrony postfix dovecot-imapd

Most services need three steps, not one: install, enable so they start at boot, and open the firewall. Installing alone leaves a service that works until the first reboot.

On the exam

• apt update refreshes metadata, apt upgrade installs. dnf upgrade does both.
• apt remove keeps configuration; apt purge removes it.
• rpm -qf / dpkg -S answer "which package owns this file?"
• rpm -V verifies installed files against the package database.
• dpkg -i does not resolve dependencies; apt install -f cleans up after it.
• GPG signature verification is the protection against a tampered mirror. gpgcheck=0 is never the fix.
• apt-mark hold and exclude= pin a package against updates.
• update-alternatives selects between several providers of one command.
• pip install as root collides with distribution-managed packages; use a virtual environment or --user. Modern distributions refuse it outright.
• NTP matters because clock skew breaks Kerberos, TLS and log correlation.
• SMTP sends, IMAP retrieves. Apache and Nginx both want port 80.