ExamFinch.com My Study

Study guide

15.3 Metapackages and Custom Repositories

Practice this exam

Kali Linux Certified Professional KLCP

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 How to Use This Guide & Study Strategy 1.3 PEN-103 Syllabus & Study Path

2 About Kali Linux

2.1 A Bit of History: From BackTrack to Kali 2.2 Kali's Relationship with Debian 2.3 Purpose and Use Cases 2.4 Main Features and Design Policies

3 Getting Started with Kali Linux

3.1 Downloading and Verifying a Kali ISO 3.2 Booting Kali in Live Mode 3.3 Installation Options Overview 3.4 Troubleshooting Installations

4 Linux Fundamentals

4.1 What Linux Is and What It Does 4.2 The Command Line 4.3 The Filesystem Hierarchy Standard 4.4 Useful Commands: Files, Search, Environment

5 Permissions and Process Management

5.1 File Permissions and Ownership 5.2 Managing Processes 5.3 Shells, Variables, and the Environment

6 Installing Kali Linux

6.1 Minimal Installation Requirements 6.2 Step-by-Step Installation on a Hard Drive 6.3 Unattended Installations with Preseeding 6.4 ARM Installations

7 Configuring the Network, Users, and SSH

7.1 Configuring the Network 7.2 Managing Unix Users and Groups 7.3 Configuring SSH

8 Configuring Services

8.1 Apache Web Server 8.2 PostgreSQL Database 8.3 Managing Services with systemd

9 Helping Yourself and Getting Help

9.1 Documentation Sources 9.2 Kali Linux Communities 9.3 Filing Good Bug Reports

10 Security Policy and Network Services

10.1 Defining a Security Policy 10.2 Possible Security Measures 10.3 Securing Network Services

11 Firewalling and Monitoring

11.1 Netfilter and iptables Behavior 11.2 Writing iptables Rules and NAT 11.3 Monitoring and Logging

12 Debian Package Management: APT

12.1 Introduction to APT 12.2 The sources.list File 12.3 Kali Repositories 12.4 Basic Package Interaction with apt

13 dpkg and Advanced Package Management

13.1 dpkg Fundamentals 13.2 Inspecting .deb Files and Package State 13.3 Maintainer Scripts and Conffiles 13.4 APT Pinning and Package Authenticity

14 Advanced Usage

14.1 Modifying and Rebuilding Kali Packages 14.2 Recompiling the Kernel 14.3 Building Custom Kali Live ISO Images 14.4 USB Persistence with LUKS Encryption

15 Kali Linux in the Enterprise

15.1 Network Installation with PXE Boot 15.2 Configuration Management with SaltStack 15.3 Metapackages and Custom Repositories 15.4 Configuration Packages and Forking

16 Introduction to Security Assessments

16.1 Kali Linux in an Assessment 16.2 Types of Assessments 16.3 Types of Attacks 16.4 Formalization and the Road Ahead

15.3 Metapackages and Custom Repositories

Key Takeaways Explain This Topic AI

A metapackage is an essentially empty package whose Depends list pulls in a whole toolset — installing kali-linux-large is really installing its dependency tree

kali-linux-default is the toolset of a standard Kali install, kali-linux-large adds most other well-maintained tools, kali-linux-everything installs every package Kali ships, and kali-tools-top10 pulls in the ten most popular tools

equivs-build turns a hand-written control file into a proper .deb, the fastest way to build an internal metapackage

reprepro hosts a custom APT repository from a directory of .deb files using a conf/distributions config, and can auto-process uploads through an incoming queue

An internal metapackage plus an internal reprepro repository lets you version and deploy your organization's standard Kali toolset like any other package

Last updated: July 2026

Kali packages 600+ tools, but a default install ships only a subset of them and no two engagements need the same set. A wireless team wants kali-tools-wireless ; a stripped-down cloud box wants far less than the full desktop. Kali solves this with metapackages , and the exam expects you to know what they are, the names of the major ones, and how to build and host your own.

What a Metapackage Is

A metapackage is a package that contains (almost) no files of its own. Its entire payload is the Depends: line in its control metadata: installing it forces APT to install everything it depends on, and removing it lets apt autoremove clean the whole set back out. Inspect one yourself: apt-cache depends kali-linux-default

apt-cache show kali-linux-default | grep -E '^(Package|Depends)'

You will see a long dependency list and no meaningful file list. This is pure package-management leverage: one name stands in for a curated toolset.

The kali-linux-* and kali-tools-* Families

  • Metapackage Contents
  • kali-linux-core Minimal base toolset for chroots, containers, WSL

kali-linux-headless The default toolset minus anything needing a GUI — the layer that carries most of the CLI tools

kali-linux-default headless plus kali-tools-top10 and the GUI tools — what the standard desktop image installs, and the baseline most people mean by "Kali"

