Skip to content
DevOps AI ToolKit
Newsletter

Kali Linux for DevOps Engineers · Part 4 of 15

Kali Linux Package Management

Difficulty: Beginner ~12 min Part 4/15
Series progress4 / 15
Series curriculum (15 lessons)

Kali Linux is built on Debian, so once you understand how software is installed and updated here, you understand it on Ubuntu, Debian, and most of the Linux servers you will manage as a DevOps engineer. This lesson covers apt and dpkg, how the kali-rolling repository works, Kali’s metapackages, and how to keep your toolbox current without breaking it.

Two tools: apt and dpkg

Package management on Debian-based systems has two layers, and it helps to keep them straight:

ToolLayerWhat it does
aptHigh-levelTalks to remote repositories, resolves dependencies, downloads and installs packages, handles upgrades
dpkgLow-levelInstalls, removes, and queries individual .deb files already on disk; does not resolve dependencies or reach the network

Day to day you will use apt. You reach for dpkg when you have a single .deb file, or when you want to query exactly what is installed. Think of apt as the package manager and dpkg as the package installer it drives underneath.

💡 Note — You may see the older apt-get and apt-cache commands in tutorials. They still work. Modern apt merges the most common ones into a single, friendlier command with progress bars and colour. Use apt interactively; prefer apt-get in scripts, where its output format is more stable.

Refreshing the package index: apt update

Before you install or upgrade anything, refresh your local copy of what is available in the repositories:

sudo apt update

This downloads the latest package lists from every repository configured on your system. It does not install or change any software — it only updates the index of what could be installed and at which version. If you skip this, apt works from a stale catalogue and may try to fetch versions that no longer exist, which is a common cause of “404 Not Found” errors during install.

Run apt update at the start of any session where you plan to install or upgrade.

Upgrading installed packages: upgrade vs full-upgrade

There are two ways to upgrade the software you already have, and the difference matters:

sudo apt upgrade

apt upgrade installs newer versions of packages you already have, but it will never remove a package to do so. If a newer version needs a package removed, that upgrade is held back.

sudo apt full-upgrade

apt full-upgrade does the same but is allowed to remove packages when required to complete the upgrade. On a rolling-release system like Kali this is the recommended command, because tool dependencies shift constantly and packages sometimes need to be replaced. (full-upgrade is the modern name for what used to be apt-get dist-upgrade.)

A typical Kali update session is just two commands:

sudo apt update
sudo apt full-upgrade

The first refreshes the catalogue; the second brings every installed package up to the newest version in the repo, removing anything that stands in the way.

⛔ Production Warningapt full-upgrade on a rolling release is designed for a disposable Kali toolbox — a VM you can rebuild in minutes. It pulls in whatever is newest and will remove packages to get there, so a single upgrade can meaningfully change your toolset. Do not run this reflexively on production servers. Production hosts should run a stable, fixed-point distribution such as Ubuntu LTS or Debian stable, where you get security patches only within a version and take major upgrades deliberately, in a maintenance window, after testing. Rolling upgrades are great for a lab bench and wrong for a fleet that has to stay up. See Kali vs Ubuntu for when to choose which.

Installing and removing packages

Install a package (and everything it depends on) by name:

sudo apt install tmux

apt resolves dependencies, downloads them, and installs the lot. You can install several at once: sudo apt install tmux jq curl.

Remove a package but keep its configuration files:

sudo apt remove tmux

Remove a package and its system-wide configuration:

sudo apt purge tmux

🔎 Troubleshooting Tip — If apt install fails with a “held broken packages” or unmet-dependencies error, you almost always forgot to run sudo apt update first, or you are mid-way through a partial upgrade. Run sudo apt update && sudo apt full-upgrade to reconcile, then try the install again. sudo apt --fix-broken install repairs an interrupted install.

Searching and inspecting packages

To find a package when you know roughly what it is called or does:

apt search nmap

This searches package names and descriptions in the repositories. No sudo is needed — you are only reading the index. To read the full description, version, and dependencies of one package before installing it:

apt show nmap

Finding what is already installed

Two commands answer “what is on this machine?”, and DevOps engineers use them constantly for auditing and reproducing environments:

apt list --installed

Lists every package apt considers installed. Pipe it through grep to filter, e.g. apt list --installed | grep openssh.

dpkg -l

The dpkg equivalent, with a status column (ii means installed and configured). To check one specific package and see its version quickly:

dpkg -l nmap

And to find out which package owns a file already on disk — invaluable when debugging “where did this binary come from?”:

dpkg -S /usr/bin/nmap

