9. Debian Package Management

9.1. Introduction to APT

9.1.1. Relationship between APT and dpkg

1. Debian Packages Overview

A Debian package is a compressed archive for software.

Binary package (.deb): Contains ready-to-use files (programs, docs).
Source package: Includes source code and build instructions. Packages also contain metadata (dependencies, lifecycle scripts).

2. dpkg – Debian Package Tool

Handles installation/analysis of .deb files on the local system.
Limitations:
- No automatic dependency resolution.
- Only processes what’s explicitly provided on the command line.

Common commands:

Install: dpkg -i package.deb
List installed: dpkg -l
View package contents: dpkg -c package.deb

3. APT (Advanced Package Tool)

APT is a package management system for Debian-based distributions.

Resolves dependencies automatically.
Fetches packages from online repositories for installation and updates.
Relies on dpkg for installation but expands functionality.

Key Differences from dpkg:

APT: Automatically resolves dependencies and fetches packages from online sources.
dpkg: Only installs local packages and lists unmet dependencies.

4. Why APT is Important

Before APT, manual compilation with gcc, make, and configure was tedious, often failing due to missing dependencies.

APT simplifies this: Tracks requirements, resolves dependencies, and installs packages automatically.

5. Using APT

Install packages: apt install package_name
Remove packages: apt remove package_name
Update system: apt update (update repositories) and apt upgrade (upgrade packages).
Full upgrade: apt dist-upgrade (handles system-wide updates).

6. Package Source vs. Source Package

Source Package: Contains program source code.
Package Source (repository): Location for Debian packages (e.g., websites, CDs).

The repository list is stored in /etc/apt/sources.list.

7. Role in Kali Linux

APT is vital for daily tasks like installing, updating, and troubleshooting packages.

Rolling distribution: Ensures Kali Linux stays up to date with daily updates.

8. Summary

dpkg: Local package handling but no dependency resolution.
APT: Automates dependency resolution and fetches updates from repositories. Understanding APT and dpkg is crucial for managing Debian-based systems like Kali Linux.

9.1.2. Understanding the sources.list File

1. Importance of sources.list

Key configuration file for defining package sources.
APT will not function without a properly defined sources.list.
Active entries define package sources, and syntax must be understood for proper configuration.

2. Syntax of sources.list

Each active line consists of three parts, separated by spaces.

Commented lines start with #. Example:

#deb cdrom:[Debian GNU/Linux 2020.3 _Kali-rolling_] ...

Structure of a source entry:

[source type] [base URL] [distribution and components]

