Hands-on Lab·CompTIA Linux+

Packages, repositories, and proving nothing changed

Domain 1 names package management and the two families answer every question differently. This guide installs the same tool on both, asks each what it installed and where it came from, verifies the files against the package record - including a deliberately tampered binary - and removes it, showing why Debian has two removal verbs and the RPM family has one.

System Management Guide 16 of 28 Beginner

PlatformsUbuntu 26.04 LTS + AlmaLinux 10.2
Mandatory access controlAppArmor on Ubuntu, SELinux enforcing on Alma
Firewallufw / nftables 1.1.6
TimeAbout 24 min

One host of each family, because this is the domain where they diverge most - different tools, different queries, and a removal verb one of them does not have.
Server Name	IP Address	OS	Roles	CPU	RAM	HDD
LPLUS-A01	192.168.0.73	Ubuntu 26.04 LTS	Debian-family host - apt, ufw, netplan, AppArmor	2 Core	4 GB	50 GB
LPLUS-B01	192.168.0.74	AlmaLinux 10.2	RPM-family host - dnf, firewalld, NetworkManager, SELinux	2 Core	4 GB	50 GB

This guide includes

Use this when you need to know what a machine has installed, where a file came from, or whether a binary has been altered. This matters because rpm -V turns "has this been tampered with" into a one-command answer, and because removing a package on Debian without purge leaves its configuration behind.

counting what is installed and reading which repositories a machine trusts
finding the package for a command you do not have yet, on both families
installing, then asking which files arrived and which package owns one
verifying every file against the package record, and reading S.5....T.
removing with and without purge, and seeing the rc state Debian leaves behind

Before you start

the-lab-and-the-two-package-families

What is installed, and where it came from
An inventory, and the repositories behind it.
bash Example session
```
$dpkg -l | grep -c "^ii"; echo "packages installed"; apt-cache policy | head -6765packages installedPackage files: 100 /var/lib/dpkg/status     release a=now 500 http://security.ubuntu.com/ubuntu resolute-security/multiverse amd64 Packages     release v=26.04,o=Ubuntu,a=resolute-security,n=resolute,l=Ubuntu,c=multiverse,b=amd64     origin security.ubuntu.com$rpm -qa | wc -l; echo "packages installed"; dnf repolist | head -61266packages installedrepo id              repo nameappstream            AlmaLinux 10 - AppStreambaseos               AlmaLinux 10 - BaseOScrb                  AlmaLinux 10 - CRBepel                 Extra Packages for Enterprise Linux 10 - x86_64extras               AlmaLinux 10 - Extras
```
Note
A package manager can only install what a repository offers, so the repository list is the first thing to read when something cannot be found. apt-cache policy and dnf repolist are the two spellings.

The numbers are not comparable and that is fine. 764 against 1267 reflects different packaging granularity, not a bigger installation - the RPM family splits software into more, smaller packages.

epel is a third-party repository on the RPM host - Extra Packages for Enterprise Linux. Knowing which of your repositories are vendor and which are not is a genuine security question, and dnf repolist is where it is answered.

Priorities decide ties. The numbers in apt-cache policy - 500 for the archives, 100 for what is already installed - are how apt chooses between two candidates offering the same package.

Expected result764 packages on the Debian host with apt-cache policy showing the archives and their priorities - and 1267 on the RPM host, with baseos, appstream, crb, epel and extras.

Success conditionYou can say what a machine has and which sources it trusts.
Finding a package you do not have yet
The query that searches the repository rather than the installed set.
bash Example session
```
$sudo dnf provides '*/bin/tree' 2>/dev/null | grep -E "^(tree|Repo|Provide)" | head -5tree-2.1.0-8.el10.x86_64 : File system tree viewerRepo        : baseos$apt-cache search --names-only '^tree$'; apt-cache policy tree | head -4tree - displays an indented directory tree, in colortree:  Installed: (none)  Candidate: 2.3.1-1  Version table:
```
Note
**dnf provides */bin/tree searches repository metadata by FILE**, which is the query people most want and Debian does not have built in. apt-file adds it, needs apt-file update first, and is not installed by default.

apt-cache policy answers three questions at once: is it installed, what version would be installed, and from which archive. Installed: (none) is the unambiguous answer to the first.

The versions differ by design. Ubuntu ships tree 2.3.1 and AlmaLinux 2.1.0, because an enterprise distribution freezes versions for its support life. Neither is out of date; they have different contracts.

Expected resulttree-2.1.0-8.el10.x86_64 : File system tree viewer from dnf provides, with Repo : baseos - and on Debian, the package description plus Installed: (none) and Candidate: 2.3.1-1.