🛠️ DevOps Perspectivedpkg -l and apt list --installed are how you produce a reproducible inventory of a host. Capture the output into version control or a config-management manifest and you can rebuild the same toolbox anywhere. When an incident starts with “it works on my box,” comparing installed-package lists between two machines is often the fastest way to find the difference.

Understanding the kali-rolling repository

A repository is a remote server that hosts packages and an index of their versions. Your system’s repositories are listed in /etc/apt/sources.list:

cat /etc/apt/sources.list

On a standard Kali install you will see a single active line pointing at the kali-rolling repository:

deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware

Rolling release means there are no numbered versions like “Kali 24.04.” Packages flow continuously into kali-rolling as they are updated, and your system stays current by upgrading against that single moving target. This is the opposite of Ubuntu LTS, where you install version 24.04 and stay on it for years, receiving only security fixes until you deliberately upgrade to the next release.

🔐 Security Note — Only add repositories you trust, and never disable signature verification to force an install. Kali packages are cryptographically signed; if apt reports an untrusted or expired key, stop and investigate rather than working around it with --allow-unauthenticated. Adding random third-party repos is one of the fastest ways to break a Debian-based system or introduce malicious packages.

Kali metapackages

Kali ships thousands of tools, and installing them one at a time would be painful. A metapackage is a package that contains no files of its own — it simply depends on a curated set of other packages, so installing it pulls in the whole group. Useful ones include:

MetapackageWhat it pulls in
kali-linux-headlessThe default, GUI-free tool set — ideal for a server or CI runner
kali-linux-defaultThe standard desktop tool set most installers ship with
kali-linux-largeA much wider selection of tools
kali-tools-top10Just the ten most common tools, a lightweight starting point
sudo apt install kali-linux-headless

For DevOps work in containers or minimal VMs, kali-linux-headless is usually the right choice — you get the command-line tooling without a desktop environment you will never open. You can always add individual tools later with apt install.

🧪 Try It — In a Kali VM, run apt show kali-linux-headless and look at the Depends line. That single field lists every tool the metapackage will install. Then run apt list --installed | wc -l to count your current packages, install a small metapackage such as kali-tools-top10, and count again to see exactly how many packages it brought in. Only test and install on systems you own.

Cleaning up: cache and orphaned packages

apt keeps every .deb it downloads in a cache under /var/lib/apt/, and upgrades leave behind dependencies nothing needs anymore. Two commands reclaim that space:

sudo apt autoremove

Removes packages that were installed only as dependencies of something you have since removed — the “orphans.” Safe and worth running after a big remove or full-upgrade.

sudo apt clean

Deletes the entire local cache of downloaded .deb files. They are just installers, not the installed software, so removing them frees disk space without uninstalling anything. sudo apt autoclean is a gentler variant that only removes packages that can no longer be downloaded.

🛠️ DevOps Perspective — In a Dockerfile, rm -rf /var/lib/apt/lists/* after an install is the containerised equivalent of these cleanups — it strips the package index from the image so it stays small. The same discipline that keeps a Kali VM tidy keeps your images lean. See the Docker Academy if you want to go deeper on image hygiene.

Try it: a full update cycle

Put it together on a Kali VM you can safely rebuild:

sudo apt update          # refresh the catalogue
sudo apt full-upgrade    # upgrade everything, removing blockers as needed
sudo apt autoremove      # drop orphaned dependencies
sudo apt clean           # clear the download cache

That four-line sequence is the complete, safe maintenance routine for a rolling-release toolbox. Run it periodically so your tools stay current — but remember the production warning above: this exact routine is not how you maintain a fleet of long-lived servers.

What You Learned

  • apt is the high-level manager and dpkg is the low-level installer — use apt for everyday work and dpkg for querying or installing single .deb files.
  • apt update refreshes the index; apt upgrade and apt full-upgrade apply it — on rolling-release Kali, full-upgrade is preferred because it can remove blocking packages.
  • apt search/apt show find packages, and dpkg -l / apt list --installed inventory them — the foundation of auditing and reproducing environments.
  • Kali is a rolling release tracking the single kali-rolling repository — great for a current, disposable toolbox, but the wrong model for production, where Ubuntu LTS or Debian stable belong.
  • Metapackages like kali-linux-headless install whole curated tool sets at once, and apt autoremove / apt clean keep the system lean afterwards.
  • Ready to see what those tools actually do? Continue with Kali tools for DevOps engineers.

Affiliate Disclosure: Some links on this page are affiliate links. If you purchase through one of these links, DevOps AI Toolkit may earn a commission at no additional cost to you. See our affiliate disclosure.

← Back to Kali Linux for DevOps Engineers

Related on DevOps AI Toolkit