kali-linux-large Default plus the majority of Kali's other maintained tools; used for the fuller offline images

  • kali-linux-everything Every package Kali ships — huge; for mirrors and throwaway analysis VMs, not laptops
  • kali-tools-top10 The ten most popular tools (nmap, Metasploit, Burp Suite, etc.)

kali-tools-<category> Per-category sets: kali-tools-web , kali-tools-wireless , kali-tools-forensics , kali-tools-gpu , and more

Two exam angles here. First, know the ordering: core ⊂ headless ⊂ default ⊂ large ⊂ everything . Second, know the practical use: a minimal install ( kali-linux-core ) plus exactly the category sets you need is the standard recipe for slim, purpose-built Kali machines, and installing kali-linux-large is the one-command answer to "my ISO is missing tools."

Building Your Own Metapackage with equivs

Your organization will want its own set — say, the corporate toolset plus internal scripts. The equivs package exists precisely for building dependency-only packages without learning full Debian packaging: apt install -y equivs

  • equivs-control acme-kali-tools
  • This writes a template control file. Edit it: Section: misc
  • Priority: optional
  • Standards-Version: 4.5.0
  • Package: acme-kali-tools
  • Version: 1.0
  • Maintainer: SecOps <secops@example.com>
  • Depends: kali-linux-default, kali-tools-web, openssh-server
  • Description: Acme Corp standard Kali toolset

Metapackage pulling in the approved toolset for engagement machines.

  • Build and install: equivs-build acme-kali-tools # produces acme-kali-tools_1.0_all.deb
  • apt install ./acme-kali-tools_1.0_all.deb

Because it is a real package, it shows up in dpkg -l , upgrades cleanly when you bump Version: , and its dependencies are enforced by APT. The lower-level alternative is dpkg-deb --build against a directory tree containing a hand-written DEBIAN/control file — same result, more manual steps. Know that both exist. Note that Kali Linux Revealed itself does not use equivs : its worked example builds a package the full Debian way, creating the payload directory, running dh_make --native (package type indep ), editing debian/control , listing what goes where in debian/<package>.install , and building with dpkg-buildpackage -us -uc .

Hosting a Custom Repository with reprepro

Copying .deb files around with dpkg -i scales as badly as SSH loops do. The professional move is an internal APT repository : one server holds your packages, and every Kali box installs them with plain apt . The book's tool for this is reprepro , which manages a repository as a plain directory tree you can serve with any web server. apt install -y reprepro apache2

  • mkdir -p /srv/repo/conf
  • Create /srv/repo/conf/distributions : Origin: Acme Corp
  • Label: acme-internal
  • Codename: kali-rolling
  • Architectures: amd64 all
  • Components: main
  • Description: Acme internal Kali packages
  • SignWith: ABCD1234

Codename anchors the suite your clients will request (matching kali-rolling keeps things simple); Architectures and Components define the repo layout; SignWith names the GPG key reprepro uses to sign the Release file, because clients will (and should) verify signatures just as they do against Kali's own GPG-signed repositories.

  • Add packages and publish: reprepro -b /srv/repo includedeb kali-rolling acme-kali-tools_1.0_all.deb
  • reprepro -b /srv/repo list kali-rolling

reprepro copies the .deb into a pool, regenerates the Packages index, and re-signs Release . Point Apache at /srv/repo (excluding conf/ and db/ ) and clients consume it with a line in /etc/apt/sources.list.d/acme.list : deb http://repo.acme.internal/ kali-rolling main

plus your public key in their keyring (modern style: a signed-by= option pointing at a keyring file). One apt update && apt install acme-kali-tools on any machine now deploys your entire standard toolset.

The Incoming Queue

For teams, reprepro supports an incoming queue : a drop directory where CI systems or developers upload packages, processed automatically according to conf/incoming : Name: default

  • IncomingDir: incoming
  • TempDir: tmp
  • Allow: kali-rolling

reprepro -b /srv/repo processincoming default validates each upload (checksums, signatures if required) and files it into the named distribution — no one needs shell access to the repository layout itself.

APT Pinning: Preferring Your Repository

One last operational detail: when your internal repo carries a forked package that also exists in Kali's repositories, APT normally picks the highest version number. To guarantee your repository wins (or to keep your metapackages from being shadowed), use APT pinning in /etc/apt/preferences.d/acme : Package: *

  • Pin: origin repo.acme.internal
  • Pin-Priority: 900

The default priority is 500, so 900 makes your origin authoritative; verify the result with apt-cache policy somepackage , which shows the candidate version and every pin that influenced the choice. Pinning plus the kali1 version suffix gives you two independent levers — version ordering and priority — for controlling exactly which build of a package your fleet runs.

Putting It Together

The pattern to remember for the exam: metapackage defines the toolset, reprepro distributes it, APT enforces it. Version 1.1 of acme-kali-tools that adds a new tool becomes a fleet-wide upgrade via a routine apt upgrade — the same mechanism Kali itself uses to evolve the kali-linux-default set on the rolling release.