Success conditionYou can find which package provides a command before installing anything.
Installing, and what came with it
One package, then the files and the ownership question.
bash Example session
```
$sudo DEBIAN_FRONTEND=noninteractive apt-get install -y tree > /tmp/apt.log 2>&1; grep -E "newly installed|upgraded" /tmp/apt.log | tail -1; dpkg -l tree | tail -1 | awk '{print $1, $2, $3}'0 upgraded, 1 newly installed, 0 to remove and 54 not upgraded.ii tree 2.3.1-1$sudo dnf install -y tree > /tmp/dnf.log 2>&1; grep -cE "^Installing|^  tree" /tmp/dnf.log; rpm -q tree2tree-2.1.0-8.el10.x86_64$dpkg -L tree | grep -E "bin/|man" | head -4; dpkg -S $(command -v tree)/usr/bin/tree/usr/share/man/usr/share/man/man1/usr/share/man/man1/tree.1.gztree: /usr/bin/tree$rpm -ql tree | grep -E "bin/|man" | head -4; rpm -qf $(command -v tree)/usr/bin/tree/usr/share/man/man1/tree.1.gztree-2.1.0-8.el10.x86_64
```
Note
dpkg -L and rpm -ql list a package's files; dpkg -S and rpm -qf do the reverse. Those four are the core of the objective, and the reverse query is the one you reach for in an incident: something is misbehaving and you want to know what installed it.

command -v inside the query means you never have to know where the binary lives - rpm -qf $(command -v tree) works unchanged on either family.

ii is dpkg's state field: first letter desired state, second actual. ii is installed and meant to be; rc in the last step is removed with configuration remaining. Reading those two letters is examined directly.

Debian lists directories as well as files, which is why /usr/share/man and /usr/share/man/man1 appear alongside the man page itself. rpm -ql lists only what the package owns.

Expected result0 upgraded, 1 newly installed and ii tree 2.3.1-1 on Debian; tree-2.1.0-8.el10.x86_64 on the RPM host - then the binary and man page from each, and dpkg -S / rpm -qf naming the owning package.

Success conditionYou can list what a package installed and find the package behind any file.
What a package says about itself
Metadata, and the field one family keeps that the other does not.
bash Example session
```
$dpkg -s tree | grep -E "^(Package|Version|Depends|Description)" | head -4Package: treeVersion: 2.3.1-1Depends: libc6 (>= 2.38)Description: displays an indented directory tree, in color$rpm -qi tree | grep -E "^(Name|Version|License|Source RPM)" | head -4; rpm -q --changelog tree | head -2Name        : treeVersion     : 2.1.0License     : GPL-2.0-or-later AND LGPL-2.1-or-laterSource RPM  : tree-pkg-2.1.0-8.el10.src.rpm* Mon Nov 04 2024 Vincent Mihalkovic <vmihalko@redhat.com> - 2.1.0-8- fix programming mistakes detected by static analysis
```
Note
The RPM carries its changelog and the .deb does not. rpm -q --changelog prints the maintainer's history straight from the package. Debian ships the same information as a file - /usr/share/doc//changelog.Debian.gz - outside the query tools. When a question asks which family answers something in one command, this is often what it means.

Source RPM names what this binary was built from, which is how you find the source for a package you are debugging. Debian's equivalent is the Source: field, present when it differs from the package name.

The licence is metadata, not documentation. On the RPM side it is a queryable field, which makes an audit across a fleet a scripting job rather than a reading job.

dpkg -s reads the installed database. For a .deb file you have not installed, dpkg -I reads the file itself - and rpm -qip is the RPM equivalent.

Expected resultPackage: tree, Version: 2.3.1-1, Depends: libc6 (>= 2.38) on Debian - and on the RPM side the name, version, License: GPL-2.0-or-later, the Source RPM, and a changelog entry from Red Hat dated November 2024.

Success conditionYou can read a package's metadata without unpacking it.
Proving nothing has been tampered with
A verified package, one byte removed, and the repair.
bash Example session
```
$sudo rpm -V tree; echo "--- exit $? : silence means every file matches the package"--- exit 0 : silence means every file matches the package$sudo truncate -s -1 /usr/bin/tree && sudo rpm -V tree; echo "--- exit $? : S size, 5 checksum, T mtime"S.5....T.    /usr/bin/tree--- exit 1 : S size, 5 checksum, T mtime$sudo dnf reinstall -y tree > /dev/null 2>&1; sudo rpm -V tree; echo "--- exit $? : reinstall restores the package's own copy, and the check is silent again"--- exit 0 : reinstall restores the package's own copy, and the check is silent again
```
Note
Silence is the pass. rpm -V prints only what differs, so no output and exit 0 means every file matches the recorded size, checksum, permissions, owner, group and timestamp.

Read the columns, they are positional. S size, M mode, 5 MD5 checksum, D device, L symlink, U user, G group, T mtime, P capabilities. S.5....T. is size, contents and timestamp - exactly what altering a binary does.