Source types:
- deb: Binary packages.
- deb-src: Source packages.
Base URL:
- Mirrors or archives (e.g., http://http.kali.org/kali).
- Common protocols:
  - file:// for local sources.
  - http:// for web servers.
  - ftp:// for FTP servers.
  - cdrom: for CD/DVD-ROM (less common due to network-based installations).

3. CD/DVD-ROM Sources

Managed differently using apt-cdrom add.
Requires inserting the disc, after which the contents are scanned for Packages files.
APT requests the disc if needed during installation.

4. Repository Structure

Repositories are often organized by:

Distribution (e.g., kali-rolling): Refers to a specific version or release.
Components (or sections): Indicate the license type.

Sections in Debian/Kali repositories:

main: Free software compliant with the Debian Free Software Guidelines.
non-free: Software that doesn’t fully comply but can be redistributed.
contrib: Open-source software requiring non-free elements (e.g., VirtualBox needing a proprietary compiler).

Key Difference:

Debian: Only main enabled by default.
Kali: main, non-free, and contrib enabled by default.

5. Standard Syntax Example

Standard entry for Kali:

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

6. Mirrors and Mirror Redirection

Mirrors: Provide alternate locations for package downloads, ensuring reliability and speed.
Mirror redirection: Automatically directs users to the closest/fastest mirror.

9.1.3. Kali Repositories

1. Standard sources.list for Kali Linux

Refers to one repository (kali-rolling) and three components (main, contrib, non-free):
```
# Main Kali repository
deb http://http.kali.org/kali kali-rolling main contrib non-free
```

2. Kali Repositories

Kali-Rolling Repository:
- Purpose: Main repository for end-users.
- Features:
  - Contains installable, up-to-date packages.
  - Merges Debian Testing with Kali-specific packages.
  - Ensures all dependencies are satisfied (barring bugs).
- Evolves daily due to updates from Debian Testing and upstream package releases.
Kali-Dev Repository:
- Purpose: Used by developers to resolve dependency issues.
- Features:
  - New updates land here first.
  - Not recommended for regular users, as it may contain unstable packages.
  - Occasionally used to grab very recent updates not yet available in kali-rolling.

3. Mirror Management

Role of Mirrors:
- http.kali.org: Redirects to the closest official mirror using Mirrorbits.
- Ensures mirrors are functional and up-to-date.
- Redirects based on location and mirror health.
Debugging Mirror Issues:
- Check where http.kali.org is redirecting with:
  curl -sI http://http.kali.org/README
  Example output:
  Location: http://mirror.accuris.ca/kali/README
- If redirection fails, edit /etc/apt/sources.list to hardcode a known working mirror.

4. ISO Mirrors

cdimage.kali.org: Hosts Kali Linux ISO images.
Similar redirection system as http.kali.org.

5. Retrieving a List of Official Mirrors

Append ?mirrorlist to a valid URL:

For package mirrors:
```
http://http.kali.org/README?mirrorlist
```

For ISO mirrors:

http://cdimage.kali.org/README?mirrorlist

Note: Lists may exclude restricted mirrors (e.g., country-specific mirrors).

6. Summary

Use kali-rolling as the default repository for stable updates.
Rely on Mirrorbits for efficient redirection to reliable mirrors.
Troubleshoot mirror issues by verifying redirection or manually setting a mirror.

9.2. Basic Package Interaction

9.2.1. Initializing APT

1. Overview

APT manages packages via command-line tools:
- apt-get: Original tool.
- apt: Improved version, preferred for simplicity.
Graphical Alternatives: Synaptic, Aptitude (less common).

2. Initialization

Update Package List: Run apt update to download the latest package index.
Performance:
- Can take time due to large package and translation files.
- CD/DVD-ROM installations are faster as they are local.

3. Summary

Use apt and always start with apt update for the latest package data.

9.2.2. Installing Packages

1. Installing Packages with dpkg

Overview: dpkg is the core package management tool, often used offline.
- No Dependency Management: Requires manual handling of dependencies.
Basic Installation:
```
dpkg -i <package>.deb
```
- Unpacks the package and runs configuration scripts.
- Steps can be separated:
  - Unpack: dpkg --unpack <package>.deb
  - Configure: dpkg --configure <package>
Handling Errors:
- Common error: File collision (e.g., a file exists in another package).
- Solution: Use --force-overwrite cautiously to replace files.
  dpkg -i --force-overwrite <package>.deb
- Use dpkg --force-help for other force options (use sparingly).

2. Installing Packages with APT

Preferred Tool: Automates dependency resolution and provides simpler syntax.
Basic Installation:
```
apt install <package>
```
- Example:
  apt install kali-tools-gpu
- Automatically installs dependencies and updates triggers.

Specifying Versions or Distributions:

Version:
```
apt install <package>=<version>
```
Distribution:
```
apt install <package>/<distribution>
```

Force Installation: Pass --force-overwrite to dpkg via apt:

apt -o Dpkg::Options::="--force-overwrite" install <package>

9.2.3. Upgrading Kali Linux

Kali Linux, as a rolling distribution, simplifies upgrades, ensuring the latest security updates and features. Here's a concise guide:

Upgrade Basics

Regular Upgrades: Regularly upgrade to receive security patches and bug fixes. Use:
```
apt update
apt upgrade
```
- Alternatives: apt-get upgrade or aptitude safe-upgrade.
- These commands avoid removing packages, ensuring minimal disruption.
Specific Distribution Upgrades: Use -t or --target-release for a specific distribution:
```
apt -t kali-rolling upgrade
```
To make this the default, add this line to /etc/apt/apt.conf.d/local:
```
APT::Default-Release "kali-rolling";
```
Major Upgrades: Use apt full-upgrade for significant updates, allowing package removal and new dependency installation:
```
apt full-upgrade
```
(Equivalent for apt-get: apt-get dist-upgrade).

Anticipate Changes

Important Updates: Install apt-listchanges to display potential issues during upgrades:
```
apt install apt-listchanges
```
It highlights changes documented in /usr/share/doc/package/NEWS.Debian.

Upgrade Timing Recommendations

When to Upgrade:
- After security patches are released.
- To resolve bugs in current packages.
- Before reporting a bug to ensure it's still valid.
- Weekly (or daily for critical environments).
When to Delay Upgrading:
- Critical Tasks: If breakage risks can’t be afforded (e.g., during presentations).
- Disruptive Changes: During transitions, such as a GNOME update, where packages might be mismatched temporarily.
- Package Removals: If important packages are flagged for removal, investigate why before proceeding.

9.2.4. Removing and Purging Packages

Basic Removal

Using dpkg: To remove a package but keep configuration files and user data:
```
dpkg --remove <package>
```
Example:
```
dpkg --remove kali-tools-gpu
```
Note: Dependencies are not removed when using dpkg.
Using apt: APT automates dependency handling. To remove a package:
```
apt remove <package>
```

Install and Remove in One Command

Install or remove packages together by adding suffixes:
- To remove a package during installation: <package>-
- To install a package during removal: <package>+
Example:
```
apt install package1 package2-
apt remove package1+ package2
```

Complete Removal (Purge)

To delete everything (configuration files, logs, and user data):
- With dpkg:
  dpkg -P <package>
- With apt:
  apt purge <package>
Example:
```
dpkg -P debian-cd
apt purge debian-cd
```
Warning: Purging removes all related data—use with caution.

9.2.5. Inspecting Packages

Querying dpkg's Database

The dpkg tool provides several commands to inspect the internal database located at /var/lib/dpkg. This includes package configuration scripts, installed file lists, and package statuses.

List Files Installed by a Package: Use --listfiles (or -L) to see all files installed by a package.
```
dpkg -L <package>
```
Example:
```
dpkg -L base-passwd
```
Find Package by File Path: Use --search (or -S) to find which package owns a file or path.
```
dpkg -S <file>
```
Example:
```
dpkg -S /bin/date
```
Inspect Package Headers: Use --status (or -s) to view metadata for an installed package.
```
dpkg -s <package>
```
Example:
```
dpkg -s coreutils
```
List Installed Packages: Use --list (or -l) to display all packages and their installation status. Wildcards are supported.
```
dpkg -l '<pattern>'
```
Example:
```
dpkg -l 'b*'
```
View Contents of a .deb File: Use --contents (or -c) to see the files inside a .deb package.
```
dpkg -c <path-to-deb-file>
```
Example:
```
dpkg -c /var/cache/apt/archives/gpg_2.2.20-1_amd64.deb
```
Inspect .deb File Headers: Use --info (or -I) to display metadata for a .deb package.
```
dpkg -I <path-to-deb-file>
```
Example:
```
dpkg -I /var/cache/apt/archives/gpg_2.2.20-1_amd64.deb
```
Compare Package Versions: Use --compare-versions to evaluate relationships between versions. Operators include lt, le, eq, ne, ge, and gt.
```
dpkg --compare-versions <version1> <operator> <version2>
```
Example:
```
dpkg --compare-versions 1.2-3 gt 1.1-4
echo $?
```

Querying the APT Database with apt-cache

The apt-cache command interacts with the APT cache, which stores metadata about available packages.

Search for Packages: Perform a keyword search in package descriptions.
```
apt-cache search <keyword>
```
Example:
```
apt-cache search forensics
```
View Package Details: Use show to display a package's description, dependencies, maintainer, and more.
```
apt-cache show <package>
```
Example:
```
apt-cache show kali-tools-gpu
```
Display Source Priorities: View the priorities of package sources and specific packages.
```
apt-cache policy
apt-cache policy <package>
```
List All Packages in the Cache: Display the names of all packages in the APT cache.
```
apt-cache pkgnames
```
Dump All Available Package Headers: Output headers for all available package versions.
```
apt-cache dumpavail
```

An Alternative: axi-cache

For better search relevancy, use axi-cache, which leverages the Xapian search engine. It requires the apt-xapian-index package.

Search Packages with Relevance Ranking:

axi-cache search <keywords>

Example:

axi-cache search forensics graphical

Maintaining the APT Cache

To manage disk space and remove unused cache files:

Clear the Cache Entirely:
```
apt clean
```
Remove Obsolete Packages:
```
apt autoclean
```

By mastering these tools, you can efficiently inspect and manage Debian packages while understanding their associated metadata and files.

9.2.6. Troubleshooting

When you run into problems after upgrading your system, remember that new software versions might not always be backward compatible or might contain bugs. The first step is to check existing bug reports, which could offer patches or workarounds, and then consider the following:

Bug Reports & Patches: Check the Kali and Debian bug trackers. If your issue isn’t reported, file a good bug report. Often, existing reports include patches or workaround instructions.
Downgrading Packages: If the problem is a regression (i.e., an older version worked), try downgrading. Look for older versions in APT’s cache (/var/cache/apt/archives/), on Kali mirrors, or on snapshot.debian.org.
Editing Maintainer Scripts: For issues with maintainer scripts (like postinst failures), add a set -x right after the shebang in the script located in /var/lib/dpkg/info/ to diagnose the error. You can modify the script (for example, appending || true) to bypass non-critical failures.
Using dpkg Logs: Refer to /var/log/dpkg.log to track package installation or upgrade events and correlate these with changelogs or bug reports.
Reinstalling Packages: To restore files

9.2.7. Frontends: aptitude and synaptic

Aptitude is an interactive package manager that combines a text-based, semi-graphical interface with powerful command-line capabilities. It is designed with the administrator in mind and offers enhanced decision-making in package management compared to basic APT tools.

Interface and Navigation:
- Displays packages grouped by state (installed, not-installed, or unavailable) and organizes them into a tree structure.
- Use keys such as Enter (or +/]) to unfold categories, + to mark for installation, – to mark for removal, and _ to purge packages.
- Offers views for tasks, virtual packages, and recent additions, enabling thematic browsing.
Command-Line Functionality:
- Supports search patterns similar to its interactive mode; for example, searching by package name, description (using ~d), or section (~s).
- Can be used to mark packages as automatically installed (with Shift+m) or manually installed (with m), aiding in dependency tracking and cleanup.
Recommendations, Suggestions, and Tasks:
- Respects package recommendations: installing a package like gnome may automatically mark recommended packages (e.g., gdebi) for installation, though you can deselect them before confirming.
- Treats suggestions separately, displaying them on the summary screen where manual intervention is needed.
- Incorporates tasks as categories, allowing either complete or selective installation/removal.
Solver Algorithms and Logging:
- Features advanced dependency resolution algorithms that evaluate multiple scenarios when conflicts arise, and highlights broken packages (accessible via the b key) so you can manually resolve issues.
- Maintains a log file at /var/log/aptitude that summarizes high-level operations (like system-wide upgrades), although it may not capture all actions if other tools are used.

