Kali Linux for DevOps Engineers · Part 4 of 15
Kali Linux Package Management
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:
| Tool | Layer | What it does |
|---|---|---|
apt | High-level | Talks to remote repositories, resolves dependencies, downloads and installs packages, handles upgrades |
dpkg | Low-level | Installs, 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-getandapt-cachecommands in tutorials. They still work. Modernaptmerges the most common ones into a single, friendlier command with progress bars and colour. Useaptinteractively; preferapt-getin 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 Warning —
apt full-upgradeon 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 installfails with a “held broken packages” or unmet-dependencies error, you almost always forgot to runsudo apt updatefirst, or you are mid-way through a partial upgrade. Runsudo apt update && sudo apt full-upgradeto reconcile, then try the install again.sudo apt --fix-broken installrepairs 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 Perspective —
dpkg -landapt list --installedare 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
aptreports 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:
| Metapackage | What it pulls in |
|---|---|
kali-linux-headless | The default, GUI-free tool set — ideal for a server or CI runner |
kali-linux-default | The standard desktop tool set most installers ship with |
kali-linux-large | A much wider selection of tools |
kali-tools-top10 | Just 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-headlessand look at the Depends line. That single field lists every tool the metapackage will install. Then runapt list --installed | wc -lto count your current packages, install a small metapackage such askali-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
aptis the high-level manager anddpkgis the low-level installer — useaptfor everyday work anddpkgfor querying or installing single.debfiles.apt updaterefreshes the index;apt upgradeandapt full-upgradeapply it — on rolling-release Kali,full-upgradeis preferred because it can remove blocking packages.apt search/apt showfind packages, anddpkg -l/apt list --installedinventory them — the foundation of auditing and reproducing environments.- Kali is a rolling release tracking the single
kali-rollingrepository — great for a current, disposable toolbox, but the wrong model for production, where Ubuntu LTS or Debian stable belong. - Metapackages like
kali-linux-headlessinstall whole curated tool sets at once, andapt autoremove/apt cleankeep the system lean afterwards. - Ready to see what those tools actually do? Continue with Kali tools for DevOps engineers.
Recommended Reading
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