> ## Documentation Index
> Fetch the complete documentation index at: https://dpos.xdr.ooo/llms.txt
> Use this file to discover all available pages before exploring further.

# Current vs. Historical Guidance

> Understand which older 6.5.0, apt-cacher-ng, and full-mirror procedures have been superseded by the current Mirror Manager.

# Current vs. Historical Guidance

Several internal PDFs and QA runbooks were created while the DP OS upgrade workflow was evolving. They remain useful as historical test evidence, but they do not all describe the current operator workflow.

## Current source of truth

For this documentation site, the current `main` branch of:

```text theme={null}
xdr-labs/ubuntu-mirror-automation
```

is the primary implementation source.

The current workflow uses:

* **DP 6.6.0** as the fixed Phase 2 target
* one Mirror Manager GUI
* a selective OS Core package from Cloudflare R2 in Full mode
* DP Phase 2 artifacts from the immutable Cloudflare R2 release prefix
* nginx HTTP distribution to DP hosts over TCP 80
* generated Menu 7 DP client commands

## Historical procedures

Older documents may describe:

* DP 6.5.0 as the Phase 2 target
* `bringup_py3_dp_after_os_upgrade.sh --version 6.5.0`
* an `apt-cacher-ng` cache server on TCP 3142
* a traditional full Ubuntu `apt-mirror` requiring hundreds of GB or multiple TB
* direct Canonical repository access from each DP
* direct ACPS runtime downloads for DP Phase 2 artifacts

Those procedures correspond to earlier development/QA stages and should not be mixed into the active Mirror Manager workflow unless engineering explicitly asks for a historical path.

## Why this matters

Combining commands from different generations can produce incorrect artifact versions, stale server addresses, incompatible package sources, or an unsupported recovery path.

Use the current Mirror Manager, require Menu 4 `PASS`, and use Menu 7 commands generated by the same installed version of the tool.