Synaptic Overview Synaptic is a graphical package manager built on GTK+ that provides a clean interface and a set of ready-to-use filters.

Graphical Interface and Filters:
- Allows users to quickly access lists of newly available, installed, upgradable, or obsolete packages.
- Enables selection of operations (install, upgrade, remove, purge) which are accumulated in a task list rather than executed immediately.
Task Management:
- Once operations are queued, a single click applies all the changes at once, providing a clear, consolidated overview of the pending package actions.

Both aptitude and synaptic leverage the underlying libapt-pkg shared library, providing administrators with versatile interfaces—whether through the command line or a graphical environment—to manage Debian packages more intelligently and efficiently.

9.3. Advanced APT Configuration and Usage

9.3.1. Configuring APT

APT configuration in modern Debian-based systems (like Debian and Kali) has moved from single, dedicated configuration files to using configuration directories (with a .d suffix). This approach allows multiple smaller files—each containing a piece of the overall configuration—to be processed in alphabetical order, where later files can modify settings defined in earlier ones. This design offers flexibility to both administrators and package maintainers, as it avoids the need to edit core configuration files directly.

Configuration via .d Directories:
- Files in /etc/apt/apt.conf.d/ collectively define APT's behavior.
- The alphabetical processing order means that naming (e.g., using a name like 99local) can determine which settings override others.
- This structure helps package maintainers adjust configurations dynamically, complying with Debian policies that forbid direct modification of other packages' files.
Cautions with Generated Configuration Files:
- Some applications (e.g., exim) use .d directories to generate their main configuration file via an update-* command.
- Avoid manually editing the canonical configuration file because changes may be overwritten on the next update.
- Remember to run the update command (like update-exim4.conf) after editing files in the .d directory to ensure your changes take effect.
Configuring APT Options:
- You can pass options directly on the command line (for instance, forcing dpkg options such as --force-overwrite when installing zsh).
- Instead of repeatedly specifying options on the command line, add directives to a file in /etc/apt/apt.conf.d/. For example, creating a file named 99local with the following content sets a permanent dpkg option:
  Dpkg::Options { "--force-overwrite"; }
