Репозиторий пакетов недоступен: поднимаем своё зеркало за вечер

MAATRIX

apt update зависает на середине списка, apt-get install падает по таймауту, а yum/dnf ругается на недоступный baseurl — знакомая картина для тех, кто держит инфраструктуру в России. Официальные зеркала Debian, Ubuntu или CentOS то доступны, то нет, скорость то нормальная, то падает до нескольких килобайт в секунду, а иногда репозиторий просто блокируется целиком на уровне провайдера. Хорошая новость: своё зеркало пакетов — это не месяц проектной работы, а вполне реальная задача на один вечер для одного администратора, если правильно выбрать инструмент и не пытаться зеркалировать всё подряд.

Почему официальный репозиторий становится недоступен

Проблема обычно приходит с одной из трёх сторон. Первая — сетевая: маршрут до зарубежного зеркала идёт через узкие или перегруженные каналы, и скачивание пакета, которое раньше занимало секунды, растягивается на минуты. Вторая — блокировки на уровне DPI или провайдера, когда конкретный IP или диапазон CDN попадает под раздачу вместе с другими ресурсами того же облака (Debian и Ubuntu часто раздаются через Fastly и подобные CDN, которые используются и для множества других сервисов). Третья — сам репозиторий, который может быть временно недоступен из-за собственных проблем на стороне мейнтейнеров, независимо от вашей геолокации.

Для разового сбоя достаточно переключиться на другое зеркало из списка. Но если недоступность повторяется неделя за неделей, а обновления безопасности откладываются, потому что apt update не может достучаться до сети — это сигнал держать своё зеркало, которое не зависит от внешних маршрутов.

Второй довод — если серверов несколько (пять, двадцать, сто), каждый из них тянет пакеты с внешних зеркал независимо, гоняя один и тот же трафик через один и тот же неустойчивый канал. Локальное зеркало решает и доступность, и избыточный внешний трафик одним действием.

Выбор инструмента: не усложняйте

Для зеркалирования apt-репозиториев (Debian, Ubuntu) практически стандартный выбор — apt-mirror. Это простой Perl-скрипт, который читает конфиг со списком репозиториев и веток, скачивает всё через wget-подобный механизм и поддерживает структуру каталогов один в один с оригиналом — это важно, потому что клиентам не нужно ничего менять в логике работы apt, только путь до зеркала.

Альтернативы стоит знать, но для вечерней задачи они, как правило, избыточны:

• debmirror — более гибкий, умеет выборочно тянуть архитектуры и компоненты, но сложнее в первичной настройке.
• aptly — не просто зеркало, а полноценный менеджер репозиториев со снапшотами и версионированием; хорош, если вам нужно управлять несколькими версиями пакетов одновременно, но это отдельный уровень сложности, не нужный для базовой задачи «поднять зеркало, чтобы сервера могли обновляться».
• rsync напрямую с зеркала-источника — работает, если у апстрима есть открытый rsync-модуль (у многих официальных зеркал Debian/Ubuntu он есть), и в некоторых случаях это даже проще apt-mirror, потому что не нужно разбираться с отдельным конфигом — команда rsync с нужными флагами и есть весь процесс.

Для RPM-дистрибутивов (CentOS, AlmaLinux, RockyLinux, а также отечественные RPM-based системы) стандартный инструмент — reposync из пакета dnf-utils/yum-utils, который скачивает пакеты репозитория целиком в локальный каталог, плюс createrepo для генерации метаданных зеркала. О различиях между apt- и rpm-мирами — почему одна и та же логика («настроить репозиторий, обновить пакет») в этих семействах реализована по-разному — можно почитать в статье про различия команд ALT Linux apt и rpm; это полезный контекст, если у вас смешанный парк серверов.

Вывод по выбору простой: для apt берите apt-mirror, для rpm — reposync + createrepo. Это самые описанные, самые предсказуемые варианты, вокруг которых меньше всего сюрпризов при первой настройке.

Полное зеркало или частичное: считаем диск заранее

Главная ошибка при первом запуске — попытаться зазеркалировать весь официальный репозиторий со всеми архитектурами, всеми компонентами и всей историей. Это не только избыточный расход диска, но и избыточный расход времени на первичную синхронизацию, которая при полном зеркале Ubuntu или Debian может растянуться на много часов даже на хорошем канале.

