# LinuxMirrors: shell scripts that repoint apt and yum at another mirror > Four shell scripts and a documentation site whose whole job is rewriting package repository URLs across roughly twenty GNU/Linux distributions. It is built for the first ten minutes after an install, and it stops being interesting well before that. **SuperManito/LinuxMirrors** — Scripts to switch GNU/Linux system package mirrors, plus scripts for Docker installation and mirror switching. - Repository: https://github.com/SuperManito/LinuxMirrors - Website: https://linuxmirrors.cn - Stars: 7,789 · Forks: 706 - Language: Shell - License: MIT - Published: 2026-10-08 · Updated: 2026-10-08 · Language: en - Canonical page: https://hysenlabs.com/projects/supermanito-linuxmirrors ## Four scripts at the top of a documentation site The repository is much smaller than its popularity suggests. The top level holds four shell scripts, three README files, three changelog files, and the source for a documentation website. `ChangeMirrors.sh` and `ChangeMirrorsLite.sh` rewrite the operating system's own package sources. `DockerInstallation.sh` and `DockerInstallationLite.sh` install Docker and point it at a mirror. Everything else is the website: a `docs/` directory, a `locales/` directory, `mkdocs.yml`, and `netlify.toml`. The pairing is the interesting structural decision. Every script has a Lite twin, so the project assumes you want to choose up front how much of the system it touches. What the Lite variants actually skip is answered on the documentation site rather than on the README front page, which is the normal shape for a project whose audience tends to run a script as root before reading much. The project description is honest about scope: scripts for changing GNU/Linux system software sources, plus Docker installation and mirror switching. That is the entire product. There is no daemon to supervise, no service to configure, and nothing left running once a script finishes. ## The compatibility table is the actual specification Most of the README front page is a two column table, distribution on the left and supported version range on the right, and it is more useful than any prose around it. Debian covers 8 through 13, Ubuntu 14 through 26, Red Hat Enterprise Linux 7 through 10, Fedora 30 through 44, Rocky Linux and AlmaLinux 8 through 10, Oracle Linux 8 through 10, and openEuler 20 through 25. Several rows read simply "all": Kali Linux, Deepin, Zorin OS, Armbian, Proxmox VE, Raspberry Pi OS and openKylin. That shorthand works for distributions whose repository layout has not fragmented across releases, and it is a reasonable claim for the ones listed. Two rows spell out two ranges instead, and they are the two that matter most. CentOS is listed as 7 through 8 plus Stream 8 through 10, and OpenCloudOS as 8.6 through 9 plus Stream 23. Those are entries where the naming convention changed underneath the script, which is exactly the kind of detail a hand maintained tool has to encode and a generic tutorial never does. The repository topics repeat the same ground in tag form, alphabetically from almalinux through ubuntu, including the Proxmox VE and Raspberry Pi OS entries. Two independent lists agreeing is a small but real quality signal for a script that edits configuration files. ## Running a mirror change on a machine that is not installed yet Here is the honest limit of what you can learn from the repository front page: it is a compatibility table, not a tutorial. The README does not spell out an invocation for the scripts it advertises, so the practical starting point is the file list at the repository root plus the documentation site, which is where the per distribution instructions live. That is not a criticism so much as a description of the intended use. This category of tool earns its value in a specific window: the minutes after a minimal server or container image is created, on hardware in a region where the default upstream hosts are slow or partly blocked, with the operator holding a root shell and no package manager configuration worth preserving. Swap the sources, run the update, move on. The same category carries a real risk that the repository does not address. A mirror rewrite changes which server answers for every package name you have not explicitly pinned, so a mirror that is incomplete, stale or slow turns one working machine into one broken machine. There is no rollback script in the top level listing, and nothing in the tree records the previous values for you. If you have a workstation with a carefully chosen set of sources, including backports or third party repositories, running a bulk rewrite over it is a bad trade for a small download speedup. ## Why Docker gets its own scripts Docker installation is a different problem from changing a package mirror, and the repository keeps them in separate files rather than folding the Docker step into the main change. On a minimal Debian or Ubuntu image you need the Docker apt repository configured before the packages exist, and a mirror that carries the operating system's packages frequently does not carry Docker's repository. Treating the two as one operation would produce a script that half works on exactly the machines people reach for it. The separation also matters for hostnames. Changing the OS mirror means editing sources entries such as the ones under `/etc/apt/sources.list`. Configuring Docker means adding a repository with its own GPG key, and the download path then goes through Docker's own resolver. The Lite variants exist for the same reason on both sides: on a locked down or air gapped host, the operator wants to add sources and nothing else. For readers in mainland China this split is the point rather than an implementation detail. The documentation site is at linuxmirrors.cn, the repository carries a `locales/` directory, and there are three README variants: Simplified Chinese, English and Traditional Chinese. The operational guidance is written for an audience where upstream hosts are unreliable. What the table cannot tell you, and the site can, is which specific mirrors are offered for your region and your distribution. ## No releases means no version to pin There are no GitHub releases for this repository, and no version number in anything the README front page shows. You take whatever is on the main branch, whose last push was on 2026-09-08. For a shell script that rewrites system configuration, that is a meaningful difference from a packaged tool, and it is the single most practical thing to know before running anything here. The mitigation is that the scripts are plain shell files you can read first, and a repository of four scripts is a very different risk profile from an opaque installer. `SECURITY.md` and `CODE_OF_CONDUCT.md` are present at the top level, which is more process than a project this size strictly needs. The `.gitee/` and `.github/` directories together show the project is mirrored on two forges, which is common for projects with a large Chinese user base and useful if you want to see commit history from either side. The `CHANGELOG.md`, `CHANGELOG.en-US.md` and `CHANGELOG.zh-Hant.md` trio is the closest thing to a version record. Whether a given script change is a bug fix or a new distribution is usually answerable there, and it is the first place to look when a script behaves differently than the version you used six months ago. ## Building the documentation site locally The documentation is a MkDocs Material project with internationalisation wired in, and its pinned Python dependencies live in a `requirements.txt` at the root. Installing them locally is the ordinary pip invocation: ```bash pip install -r requirements.txt ``` The pins tell you more than the README does about how the site is put together. `mkdocs-material==9.7.7` is the theme, `mkdocs-static-i18n==1.3.1` is what lets one site serve the Simplified Chinese, English and Traditional Chinese variants, `mkdocs-glightbox==0.5.2` handles click to zoom images, and `mkdocs-exclude-search==0.6.7` keeps selected pages out of the search index. `termynal==0.14.0` is there so shell commands in the docs render and animate in the browser, which for a project whose instructions are almost entirely shell commands is a deliberate and sensible choice. One dependency is commented out, `mkdocs-minify-plugin`, so the checked in configuration does not minify output. That is a small window into how the site is actually maintained. Nothing here needs a server, a database or a build pipeline beyond MkDocs, and `netlify.toml` at the root is the deployment descriptor. ## Conclusion LinuxMirrors is a good fit for the window right after a minimal image is installed, especially on a host where the default upstream package hosts are slow, and a poor fit for a workstation you already administer, where the mirrors are configured and a rewrite buys nothing but risk. The distribution table is precise enough to check compatibility in a few seconds, the scripts are small enough to read before running, and the documentation site at linuxmirrors.cn is where the per-distribution steps actually live. What the repository does not give you is a version to pin: there are no releases, so you take whatever sits on the main branch, whose last push was on 2026-09-08. Start by reading `ChangeMirrors.sh` end to end, then check the table row for your distribution and version. ## FAQ ### Which Linux distributions does LinuxMirrors support? The README table covers Debian 8 to 13, Ubuntu 14 to 26, Red Hat Enterprise Linux 7 to 10, Fedora 30 to 44, CentOS 7 to 8 and Stream 8 to 10, Rocky Linux and AlmaLinux 8 to 10, Oracle Linux 8 to 10, openEuler 20 to 25, OpenCloudOS, openKylin, Anolis OS, openSUSE, and entries marked all for Kali Linux, Deepin, Zorin OS, Armbian, Proxmox VE, Raspberry Pi OS and Linux Mint. ### Which LinuxMirrors script should I run to change my package mirror? The repository root lists four scripts: ChangeMirrors.sh and ChangeMirrorsLite.sh for the operating system sources, DockerInstallation.sh and DockerInstallationLite.sh for installing Docker and switching its mirror. The README front page is a compatibility table and does not spell out the invocation, so the per distribution steps are on the documentation site at linuxmirrors.cn. ### Can I install a specific version of LinuxMirrors? No. The repository has no GitHub releases and no version number in the README, so you take whatever is on the main branch, last pushed on 2026-09-08. The changelog files at the repository root are the only record of what changed, and reading the script before running it is a reasonable substitute for a pinned release. ## Sources - [Issues](https://github.com/SuperManito/LinuxMirrors/issues) - [License: MIT](https://github.com/SuperManito/LinuxMirrors/blob/main/LICENSE) - [Project website](https://linuxmirrors.cn) - [README](https://github.com/SuperManito/LinuxMirrors/blob/main/README.md) - [SuperManito/LinuxMirrors on GitHub](https://github.com/SuperManito/LinuxMirrors) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/supermanito-linuxmirrors