Additional Configuration Examples:
- Network proxy settings can be configured by adding lines like:
  - Acquire::http::proxy "http://yourproxy:3128"; for HTTP.
  - Acquire::ftp::proxy "ftp://yourproxy"; for FTP.

To explore more options and details, consult the apt.conf(5) manual page with the command man apt.conf.

9.3.2. Managing Package Priorities

Managing package priorities is crucial when you mix sources—such as Kali with Debian Unstable or Experimental. The core idea is that APT assigns a priority to each available package version (which may vary depending on its source or version). APT then always selects the version with the highest priority, with one important exception: an older version (relative to what’s installed) will not be selected unless its priority exceeds 1000.

Default Priorities:
- Installed package version: priority 100
- Non-installed version: default priority of 500, which can jump to 990 if it is part of the target release (specified via the -t option or APT::Default-Release).
Customizing Priorities:
- You can modify priorities by adding entries in the /etc/apt/preferences file (or files in /etc/apt/preferences.d/).
- Each entry can target specific packages, versions, or origins using selection criteria like package name, version, or the source information (as defined in the Release file).
Priority Ranges and Their Effects:
- Priority < 0: Package will never be installed.
- 0 to 100: Installed only if no version of the package is already installed.
- 100 to 500: Installed only if there is no newer version already installed or available from another distribution.
- 501 to 990: Installed only if there is no newer version available in the target release.
- 990 to 1000: Installed unless the currently installed version is newer.
- > 1000: Forces installation—even if it means downgrading to an older version.
Selection Order: APT processes preferences by considering the most specific entries first (for example, entries for an individual package) followed by more generic ones (such as those for an entire distribution). If multiple generic entries match, the first one encountered is used.
Real-World Examples:
- Debian Experimental Packages:
  - By default, packages from experimental have a priority of 1 to prevent accidental installation.
  - To treat experimental packages like any other source, add an entry:
    Package: * Pin: release a=experimental Pin-Priority: 500
- Prioritizing Kali Over Debian:
  - To ensure that only Kali packages are installed by default and Debian packages are only used when explicitly requested, you could use:
    Package: * Pin: release o=Kali Pin-Priority: 900 Package: * Pin: release o=Debian Pin-Priority: -10
- Locking a Specific Package Version:
  - To force the installation (or retention) of a specific version of Perl (e.g., version 5.22), use:
    Package: perl Pin: version 5.22* Pin-Priority: 1001
Adding Explanatory Comments: While there is no official syntax for comments in /etc/apt/preferences, you can include textual explanations by prepending one or more Explanation fields to each entry. For example:
```
Explanation: The package xserver-xorg-video-intel provided
Explanation: in experimental can be used safely
Package: xserver-xorg-video-intel
Pin: release a=experimental
Pin-Priority: 500
```

For further details and syntax options, refer to the apt_preferences(5) manual page by running man apt_preferences.

9.3.3. Working with Several Distributions

When you experiment with packages from other distributions (such as Kali Dev, Debian Unstable, or Debian Experimental) on a Kali Rolling system, APT uses a priority system to decide which version of a package to install or upgrade. To maintain system consistency while trying out newer software, you should list all distributions in your /etc/apt/sources.list and define your reference distribution using the APT::Default-Release parameter.

Installing Packages from Other Distributions:
- With Kali Rolling as your reference, you can install a package from Debian Unstable using:
  bashCopyEditapt install package/unstable
