Package repositories and version pinning
You manage signed repositories, local mirrors, version pinning and priorities, and run your own repository for offline networks.
Level 301 · 18 lessons · 15 practice labs
Lessons
How repositories work
- Anatomy of an APT repository: Release, InRelease and Packages
- Anatomy of an RPM repository: repodata and modules
- Repository signatures and key management: signed-by
- The deb822 format and tidy source lists
- Short task: safely repair a repository whose key has expired
Version control
- APT pinning and priorities
- apt-mark hold and dnf versionlock
- Downgrading a package
- Backports and third-party repositories: weighing the risk
- Short task: pin the version the app runs on and update everything else
Running your own repository
- A local APT repository with reprepro
- A local RPM repository with createrepo
- Syncing a mirror: apt-mirror and reposync
- A package caching proxy: apt-cacher-ng
- Getting updates into an offline network
- Short task: point internal servers at the local mirror
Wrap-up
- A repository audit: which server takes packages from where
- Capstone: build a signed internal repository and move every server onto it
Practice labs
- Find which repository a package comes from: Query a package's candidate versions and source repository and submit the number of enabled repositories.
- Fix a repository failing signature checks with the right key: For a repository that fails signature verification, add its key so that it is trusted for that repository only.
- Find the cause of broken repository metadata: On a repository with hash mismatches, compare the proxy cache with the real file, find the cause and fix it on Debian and Rocky clients.
- Hold a package at a version: Exclude the database package from updates, run an upgrade and show the version did not change.
- Control version choice with repository priority: Write a priority rule so the organisation's repository wins for a package found in two repositories and verify the candidate version changed.
- Roll back a bad version with its dependencies: Downgrade a library update that broke an application to an older version consistent with its dependants and pin it against re-upgrade.
- Build a small repository from local packages: Create a directory-based repository from three package files, add it to a client and install one of the packages from it.
- Sign your own repository and verify it on a client: Sign Göktaşı Yazılım's internal repository with a new key and install a package on a client without allowing unsigned installs.
- Align servers with a dated mirror snapshot: Publish a dated snapshot of a repository mirror, point Debian and Rocky clients at it and prove two servers received identical versions.
- Limit a third-party repository to one package: Write a rule that stops an external repository meant only for a monitoring tool from replacing any other package.
- Audit unused and insecure repository definitions: Scan repository definitions on the servers and report in a table those with signature checks off, using HTTP or no longer responding.
- Rotate a repository signing key without an outage: Replace an internal repository's expiring key with a new one and show clients can still update throughout the changeover.
- Prepare a package bundle for an offline server: Download a tool with all its dependencies into an archive and install it on an isolated server from that bundle alone.
- Set up a package caching proxy and connect clients: Set up a caching proxy for branch servers, redirect two clients and show from the log that the second install came from cache.
- Build a repository with test and production channels: Set up a two-stage repository where packages land in a test channel and move to production after approval, and promote one package.
About this course
You manage signed repositories, local mirrors, version pinning and priorities, and run your own repository for offline networks.
What you will learn
- How repositories work
- Version control
- Running your own repository
- Wrap-up
Prerequisites
You should be comfortable with the level 101 and 201 topics of the same path.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 301; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.