Offline Repositories, Mirrors and Disconnected Installation

A disconnected host still needs a way to receive authenticated software and security fixes. A cache, a mirror and a portable bundle solve different problems: a cache retains requested objects, a mirror copies a defined repository set, and a bundle carries a selected transaction. None is current or trustworthy merely because it is nearby.

Design the supply route

Record the target release and architecture, enabled components, installed packages, storage capacity and update cadence. Decide who approves sources and signing keys, how metadata and packages cross the boundary, who verifies them, and how old snapshots are retained for recovery. A mirror can carry signed upstream metadata unchanged; an internally assembled repository needs its own signed release metadata and an independently provisioned, scoped trust key. Protect the signing key separately from the distribution server.

APT authenticates repository release metadata, which identifies index hashes; indexes in turn identify package hashes. Transport encryption can protect the connection but does not replace repository authentication. Conversely, valid signatures do not establish that software is appropriate for the target or that its metadata is fresh. A release’s expiry can make an old snapshot unusable; handle freshness through an explicit policy rather than disabling verification to get past an error. The APT authentication manual explains this trust chain.

A cache saves bandwidth only for objects it has retained and may need network access on a miss. A mirror needs sufficient space for all selected architectures, components and versions; incomplete synchronization can temporarily mix metadata with missing packages. Publish a completed, verified snapshot atomically and test it before clients consume it. Preserve source packages and required licenses when your policy requires them.

Inventory a target without changing it

Use the bl05-packages-lab clone. Keep its network configured for this observation; no sources will be added or disabled. Record release and architecture along with current sources and package state:

cat /etc/os-release
dpkg --print-architecture
dpkg --print-foreign-architectures
apt-cache policy
dpkg-query -W -f='${binary:Package}\t${Version}\t${db:Status-Status}\n' \
  > "$HOME/bl05-package-inventory.tsv"

The inventory file is written in the lab user’s home and may disclose installed software. It is not a complete list of repository configuration, package selections, dependencies or application data. Keep it with the target’s change record and restrict distribution as appropriate. Review enabled source files and scoped signing keys as described earlier in this part. Inspect the package candidates required by a proposed change:

apt-cache policy tree
sudo apt-get -s install tree

This simulation uses the target’s current local indexes and state. It neither downloads packages nor guarantees that another host will resolve the same transaction. tree is only an example; the preceding lab removed it. Do not install it during this inspection.

Prepare and verify a transfer

A connected staging system must use a repository snapshot and target-compatible release, architectures, source configuration and package state. Resolve the whole transaction, including dependencies, on a representative target or controlled equivalent. Export the required signed metadata, indexes and package files using your chosen mirror or bundle tooling. Authenticate the portable media or transfer manifest independently; then verify repository signatures and hashes at the receiving side. A checksum copied beside a file on the same untrusted medium cannot by itself authenticate either file.

Test the procedure on a disposable host with its external network disconnected. Configure the approved local source using a scoped Signed-By key that was provisioned through a separate trusted channel; do not use trusted=yes to bypass a signature failure. Run apt update, inspect apt-cache policy and simulate the planned installation. If resolution wants a missing dependency or another repository, stop and rebuild the bundle or snapshot; do not silently reconnect the supposedly isolated host. Apply only a reviewed proposal, then validate package state and the workload. Record the snapshot identity, transfer date, signatures, versions, results and next update deadline.

The exact source stanza depends on how the repository is published. The Ubuntu sources.list manual describes deb822 sources and Signed-By. A directory of .deb files alone is not a signed APT repository. For a full implementation, also plan key rotation, revocation, repository expiry, storage monitoring, audit trails and emergency transport.

Diagnose and practice

If apt update reports a signature error, preserve the exact message and check the source URL, key identity, release metadata, clock and snapshot completeness. An expired release, wrong key and corrupted metadata require different fixes. If installation fails with an unavailable dependency, compare the candidate versions and architecture with the snapshot manifest; copying only the requested package rarely captures the full dependency closure.

Draw a supply route from upstream to the isolated host and mark the trust check and responsible owner at each crossing. Describe how you would test a stale or incomplete snapshot without changing a production host.