- If the installation encounters unsatisfiable dependencies, instruct APT to resolve them within the unstable distribution by adding the -t unstable option.
Upgrade Behavior:
- Regular upgrades (using upgrade or full-upgrade) will update packages from Kali Rolling by default.
- Packages previously upgraded from another distribution will continue to follow updates from their respective sources.
Understanding Priorities with apt-cache policy:
- Use apt-cache policy or apt-cache policy package to see the default priorities of each package source.
- APT compares available versions based on their priorities and version numbers, considering only packages of the same or a higher version than the installed one (unless overridden by forceful priority settings above 1000).
Example Scenario: Imagine you have three versions of a package:
- Version 1: Installed from Kali Rolling, with a priority of 990 (as it’s part of the target release).
- Version 2: Available in Kali Dev, with the default non-installed priority of 500.
- Version 3: Available in Debian Unstable, also with a default priority of 500.
In this case, although version 1 has an installed priority of 100 and version 2 and 3 each have 500, APT will stick with version 1 because the installed version from Kali Rolling has a higher effective priority (990). However, if you have a package (say, version 2) installed from Kali Dev, and there’s a competing version 3 in Debian Unstable, both with priority 500, APT will choose the newest version—potentially pulling in the Debian Unstable version. To prevent this migration, you can lower the priority of Debian Unstable packages (for example, to 490) by adding an entry in /etc/apt/preferences:
```
Package: *
Pin: release a=unstable
Pin-Priority: 490
```

In summary, APT's robust priority system, in combination with the appropriate use of apt-cache policy and targeted configuration in /etc/apt/preferences, enables you to safely experiment with packages from different distributions while keeping your system’s reference state largely intact.

9.3.4. Tracking Automatically Installed Packages

Tracking automatically installed packages is a key feature of apt, designed to keep your system tidy by removing libraries and other dependencies that are no longer needed. When you install packages, many additional packages are installed as dependencies. These are marked as "automatic" so that when the primary (manually installed) packages are removed, these dependencies can be safely purged.

Automatic Removal:
- The command apt autoremove is used to remove these unnecessary packages.
- In contrast, aptitude automatically removes them as soon as they’re identified, and it provides a clear message listing which packages will be removed.
Marking Packages:
- If you have packages that you don’t need to keep around directly, you can mark them as automatic using apt-mark auto package.
- To reverse this, use apt-mark manual package to mark a package as manually installed.
- Aptitude offers similar commands (aptitude markauto and aptitude unmarkauto) along with additional features to mark many packages at once, and its interactive interface makes it easy to review the status of these flags.
Understanding Dependencies:
- If you're curious why a particular package is present on your system as an automatic dependency, you can use the command aptitude why package. For example:
  $ aptitude why python-debian i aptitude Recommends apt-xapian-index i A apt-xapian-index Depends python-debian (>= 0.1.15)
  This shows the chain of dependencies leading to the installation of python-debian.

By ensuring that packages you don’t explicitly need are marked as automatic, you enable apt and aptitude to automatically clean up unneeded dependencies, keeping your system lean and preventing unnecessary clutter.

9.3.5. Leveraging Multi-Arch Support

Multi-arch support allows you to install packages from different architectures on the same system. By default, each Debian package’s control file specifies an Architecture field—either "all" for architecture-independent packages or a specific target (such as amd64 or i386). Under normal circumstances, dpkg installs only packages matching the host’s architecture (as shown by dpkg --print-architecture).

Enabling Multi-Arch:
- To install packages from a foreign architecture (for example, running 32-bit applications on an amd64 system), you add the desired architecture with:
  dpkg --add-architecture i386
- After updating the package lists (apt update), APT will automatically download the appropriate Packages files for the newly added architecture.
- You can install a specific foreign package by specifying its architecture, e.g.,
  apt install wine32:i386
- Removing a foreign architecture with dpkg --remove-architecture i386 isn’t allowed while packages of that architecture remain installed.
Using Foreign Binaries:
- Multi-arch is most often used to run 32-bit (i386) binaries on a 64-bit (amd64) system. Popular applications like Skype or Wine might be available only in 32-bit versions, making multi-arch support essential.
Library Repackaging and File Coexistence:
- To support multi-arch, libraries have been repackaged and moved to architecture-specific directories. Updated packages include a Multi-Arch: same field in their control information, which signals that different architectures’ versions can be co-installed.
- Shared files between architecture instances must be bit-for-bit identical. Consequently, when you query such a package (for example, with dpkg -s libwine:amd64 libwine:i386), both instances will show the Multi-Arch: same header.
- Files shared by multiple instances are managed so that they do not conflict, and the system ensures that all installed instances have matching versions—upgrades are performed simultaneously.
Dependency Handling in Multi-Arch:
- Dependencies must be met by either:
  - A package that is marked Multi-Arch: foreign, or
  - A package whose architecture matches that of the dependent package (with architecture-independent packages assumed to match the host).
- When a dependency is relaxed to allow any architecture (using the package:any syntax), only packages marked as Multi-Arch: allowed can fulfill that dependency.

Multi-arch support greatly enhances system flexibility, enabling you to safely install and run software built for different architectures while ensuring dependency resolution and file consistency are properly maintained.

9.3.6. Validating Package Authenticity

Validating package authenticity is a critical security measure that ensures your system only installs official, unmodified packages—especially important during system upgrades. Kali, like other Debian-based systems, employs a tamper-proof seal based on cryptographic hashes and signatures to guarantee package integrity. Here’s a summary of the key concepts:

Release File and Cryptographic Chain: The Release file from the mirror contains a list of Packages files (in various compressed formats) alongside their MD5, SHA1, and SHA256 hashes. This chain of hashes, secured by a digital signature, confirms that neither the Packages file nor the actual package contents have been tampered with.
Trusted Keys and apt-key:
- Trusted GPG keys are used to verify these signatures. They are managed via the apt-key command, which maintains a keyring of public keys (now preferably managed in /etc/apt/trusted.gpg.d/).
- Official keyrings are typically updated automatically by packages like kali-archive-keyring. However, during the first installation, administrators should verify the fingerprints of these keys to ensure trustworthiness.
Handling Third-Party Sources:
- When adding a third-party repository, you must also import its public key (commonly provided as a small text file such as key.asc) using:
  apt-key add < key.asc