Ориентировочные объёмы (оговорка: цифры меняются от релиза к релизу и зависят от того, сколько компонентов и веток вы включаете — воспринимайте их как порядок величины, а не точное значение):

Практический совет: подавляющему большинству компаний нужна только одна архитектура (amd64, реже arm64), один-два релиза дистрибутива, которые реально используются в продакшене, и, как правило, без секции src (исходники пакетов почти никогда не нужны для обычной эксплуатации). Такое ограничение сокращает объём в разы — обычно счёт идёт на сотни гигабайт вместо терабайт, и именно это делает задачу реалистичной за вечер, а не за неделю непрерывной синхронизации.

Если места мало, а обновляться нужно конкретному набору серверов с известным составом ПО — можно держать частичное зеркало, кэширующее только реально запрашиваемые пакеты (см. раздел про кэширующий прокси ниже). Диск стоит выделять с запасом минимум в 30-50% от расчётного объёма — новые версии добавляются, старые не всегда сразу вычищаются. Если сервер уже развёрнут, а диска не хватает — почитайте про расширение диска на работающем сервере, это делается без простоя на большинстве современных VPS-платформ.

Разворачиваем зеркало apt-mirror: пошагово

Дальше — конкретные шаги для Debian/Ubuntu-сервера, на котором будет жить зеркало.

1. Установка.

apt update
apt install apt-mirror

2. Конфиг зеркала. Основной файл — /etc/apt/mirror.list. По умолчанию там уже есть шаблон, его нужно отредактировать под конкретный релиз и компоненты:

set base_path /var/spool/apt-mirror
set nthreads 20
set _tilde 0

deb http://archive.ubuntu.com/ubuntu noble main restricted universe
deb http://archive.ubuntu.com/ubuntu noble-updates main restricted universe
deb http://archive.ubuntu.com/ubuntu noble-security main restricted universe

clean http://archive.ubuntu.com/ubuntu

Обратите внимание: секция multiverse и строки deb-src намеренно не включены — если они вам не нужны, не тяните их, это прямая экономия диска и времени синхронизации. nthreads определяет число параллельных потоков скачивания — 20 разумное значение для старта, при нестабильном канале имеет смысл его снизить, чтобы не получать оборванные соединения.

3. Первый запуск синхронизации. Он же самый долгий:

apt-mirror

Первая синхронизация полного набора пакетов может занять от пары часов до существенно больше — зависит от объёма выбранных компонентов и от того, насколько стабилен канал до источника. Разумно запускать её в screen или tmux, чтобы не потерять процесс при обрыве SSH-сессии:

tmux new -s aptmirror
apt-mirror
# Ctrl+B, D — отключиться от сессии, процесс продолжит работать

4. Раздача зеркала по HTTP. Проще всего — через nginx, который отдаёт скачанный каталог как статику:

server {
    listen 80;
    server_name mirror.internal.example;
    root /var/spool/apt-mirror/mirror/archive.ubuntu.com/ubuntu;
    autoindex on;
}

После этого зеркало доступно по адресу http://mirror.internal.example/, и структура каталогов повторяет оригинальный репозиторий — клиентам не нужно ничего перестраивать в логике, только путь.

Автообновление зеркала и альтернатива для небольшой команды

Зеркало, которое синхронизировалось один раз и больше не обновляется, довольно быстро становится источником проблем — на нём не появляются патчи безопасности, а версии пакетов расходятся с тем, что доступно у апстрима. Автообновление настраивается через cron:

crontab -e

0 3 * * * /usr/bin/apt-mirror > /var/log/apt-mirror/cron.log 2>&1

Ежедневный запуск ночью — разумный компромисс между свежестью зеркала и нагрузкой на канал и диск. Повторные синхронизации значительно быстрее первой, потому что скачиваются только изменившиеся файлы, а не весь репозиторий заново.

Два нюанса, которые стоит учесть сразу:

• Место на диске не освобождается автоматически. apt-mirror по умолчанию не удаляет устаревшие пакеты — это делает отдельная команда apt-mirror-clean (или скрипт clean.sh из комплекта), её стоит добавить в тот же cron отдельной строкой, но с задержкой после основной синхронизации.
• Мониторинг успешной синхронизации. Если зеркало перестало обновляться из-за сетевой проблемы или ошибки конфига, а cron тихо не отработал — можно неделями не замечать, что зеркало не актуально. Простейшая защита — проверка в конце cron-задачи, что лог не завершился ошибкой, и алерт при сбое; подробнее о том, почему cron-задачи молча перестают отрабатывать, — в статье про частые ошибки cron-задач на сервере.

Для RPM-зеркала (reposync) логика аналогичная — та же команда в cron, но с добавлением createrepo --update после каждой синхронизации, чтобы метаданные репозитория пересчитывались под новый набор пакетов:

0 3 * * * reposync --repoid=baseos --download-path=/var/mirror/rpm --delete && createrepo --update /var/mirror/rpm/baseos

Если полное зеркало избыточно. Если серверов немного, а состав используемых пакетов заранее не известен целиком, полноценное зеркало может оказаться избыточным — вы тратите диск и время на синхронизацию пакетов, которые никто не установит. Практичнее кэширующий прокси: сервер не хранит весь репозиторий заранее, а кэширует пакеты по мере первого запроса и отдаёт из кэша при повторных.

Для apt это делается через прокси-кэш на базе nginx (модуль proxy_cache) или Squid перед оригинальным репозиторием, для RPM — похожим образом. Настройка чуть тоньше, чем прямое зеркалирование через apt-mirror, но диск растёт органически, под реально используемые пакеты. Для компании с парой десятков серверов и стабильным набором ПО такой подход часто компактнее и требует меньше ухода, хотя и не даёт полной независимости от канала — если апстрим недоступен, а пакета ещё нет в кэше, установка не пройдёт.

Переключаем сервера компании на своё зеркало

Когда зеркало синхронизировано и раздаётся по HTTP, остаётся самый механический, но важный шаг — переключить клиентские сервера так, чтобы они брали пакеты у вас, а не у внешнего источника.

На Ubuntu/Debian правится /etc/apt/sources.list (или отдельные файлы в /etc/apt/sources.list.d/):

# было
deb http://archive.ubuntu.com/ubuntu noble main restricted universe

# стало
deb http://mirror.internal.example/ubuntu noble main restricted universe

После правки — обязательно apt update, чтобы клиент перечитал индексы уже со своего зеркала, и проверка, что пакеты действительно ставятся:

apt update
apt install -y curl  # любой некритичный пакет — просто убедиться, что источник рабочий

На RPM-системах аналогично меняется baseurl в файлах /etc/yum.repos.d/*.repo:

[baseos]
name=BaseOS
baseurl=http://mirror.internal.example/rpm/baseos
enabled=1
gpgcheck=1

Если серверов много и править файлы вручную неудобно — правку конфига стоит завести в тот же механизм, которым вы раскатываете конфигурацию (Ansible, cloud-init при первом запуске, bash-скрипт по SSH в цикле). Для новых серверов проще заложить адрес своего зеркала сразу в шаблон первичной настройки — эта же логика разобрана в статье про обновление и обслуживание Debian 12 с нуля, где зеркало пакетов — один из пунктов базовой гигиены сервера.

GPG-ключи репозитория проверять отдельно не нужно: зеркало копирует пакеты и метаданные, но не подменяет подписи, клиент проверяет их той же цепочкой доверия, что и с оригинального источника.

Реальные трудозатраты: почему это действительно вечер, а не проект

Если разложить время по шагам, картина выглядит примерно так:

Активного времени администратора — час-полтора на настройку и проверку плюс время на переключение серверов. Основное «долгое» время — фоновая синхронизация: вы запускаете её в tmux, занимаетесь другими делами, и к утру зеркало готово.

Ключевое условие для такого темпа — не пытаться с первого раза зазеркалировать всё. Ограничьтесь одной архитектурой, актуальным релизом и реально нужными компонентами — расширить зеркало позже, добавив ещё одну ветку или компонент в конфиг, гораздо проще, чем сразу тянуть терабайты данных, часть которых никогда не понадобится.

Частые вопросы