rpm -Va verifies everything installed and is a genuine intrusion check, with the caveat that it trusts the local RPM database. An attacker with root can rewrite that too, which is why serious verification compares against an external copy.

The repair is dnf reinstall, not a copy. An earlier version of this page restored the binary from a backup made with cp and the check still reported .......T. - the mtime no longer matched the package. Reinstalling puts the package's own file back, with its own metadata.

Debian's equivalent is dpkg -V, which checks fewer attributes, and debsums for checksums where the package provides them - which not all do.

Expected resultSilence and exit 0 first - then after one byte is removed, S.5....T. /usr/bin/tree and exit 1 - and after a reinstall, silence and exit 0 again.

Success conditionYou can prove a file still matches the package that shipped it.
Removing it, and what each family leaves
Two verbs on one family, one on the other.
bash Example session
```
$sudo DEBIAN_FRONTEND=noninteractive apt-get install -y vsftpd > /dev/null 2>&1; dpkg -l vsftpd | tail -1 | awk '{print $1, $2, $3}'; head -2 /var/lib/dpkg/info/vsftpd.conffiles; echo "--- the conffiles, which decide what a remove leaves behind"ii vsftpd 3.0.5-0.4/etc/ftpusers/etc/init.d/vsftpd--- the conffiles, which decide what a remove leaves behind$sudo DEBIAN_FRONTEND=noninteractive apt-get remove -y vsftpd > /dev/null 2>&1; dpkg -l vsftpd | tail -1 | awk '{print $1, $2}'; ls -l /etc/vsftpd.conf | awk '{print $5, $9}'; echo "--- rc: removed, configuration kept"rc vsftpd5850 /etc/vsftpd.conf--- rc: removed, configuration kept$sudo DEBIAN_FRONTEND=noninteractive apt-get purge -y vsftpd > /dev/null 2>&1; dpkg -l vsftpd 2>&1 | tail -1; ls /etc/vsftpd.conf 2>&1 | tail -1; echo "--- and purge takes the configuration with it"dpkg-query: no packages found matching vsftpdls: cannot access '/etc/vsftpd.conf': No such file or directory--- and purge takes the configuration with it$sudo dnf remove -y tree > /dev/null 2>&1; rpm -q tree; echo "--- exit $? : one verb, and no purge distinction to make"package tree is not installed--- exit 1 : one verb, and no purge distinction to make
```
Note
remove keeps conffiles; purge does not. The rc state means removed with configuration retained, and it is deliberate: reinstalling later picks your settings back up. It also means a machine accumulates configuration for software that is no longer there.

Conffiles are declared by the package, listed in /var/lib/dpkg/info/.conffiles. Only those are protected - a file your own script wrote into /etc is not a conffile and is never preserved.

The RPM family has one verb and a different convention. dnf remove takes everything, except a configuration file you MODIFIED, which is renamed .rpmsave. Same intention, different mechanism, and both are examined.

apt autoremove is the other half. Removing a package leaves the dependencies it pulled in, marked automatic; autoremove collects them. dnf remove takes unused dependencies with it by default.

Neither host was left with the test packages. The last two commands confirm tree is gone from both, which is the check rather than the claim.

Expected resultvsftpd installed with conffiles /etc/ftpusers and /etc/init.d/vsftpd - then after remove, state rc with /etc/vsftpd.conf still on disk at 5,850 bytes - after purge, no package and no file - and on the RPM host, package tree is not installed from a single verb.

Success conditionYou can remove a package completely, and know when you have not.

Troubleshooting

A binary behaves oddly and you need to know whether it has been altered.

Why: Nothing announces a modified file; the package database has the original size, checksum and timestamp.

Fix:rpm -V <package> - silence means unchanged. Read the flags: S size, 5 checksum, T mtime. Repair with dnf reinstall <package>, which restores the package's own copy and its metadata. On Debian, dpkg -V and debsums.
A removed package's configuration is still in /etc.

Why: apt remove keeps conffiles and leaves the package in state rc.

Fix:apt purge <pkg> removes them. dpkg -l | grep '^rc' lists every package in that state, which is how you find years of leftovers.
You need the package for a command that is not installed.

Why: dpkg -S and rpm -qf only know about installed files.

Fix:dnf provides '*/bin/<command>' searches repository metadata. On Debian install apt-file, run apt-file update, then apt-file search bin/<command>.
A package cannot be found although it exists in the repository.

Why: The local metadata cache is stale, or the repository is not enabled on this machine.

Fix:sudo apt update or sudo dnf makecache, then check the source list: apt-cache policy and dnf repolist. A third-party repository such as EPEL may simply not be present.

Official sources

← All Linux+ guides

Packages, repositories, and proving nothing changed

This guide includes

Before you start

What is installed, and where it came from

Finding a package you do not have yet

Installing, and what came with it

What a package says about itself

Proving nothing has been tampered with

Removing it, and what each family leaves

Troubleshooting

Official sources