You have spent four modules typing sudo apt install without asking where that software comes from, who guarantees nobody tampered with it along the way, or what happens if one night Tramontana's database engine jumps from version 15 to 16 and the application stops starting. Now that you know exactly what sudo lets you do, it is time to understand what you do with it most of the time: install, update and pin software. This lesson covers Debian and Ubuntu's two layers, the cryptographic signing of repositories, version pinning and the uncomfortable debate about whether a server should reboot itself after a security update.

1. What a package manager solves
2. Anatomy of a .deb and a comparison with .rpm
3. The two layers: dpkg versus apt
4. apt day to day
5. dpkg and file archaeology
6. Repositories: deb822, components, pockets and keys
7. Pinning versions: hold and pinning
8. Unattended upgrades, the reboot and cleaning the cache
9. Snap, Flatpak and AppImage versus .deb
10. Compiling from source when there is no alternative
11. Equivalents with dnf on RHEL
12. Tramontana case: dependencies, a pinned version and an audit

Installing software "by hand" — downloading a .tar.gz, compiling it and copying it into /usr/local — looks harmless until the first security update arrives. A package manager solves four problems that have no reasonable manual solution:

• Dependencies: it knows your application needs libssl3t64 and that another twenty programs use that library, so it installs it once and shares it.
• Security updates: one command updates everything installed. With hand-compiled software, the day a critical CVE comes out you will have to remember it yourself.
• Integrity and provenance: every package comes signed and its checksum verified. You know that what gets installed is what the maintainer published.
• Clean uninstallation: the manager knows exactly which files each package brought. A make install does not even leave the list.

An operational rule: compiling is the last resort, and when you have to, do it in /usr/local so as not to tread on what the manager administers.

A .deb is an ar archive with three pieces: debian-binary (the format version), control.tar.zst (metadata and scripts) and data.tar.zst (the files that get installed).

The inter-package relationship fields are the ones doing all the work:

Inside control there are also maintainer scripts — preinst, postinst, prerm, postrm — which run as root at each phase. That is exactly why adding a third-party repository is a security decision and not a convenience: installing a package means running somebody else's code as root.

dpkg knows how to install one .deb file and keep the books on what is installed; it knows nothing about repositories and downloads no dependencies. apt knows how to talk to the repositories, resolve the dependency graph, verify signatures and decide the order, and then it delegates to dpkg.

A note: apt is the interface for humans and apt-get/apt-cache are the stable ones for scripts. In a script use apt-get: apt warns that its interface may change between versions.

The classic confusion: update only downloads the indexes. Without it, apt works from an old snapshot of the repository and will not see the security update published this morning. The difference between upgrade and full-upgrade matters on a server: upgrade is conservative and would rather touch nothing than delete something; full-upgrade accepts removals and is what you need for a distribution version change.

remove versus purge is a real decision: remove lets you reinstall and get your configuration back; purge leaves the system clean. On a server that is documented, purge stops a ghost /etc/whatever turning up in a year's time that nobody knows the origin of.

Querying:

And the option that saves the most disk on a server is sudo apt install --no-install-recommends nginx. The Recommends drag in extras designed for the desktop (documentation, graphical clients, complete mail servers). On a server, every extra package is attack surface and occupied disk. You can make it permanent:

The states in dpkg -l are read as two letters: the first is the desired state and the second the actual one. ii is "installed and installed"; rc is "removed but configuration files remain" (candidates for purge); iU or iF indicate a half-finished installation, which is fixed with sudo dpkg --configure -a (it finishes interrupted configurations) and sudo apt -f install (it repairs broken dependencies).

To look for a file in packages you do not have installed:

Ubuntu 24.04 abandoned the one-line format of /etc/apt/sources.list and uses deb822, which is far more readable, in /etc/apt/sources.list.d/*.sources:

The file carries a second, identical block with URIs: http://security.ubuntu.com/ubuntu/ and Suites: noble-security, which is the one that brings the patches.

Every repository signs its Release index with a GPG key. In the past all the keys went into a global keyring (apt-key add), which meant that any third-party repository could sign any package, including a fake openssh-server that replaced the official one. That is why apt-key is obsolete and has been removed in 24.04. Today the key is stored in a file and tied to that repository with Signed-By:.

Adding a third-party repository is a security decision. You are authorising a third party to run code as root on your server every time you update, and to replace packages if you do not limit their scope. Before adding it: check who publishes it, use HTTPS, tie the key with Signed-By, restrict Components to what is needed and, if you really care, apply pinning so that it can only supply the packages you intend. In a corporate environment this decision must be validated by the security officer.

Ubuntu's PPAs are Launchpad repositories that sudo add-apt-repository ppa:user/project adds along with their key. Convenient on the desktop; in production, every PPA is an individual maintainer you become dependent on.

There is software that cannot update itself. Tramontana's database engine is the textbook case: a major version jump means migrating the data format, and doing that at 06:00 unsupervised means an application that is down and a complicated rollback.

The simple way, with dpkg:

A package on hold is not touched by upgrade, nor by full-upgrade, nor by unattended-upgrades.

The more controlled way, APT pinning, lets you decide which origin each thing comes from:

apt-cache policy is the tool that confirms your pinning does what you think. Always check it: a badly written pin gives no error, it simply does not apply.

A server without security patches is only a matter of time. Ubuntu includes unattended-upgrades, which by default installs only what comes from the -security pocket:

The automatic-reboot debate has no universal answer. A kernel or glibc update has no effect until you restart the affected processes or the machine:

For Tramontana, with a single server and no high availability (which is the subject of 07-07), the reasonable decision is false plus an alert Marta receives, plus a written commitment to a weekly window. And the indispensable habit: a VM snapshot before a big update, which on a real server is an LVM or hypervisor snapshot (05-04).

And the cleanup, which on a server with /var on its own partition — like the one you partitioned in 01-04 — prevents a full disk: du -sh /var/cache/apt/archives usually gives hundreds of megabytes, which sudo apt clean deletes entirely and apt autoclean only for what has already been withdrawn from the repository; old kernels are cleaned by apt autoremove --purge.

Ubuntu ships snapd as standard, and some pieces (such as lxd or certbot) are distributed that way. What you need to know on a server: snaps update on their own and their pace can be postponed but not cancelled, which clashes head-on with a controlled-change policy.

--prefix=/usr/local is not a detail: the FHS from 01-06 reserves that tree for what the administrator installs, precisely so that it never collides with what dpkg manages in /usr. And since make install leaves no record, checkinstall exists, wrapping the installation in a real .deb:

Now it uninstalls cleanly with apt purge tool. Even so, there is still nobody to warn you about its security flaws: that watch becomes yours.

Picking up the families from 01-03, this table lets you work on Rocky, Alma or RHEL without learning anything again:

The most striking practical difference: dnf history undo reverses an entire transaction, something APT does not offer. On Debian/Ubuntu you go back by reinstalling specific versions worked out from history.log.

First, the server's dependencies, with no recommends and with verification:

Second, we pin the database so that no unattended upgrade raises its major version:

And we add the explicit pinning in /etc/apt/preferences.d/99-tramontana-bd that you saw in section 7, plus the blacklist in 50unattended-upgrades. A mandatory verification:

Third, Marta's question this morning: "what was updated last night and why?".

The answer for Marta, with the usual structure — what it protects and what it does not protect —: "Last night OpenSSL was updated because of a security flaw that allowed the TLS service to be brought down. It protects the encryption of incoming connections. It protects nothing else, and it will not take full effect until we restart the services that already had the library loaded; needrestart says tramontana.service is one of them. I propose restarting it in Thursday's window. The database is still pinned to the 16 series and has not been touched." And into the HISTORY:

• Believing that apt update updates anything. It only refreshes the list; the correct pair is apt update && apt upgrade, and the && is not decorative: if the update fails, upgrading with old indexes is worse than not upgrading.
• Using apt in scripts instead of apt-get with DEBIAN_FRONTEND=noninteractive, or plain dpkg -i, which installs without dependencies and leaves the system in the iF state (use apt install ./file.deb).
• Adding a repository with apt-key. Removed in 24.04 and insecure by design: the key goes in /etc/apt/keyrings/ and Signed-By: in the .sources.
• Forgetting the -security pocket. Without it the server goes unpatched, and it gives no error at all. And do not update without a snapshot or a window: the day something breaks, the difference between 5 minutes and 5 hours is having taken the snapshot.
• Leaving a hold in place and forgetting it. A held package does not receive security patches either: review apt-mark showhold every month and write down who decided each hold and until when.
• Tip: keep apt-mark showmanual > packages.txt alongside your backups. Rebuilding a server from that list is a matter of minutes.

1. Simulate before acting. Find out which packages would be updated right now and how much disk they would take, without installing anything. Then check whether any of them requires a system reboot.
2. A third-party repository set up properly. Describe the complete, safe steps to add a fictitious repository https://apt.tramontana.example/ (suite noble, component main) that should only supply the tramontana-agent package, and state how you would verify it cannot replace system packages.
3. The forensics of an update. A colleague says "somebody installed nginx by hand on Tuesday". Demonstrate with commands when it was installed, whether it came from a repository or from a standalone .deb, and which configuration files it contributes.

1.

--simulate (or -s) is APT's --dry-run, and it fits the course's convention of simulating before acting. For the reboot: [ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs || echo "No reboot required".

2. The steps, in order:

Verification: sudo apt update must give no signature warnings, and apt-cache policy openssl must still show noble-security as the candidate's origin. That priority-1 pin is the safety net that stops a third-party repository hijacking a system package.

3.

It came from the official repository (noble-updates), luis asked for it on 13 August with apt install, and it contributes conffiles that apt will protect in future updates. Note the Requested-By field: history.log records the real UID behind the sudo, which links directly to the traceability of the previous lesson.

The software on srv-tramontana no longer appears by magic. You know that a package manager solves dependencies, updates, integrity and clean uninstallation, and that compiling is the last resort; you know the anatomy of a .deb — including the maintainer scripts that run as root, which is the underlying reason for all the caution around repositories — and its equivalence with .rpm; you tell the dpkg layer from the apt layer and you know when each one applies; you handle update/upgrade/full-upgrade, remove versus purge, --no-install-recommends, depends/rdepends and the archaeology of dpkg -L, dpkg -S and apt-file.

You understand Ubuntu 24.04's repositories in deb822 format, their components and their pockets, and why the key goes in /etc/apt/keyrings/ with Signed-By: instead of the late apt-key. You know how to pin versions with apt-mark hold and with pinning, verify it with apt-cache policy, and that a forgotten hold leaves a package unpatched. You have configured unattended-upgrades so that it installs security only, warns Marta and does not reboot on its own, and you know how to read /var/run/reboot-required and needrestart. And you can place snap, Flatpak and AppImage, compile into /usr/local with checkinstall when you have to, and translate all of it into dnf.

What remains is the resource everything else depends on and that nobody looks at until it runs out: the disk. /srv/tramontana/backups has been growing for weeks, the 04:20 backup writes every night without anybody having worked out how much fits, and the apt cache you have just cleaned was a symptom, not the cause. In Disk Management you will see the full stack from the physical device to the mount point, MBR and GPT partitions, filesystems compared, /etc/fstab field by field — and why one badly written line there stops the server booting —, the case of the deleted file that does not free up space, and LVM, with which you will add a new disk to the VM and move /srv/tramontana/backups to its own volume without losing a single byte.