- Graphical tools like Synaptic (via its Authentication tab) or dedicated applications such as gui-apt-key can also manage trusted keys.
Security Implications: With proper key management, APT will verify signatures before performing risky operations like upgrades or new package installations. If a package’s authenticity can’t be confirmed, the package manager issues a warning—helping to prevent potential malicious code from being installed.

By leveraging this robust system of cryptographic verification and trusted key management, you ensure that every package installed is verified and has not been modified by an attacker.

9.4. APT Package Reference: Digging Deeper into the Debian Package System

This section takes you beneath the surface of APT and the Debian/Kali package system to reveal how packages are structured and how meta-information is embedded within them. Understanding these details can help you customize and troubleshoot your system at a deeper level. Here are the key points:

Deeper Understanding Beyond Tools: The focus here is not just on using APT's front-end commands but on understanding the fundamental structure of Debian packages—knowledge that can streamline and customize your Kali system.
.deb File Structure: A .deb file is essentially an ar archive composed of three main parts:
- debian-binary:
  - Contains a single version number (e.g., "2.0") that indicates the archive format.
- control.tar.gz:
  - Houses meta-information including configuration files and scripts such as:
    control (package description and metadata)
    conffiles (list of configuration files)
    md5sums (checksums for verifying file integrity)
    Maintenance scripts (preinst, postinst, prerm, postrm)
    Other metadata files like shlibs and triggers
- data.tar.xz:
  - Contains the actual files that will be installed on your system. These files are organized according to the system’s file hierarchy (for example, /etc/apt/, /lib/, etc.).
Why This Matters: By understanding the internal structure of a package, you gain insight into:
- How meta-information controls package installation and configuration.
- The role of maintenance scripts and dependency data.
- Methods to troubleshoot issues by examining package internals.

In summary, digging into the Debian package system—from its .deb structure to its embedded meta-information—equips you with a more profound understanding of how APT works behind the scenes. This knowledge is invaluable for advanced system customization and effective problem-solving as you further master the Kali Linux environment.

9.4.1. The control File

The control file—found inside the control.tar.gz archive of a .deb package—is the central source of meta-information about a package. Its structure resembles email headers, and you can inspect it using the command dpkg -I package.deb control. This file not only defines basic package metadata (name, version, architecture, maintainer, etc.) but also outlines how the package interacts with other packages through dependencies, conflicts, and more.

Key Fields in the Control File:

Dependencies:
- Depends: Lists the conditions that must be met for the package to function correctly. Version restrictions can be applied using comparison operators (e.g., libc6 (>= 2.15)). Multiple conditions separated by commas are treated as logical AND, while the vertical bar (|) denotes logical OR (with precedence over AND).
- Pre-Depends: Similar to Depends but even more strict. A pre-dependency requires the specified package to be fully installed and configured before the pre-installation script of the dependent package is executed. This imposes strict ordering constraints and is generally discouraged unless absolutely necessary.
Recommendations and Suggestions:
- Recommends: Lists packages that, while not essential, significantly enhance the functionality of the package. These should typically be installed.
- Suggests: Identifies optional packages that could complement the package, though installation is left to the administrator’s discretion.
- Enhances: A field placed in the suggested package rather than in the primary package. It allows extensions or add-ons to be associated with the base software without modifying the original package.
Conflict Management:
- Conflicts: Specifies packages that cannot coexist with the current package, usually due to file clashes or overlapping functionality. If a conflict is detected, APT offers to remove the conflicting package.
- Breaks: Indicates that the installation of this package will break specific versions of another package. This field is used to preempt issues from incompatible updates by ensuring that any package known to be broken gets updated or removed.
Virtual and Replacement Relationships:
- Provides: Introduces the concept of virtual packages. This field allows a package to declare that it offers a generic service or even replace another package entirely, satisfying dependencies that require a particular capability (for example, mail-transport-agent for mail servers). This mechanism is key for metapackages, which depend solely on other packages.
- Replaces: Signifies that a package contains files that are also present in another package, permitting dpkg to overwrite them safely. This is crucial when package names change, when one package is merged into another, or when files are redistributed among binary packages derived from a single source.

Metapackages vs. Virtual Packages:

Metapackages are actual packages whose primary role is to pull in a group of related packages via dependencies (e.g., kali-linux-large or gnome).
Virtual Packages don’t exist as installable files; they serve as logical names to represent a capability or service provided by one or more real packages.

Understanding the control file and these various fields not only clarifies how Debian’s package system manages inter-package relationships but also provides the insight needed for advanced customization and troubleshooting. This deeper knowledge helps ensure that dependencies are met correctly, conflicts are managed, and the system maintains consistent and reliable software behavior.

9.4.2. Configuration Scripts

Each Debian package contains a control file along with a compressed archive (control.tar.gz) that may include several maintenance scripts. These scripts—preinst, postinst, prerm, and postrm—are called by dpkg at various stages during package management. You can inspect these files within a package archive using the command:

dpkg -I /var/cache/apt/archives/zsh_5.3-1_amd64.deb

This output shows not only the control file but also the scripts (with their shebang lines, like #!/bin/sh), which are executed at different points during installation, removal, and upgrades.

The dpkg Database Structure

The dpkg database, which maintains a record of all installed packages, is found on the filesystem at /var/lib/dpkg/. Here are some important details:

Configuration Scripts Directory: The /var/lib/dpkg/info/ directory contains files for each package (prefixed by the package name). For example, for zsh you might see:
- zsh.list – lists all files installed by the package.
- zsh.md5sums – contains MD5 checksums.
- zsh.postinst, zsh.postrm, zsh.preinst, zsh.prerm – the respective configuration scripts.
Package File List: The .list file for each package enumerates every file installed by that package. Running:
```
head /var/lib/dpkg/info/zsh.list
```
might show a directory hierarchy starting from root, listing directories like /bin, /usr, etc.

Status File: The /var/lib/dpkg/status file contains a series of data blocks (formatted similarly to email headers as per RFC 2822) that describe each package’s current state. For example:

Package: gnome-characters
Status: install ok installed
Priority: optional
Section: gnome
Installed-Size: 1785
Maintainer: Debian GNOME Maintainers
Architecture: amd64
Version: 3.20.1-1
[...]

Interaction of Configuration Scripts

The Debian policy clearly defines when each configuration script is called. The scripts are executed at different stages, ensuring that the system remains in a consistent state during installations, updates, or removals. In general:

preinst (Pre-installation script) is executed before the package is unpacked or installed.
postinst (Post-installation script) runs after the package is installed.
prerm (Pre-removal script) is invoked before package removal.
postrm (Post-removal script) is executed after the package has been removed.

When packages are updated, the process is conceptually split into removing the old version and installing the new one. It is important to note that the scripts from the old version (e.g., old-prerm) and the new version (e.g., new-preinst) are used at different stages.

Installation/Upgrade Sequence

The installation or upgrade of a package follows a carefully orchestrated sequence:

For an Update:
- Old Package Phase:
  - old-prerm is called with the arguments indicating an upgrade and the new version.
- New Package Phase (Pre-installation):
  - new-preinst is executed. If it is a first-time installation, it is called with install; for an upgrade, with upgrade and the old version as an extra parameter (in cases where the package was previously installed and then removed without purging).
- Unpacking Files:
  - The new package files are unpacked. If an existing file is replaced, dpkg creates a temporary backup.
- Post-removal of Old Version:
  - old-postrm is called to complete removal-related tasks for the old version.
- Data Update:
  - dpkg updates its internal database (file lists, scripts, etc.) and then removes the backup copies of replaced files. At this stage, reverting to the previous version becomes impossible.
- Configuration Files Handling:
  - dpkg manages the package configuration files (including prompting the user if there are conflicts or changes in the configuration).
- Final Configuration:
  - new-postinst is executed with the argument configure (and the previous version’s configuration details as a parameter) to complete the installation process.

Package Removal Process

Removing a package follows its own sequence:

Pre-removal:
- prerm is called with the argument remove.
File Removal:
- dpkg removes the package files, excluding configuration files and configuration scripts.
Post-removal:
- postrm is executed with remove. After this step, if the user has not opted for a purge, only the configuration files remain.
Purging a Package:
- When a package is purged (using dpkg --purge or dpkg -P), the process goes further:
  - dpkg deletes the configuration files, temporary files (like *.dpkg-tmp, *.dpkg-old, *.dpkg-new), and then calls postrm with the purge argument.

Debconf and Its Role

Some packages require additional configuration information from the user. To avoid the need for interactive responses in every script (which could otherwise delay installations), Debian uses debconf. Key points about debconf include:

Centralized Question Management:
- It allows package developers to define what questions to ask, and these are grouped together at the beginning of the process (often by front-end tools like apt), minimizing interruptions during installation.
Localization and Flexibility:
- The strings and questions can be localized since all translations are stored in the debconf templates file.
- Different frontends (text mode, graphical, non-interactive) ensure that user interaction is handled appropriately according to the system or user preferences.
Database of Responses:
- All user responses are stored in a central debconf database. This permits sharing the same configuration settings across multiple systems if desired.
Usage in Configuration Scripts:
- The pre- and post-installation scripts can then make decisions or perform actions based on the information gathered by debconf, making the installation process smoother and more automated.

9.4.3. Checksums, Conffiles

In addition to the maintainer scripts and control data, a Debian package’s control.tar.gz archive may include several other important files. For example, when you inspect a package such as bash_4.4-2_amd64.deb using the command:

ar p /var/cache/apt/archives/bash_4.4-2_amd64.deb control.tar.gz | tar -tzf -

you may see the following files:

./ (directory entry)
./conffiles
./control
./md5sums
./postinst
./postrm
./preinst
./prerm

Key Files and Their Purposes

md5sums This file contains the MD5 checksums for all files included in the package. Its primary function is to allow the dpkg --verify command to check if any package file has been modified since its installation.
- Note: If the md5sums file is missing, dpkg will generate it dynamically during installation and store it in the dpkg database, ensuring that file integrity can be verified.
conffiles This file lists the package files that are considered configuration files. These files are treated specially because they may have been modified by the system administrator.
- Handling during Updates: dpkg attempts to intelligently manage these configuration files during package upgrades:
  - Unmodified Configuration: If the configuration file has not been changed between versions, dpkg takes no action.
  - Automatic Replacement: If the administrator has not modified the configuration file, dpkg automatically installs the new version.
  - Modified Configuration: If the file has been changed by the administrator, dpkg prompts the administrator to decide between:
    Keeping the modified (old) version,
    Accepting the new version from the package.
  - Assistance with Decision Making: dpkg offers a diff showing the differences between the two versions. Based on the choice:
    The new file may be saved with a .dpkg-dist suffix if the old version is retained.
    The old file may be kept with a .dpkg-old suffix if the new version is accepted.
    Alternatively, dpkg can be temporarily interrupted so that the administrator can edit the file and merge the changes manually.

Automating Configuration File Handling

Since asking the administrator for input on configuration file updates can interrupt the package management process, dpkg provides options to automate these decisions:

--force-confold: Instructs dpkg to always retain the old configuration file, even if it has been modified.
--force-confnew: Forces dpkg to always use the new configuration file provided by the package.
--force-confdef: Allows dpkg to automatically decide which version to keep when possible—using the new file if the configuration file has not been touched, and otherwise defaulting to either the new or the old version based on internal heuristics.

These options are typically passed to dpkg; however, since most package management is done via apt or aptitude, they must be specified using their respective configuration syntaxes. For example, one can run:

apt -o DPkg::options::="--force-confdef" -o DPkg::options::="--force-confold" full-upgrade

Alternatively, these options can be set permanently by adding the following lines to the /etc/apt/apt.conf.d/local file:

DPkg::options { "--force-confdef"; "--force-confold"; }

This ensures that the options are applied even when using a graphical interface like aptitude.

Forcing Configuration Prompts

While the above options automate decisions, there might be cases where the administrator wants dpkg to ask configuration file questions regardless of the file's modification status. This is achieved with the:

--force-confask option This forces dpkg to display configuration questions even if they wouldn’t normally be prompted.
- Use Case: This is particularly useful when reinstalling a package that has missing configuration files (for example, if the original configuration file was deleted). Normally, dpkg might not reinstall the configuration file because it considers removal a valid modification. Using --force-confask ensures that the configuration questions are asked, enabling you to reinstall the default configuration.

9.5. Summary

Key Concepts and Tools

Debian Package Structure:
- A Debian package is not just a collection of files; it includes:
  - Application binaries and resources.
  - Metadata such as dependencies and version information.
  - Lifecycle scripts (e.g., preinst, postinst, prerm, postrm) that run at different stages (installation, removal, upgrades).
dpkg vs. APT:
- dpkg is the core package manager that works at a low level; it installs or removes a specific package but does not resolve dependencies.
- APT (and its variants like apt-get and aptitude) automatically handles dependencies and maintains a list of available packages, making it the preferred choice for day-to-day package management.

APT Configuration and Usage

Sources List and Repositories:
- The sources.list file is the primary configuration file for defining repositories.
- Debian and Kali distinguish packages into:
  - main: Fully compliant with Debian Free Software Guidelines.
  - non-free: Packages that do not entirely conform but can still be distributed.
  - contrib: Open source packages that require non-free elements to function.
- Kali’s repositories include:
  - kali-rolling: Main repository for end-users with installable, up-to-date packages.
  - kali-dev: Reserved for development purposes and not intended for general public use.
Basic Package Operations with APT:
- Updating the Package List: Run apt update to download the latest list of available packages.
- Installation: apt install package installs the desired package along with its dependencies.
- Removal: apt remove package deletes the package along with any reverse dependencies.
- Purging: apt purge package removes the package and its associated configuration files and sometimes user data.
Upgrading the System:
- For routine upgrades (security updates and minor changes), use:
  - apt update followed by apt upgrade (or its variants, such as apt-get upgrade or aptitude safe-upgrade), which upgrade packages without removing any.
- For major upgrades that might require package removals or new dependencies, use:
  - apt full-upgrade, especially important for systems like Kali Rolling.
APT Cache and Disk Usage Management:
- Inspection Tools:
  - dpkg --listfiles package (or -L): Lists all files installed by a package.
  - dpkg --search file (or -S): Identifies which package a file belongs to.
  - dpkg --list (or -l): Shows installed packages and their statuses.
  - dpkg --contents file.deb (or -c): Lists files in a .deb package.
  - dpkg --info file.deb (or -I): Displays package header information.
- Cache Cleanup:
  - apt clean (or apt-get clean): Empties the /var/cache/apt/archives/ directory completely.
  - apt autoclean (or apt-get autoclean): Removes obsolete packages no longer available from the mirror.
Graphical and Interactive Tools:
- aptitude: An interactive, semi-graphical tool that helps in both installation and troubleshooting.
- synaptic: A graphical package manager with an efficient interface for managing packages.
Advanced APT Configuration:
- Advanced users can fine-tune APT by creating configuration files in /etc/apt/apt.conf.d/.
- This allows control over package priorities, tracking of automatically installed packages, managing multiple architectures or distributions, and even enforcing cryptographic package validation.

Troubleshooting and Upgrades

Despite the careful design of the Debian and Kali package systems, upgrades may sometimes encounter issues. In such cases:

Bug Trackers: Consult the Kali bug tracker or the Debian bug tracking system (https://bugs.debian.org/package) to check for known issues.
Downgrading and Debugging: You might need to downgrade a problematic package or debug its maintainer scripts to restore system stability.

Hacker's Mantra: The best way to predict the future is to invent it. -- Alan Kay

Previous8. Securing and Monitoring Kali Linux Next10. Advanced Usage

Last updated 1 month ago

Was this helpful?