Выбор зеркала архива astra linux
Обновлено: 08.07.2024
Выбор зеркала репозиториев пакетов в Arch Linux возлагается на пользователя. Сам пользователь должен определиться, какое зеркало или список зеркал будет использоваться для установки и обновления пакетов программ.
В дистрибутивах Arch Linux по умолчанию не предусмотрено инструментов для автоматического измерения скорости и качества зеркал. Полный список зеркал размещён в файле /etc/pacman.d/mirrorlist, по умолчанию все записи закомментированы, то есть неактивны.
Если вы используетесь более чем одним дистрибутивом Arch Linux, то вы можете обратить внимание, что в одно и то же время на разных системах доступны разные списки пакетов для обновлений — это связано с тем, что выбраны разные зеркала, которые имеют различную скорость синхронизации.
Вы также можете столкнуться с ситуацией, когда обновление Arch Linux происходит очень долго из-за того, что долго скачиваются файлы новых пакетов. В этом случае вам поможет выбор более быстрого зеркала.
Нужно выбирать самое качественное зеркало, которое необязательно будет самым быстрым
Кроме скорости, зеркала также характеризуются:
- Completion % — процент успешных проверок зеркала, если он менее 100, то зеркало может быть ненадёжным
- μ Delay — задержка от выхода обновлений пакетов до их появления на зеркале. Любые значения менее 1 часа должны расцениваться как идеальные
- μ Duration — длительность соединения во время которого с зеркала скачивается файл lastsync. Обратите внимания, что данная величина вычисляется не от вашего компьютера, а от проверяющего сервера Arch Linux
- σ Duration — стандартное отклонение времени подключения и поиска. Высокое стандартное отклонение может указывать на нестабильное или перегруженное зеркало.
- Mirror Score — очень грубый расчёт для ранжирования зеркал. В настоящее время он рассчитывается как (задержка обновлений пакетов + средняя продолжительность соединения + стандартное отклонение) / процент завершения. Чем ниже величина, тем лучше.
Возможно, вы уже перешли к списку зеркал Arch Linux и начали выбирать зеркало на основе важных вам критериев, но обратите внимание, что вначале этой страницы размещены «Out of Sync Mirrors», то есть зеркала, которые функционируют неправильно! Зеркала, с которыми всё в порядке, находятся ниже в разделе «Successfully Syncing Mirrors». Я не знаю, зачем авторы этой страницы так сделали.
Данный список регулярно обновляется и рейтинг выстраивается заново.
Итак, прежде чем перейти к выбору самого быстрого зеркала, отберите несколько самых качественных зеркал, желательно, географически близкие к вам.
К примеру, на момент написания данной заметки самыми лучшими были следующие зеркала:
Все они размещены в таких странах как Швеция, США, Германия, Франция, Нидерланды.
Теперь, когда вы составили список самых лучших зеркал, поместите их в файл /etc/pacman.d/mirrorlist.
Для проверки их скорости можно использовать утилиту rankmirrors из пакета pacman-contrib, установим этот пакет:
Запустим утилиту rankmirrors указав путь до файла со списком зеркал:
Вы увидите список зеркал, отсортированных по скорости от вашего компьютера до зеркала.
Для того, чтобы получить пригодный для вставки в /etc/pacman.d/mirrorlist список зеркал, отсортированных по скорости, запустите rankmirrors без опций:
Обратите внимание, что в данном случае rankmirrors выведет всё содержимое файла /etc/pacman.d/mirrorlist, включая закомментированные строки, в самом конце будет список активных зеркал, отсортированных по скорости.
Если вы не хотите устанавливать сторонние инструменты, то грубо оценить скорость зеркала можно по скорости синхронизации пакетов. Для этого вы можете удвоить опцию -y что приведёт к тому, что список пакетов будет скачиваться заново, даже если он является актуальным:
Поиск зеркал из определённых стран, проверка их качества и скорости
С помощью скрипта reflector можно автоматизировать процесс поиска и анализа зеркал. Установка скрипта:
Если запустить скрипт без опций, то он выведет список всех доступных зеркал:
Для того, чтобы вывести список стран и количество зеркал в каждой из них, выполните следующую команду:
С помощью опции --fastest ЧИСЛО (короткая запись -f ЧИСЛО) можно указать максимальное количество выводимых зеркал, отсортированных по их скорости. Следующая команда выведет 10 самых быстрых зеркал из стран Франция и Германия:
Если вас интересуют зеркала с наиболее высоким значением рейтинга, то используйте опцию --score ЧИСЛО. В качестве числа укажите максимальное количество выводимых зеркал. Например, эта команда выведет три зеркала из России с самым высоким рейтингом:
Если вас интересуют сервера с лучшей скоростью синхронизации, то используйте опцию --latest ЧИСЛО (-l ЧИСЛО). Следующая команда выведет 3 зеркала из Таиланда, которые были синхронизированы самое короткое время назад:
С помощью опции --protocol (короткое написание -p) вы можете указать протокол зеркала, например:
Несколько протоколов можно указать через запятую, либо используя эту опцию несколько раз.
Вы можете вывести только те зеркала, Completion % (процент успешных проверок зеркала, если он менее 100, то зеркало может быть ненадёжным) которых не менее указанной величины. Для этого используйте опцию --completion-percent 100. Значением по умолчанию является 100.0. То есть если вы хотите, чтобы тестировались и выводились зеркала только со 100 надёжностью, то эту опцию можно не использовать — она подразумевается по умолчанию.
Опциями --ipv4 и --ipv6 можно ограничить зеркала, поддерживающие только IPv4 и IPv6 соответственно.
По умолчанию список зеркал выводится в стандартный вывод, с помощью опции --save вы можете указать путь для сохранения файла со списком зеркал.
Опция --info приведёт к тому, что вместо списка зеркал будет выведена информация о них (укажите опции с фильтрами).
Вы можете автоматизировать актуализацию списка зеркал. Для этого имеется служба reflector.service, перед её запуском и добавления в автозагрузку, изучите и отредактируйте файл /etc/xdg/reflector/reflector.conf:
Обновление списка зеркал будет выполнятся при запуске службы (то есть при каждом включении компьютера, если служба добавлена в автозагрузку (enable), или при её ручном запуске (start)).
Reflector имеет systemd таймер reflector.timer, который запускает обновление списка зеркал по расписанию. Вы можете включить reflector.timer для еженедельного обновления. Вы также можете отредактировать reflector.timer чтобы изменить расписание обновлений.
Как найти самые быстрые зеркала BlackArch
Начните с обновления списка зеркал BlackArch, текущий список зеркал содержится в файле /etc/pacman.d/blackarch-mirrorlist, а обновлённый список в файле /etc/pacman.d/blackarch-mirrorlist.pacnew.
К сожалению, для BlackArch отсутствует рейтинг зеркал. Поэтому вам придётся вручную отредактировать файл /etc/pacman.d/blackarch-mirrorlist, раскомментировав наиболее качественные, по вашему мнению, зеркала.
Затем с помощью rankmirrors запустите проверку скорости зеркал, причём вам обязательно нужно указать опцию -r с именем репозитория, иначе вы получите ошибку «unreachable»:
Чтобы получить пригодный для копирования и вставки список, не используйте опцию -t:
Заключение
Итак, важно не просто выбрать самое быстрое зеркало, важно также выбрать качественное зеркало, иначе вместо задержки от скачивания, которая может составлять несколько минут, вы можете получить задержку в несколько часов из-за того, что сервер долго не синхронизирует новые пакеты.
Как правило, местные, локальные зеркала, расположенные в той же стране, что и обновляемая система, оказываются быстрее, но это правило действует далеко не всегда. Точнее говоря, правильнее сказать так: какое-то из локальных зеркал может оказаться быстрее, чем расположенные далеко. Не нужно слепо полагаться на тот факт, что зеркало является местным — оно может быть медленным и/или иметь устаревшие пакеты из-за проблем с синхронизацией.
Выбрав качественные зеркала, вы не столкнётесь с ситуацией, когда обновления на определённых системах задерживаются на часы или даже на дни.
Устанавливаем операционную систему Astra Linux.
Для репозитория желательно предусмотреть отдельный раздел на диске. Как сделать отдельный раздел можно прочесть тут.
И устанавливаем необходимые пакеты (для управления сервером пакеты ssh и xrdp, веб сервер Apache, утилиту создания локальных копий репозиториев):
Далее создаем директорию под размещение локального репозитория (зеркала) и устанавливаем владельца директории.
Если при установке системы был предусмотрен отдельный раздел под размещения репозитория, то необходимо указать его.
Настраиваем источники синхронизации репозитория и директорию размещения,
указываем нашу директорию для размещения репозитория, меняя строку
также меняем источники на требуемые, для примера будем использовать официальные репозиторий Astra Linux Common Edition:
и для очистки локальной копии (например: устаревшие пакеты) при обновлении укажем в конце
Сохраняем нажав "Cntr+O" и ввод, и выходим из редактора "Cntr+X".
Создаем публикуемую директорию для веб-сервера
Примечание: если планируется публиковать все содержимое mirror (без разбора), то можно создать символическую ссылку на него (sudo ln -s /repo /var/www/html/repo)
Меняем настройки веб-сервера
и устанавливаем главную страницу
и добавляем сведения о директории с репозиторием
Сохраняем нажав "Cntr+O" и ввод, и выходим из редактора "Cntr+X".
Создадим директорию под файлы конфигурации и добавим ссылку в веб-сервер
В данной директории удобно разместить новый sources.list для скачивания пользователями с указанием уже своего развернутого репозитория. Разместим такой лист sources.list
И вставим (для нашего примера):
Сохраняем нажав "Cntr+O" и ввод, и выходим из редактора "Cntr+X".
Выполняем синхронизацию выбранных разделов репозиториев
После индексации утилита покажет объем пакетов для скачивания и прогресс выполнения задачи.
Дожидаемся завершения синхронизации (данный процесс может занять длительное время из-за скорости интернета).
Можно синхронизировать репозитории вручную, убедившись что источник синхронизации исправен и не содержит "некорректных" пактов, либо установить задание в планировщик cron например раз в неделю в 4:00 по воскресеньям.
В прошлом году мы организовали у себя в сети общедоступные зеркала для нескольких Linux дистрибутивов. Это не сложный процесс и для больших проектов, вроде Ubuntu, почти полностью автоматизированный. В других случаях необходимо тем или иным способом связаться с проектом, например, в списке рассылки и явно высказать своё желание.
Технически это rsync , обычно по расписанию. Кто-то для этого предоставляет готовый набор скриптов, как Fedora, а кто-то просто говорит что надо синхронизироваться вот с этого сервера и рекомендуемый набор параметров. Самый затратный ресурс это место, мы недавно добрались до 4 терабайт и это дорого в нашем случае для того что не генерирует никакой прибыли. Взамен мы получили локальную доступность используемых нами дистрибутивов, это позволило упростить первоначальную настройку серверов исключив из неё обязательный доступ к Интернет. А ещё конечно мы рады что приобщились к чем-то большому, даже если наше участие в этом не сильно заметно.
Наше зеркало публичное, с него могут получать обновления все желающие, что собственно и происходит если судить по статистике обращений. В основном это Россия, но не только. Про то как так получается и как вообще происходит выбор конкретного сервера для обновлений на примере Centos седьмой версии этот пост.
Будем говорить о пакетном менеджере yum с установленным по умолчанию плагином fastestmirror и нас будет интересовать только процесс выбора конкретного зеркала.
Список зеркал
Известно, что список репозиториев задаётся в файлах в каталоге /etc/yum.repos.d/ если не указано иное. Вот так выглядят настройки репозитория Base в файле /etc/yum.repos.d/Centos-Base.repo :
Здесь видно две опции которые задают место откуда можно получать данные. Первая baseurl непосредственно указывает зеркало, никакого выбора тут не нужно. Вторая mirrorlist указывает ссылку по которой будет возвращён список из 10 зеркал из которых и будет делаться выбор, именно эта опция активна. Также мы видим несколько переменных внутри ссылки, все они в конечном итоге отражают конкретное место в дереве каталогов репозитория:
Реализация
Проверка осуществляется по списку в следующем порядке (цитирую из кода):
Пункты 1 и 2 работают или-или, чтобы проверить не только код страны, но и код штата. По сути происходит попытка выбрать ближайшие географически серверы. Для каждого шага выполняется запрос из базы данных, например:
Потом идёт проверка живости зеркал по этому списку путём сравнения хешей, как написано выше. Если набирается 10 живых, то на этом требуемая задача выполнена, работа завершена. Если не набирается то переходим к следующему шагу чтобы добрать общий список до 10 или пока не исчерпаем все варианты. Результат сохраняется в файле и отдаётся на откуп фронтенд части представленной Python скриптом ml.py, задача которого выбрать и отдать нужный файл, предварительно выяснив страну источника запроса по IP адресу. Также учитывается и тип протокола IPv4 или IPv6, для которых формируются разные списки.
Вернёмся к запросу в котором используется ORDER BY RAND() , означает ли это что список будет случайным? Да, насколько случайна само реализация в СУБД, но это касается только порядка внутри каждого шага. То есть, если для конкретной страны набирается больше 10 зеркал нужного типа репозитория и архитектуры (для России всего 17), то в итоге каждый раз мы будем получать перетасованный список из 10 разных зеркал в одной стране. Если их меньше, то вверху списка всегда будут перетасованные репозитории из одной страны, дальше перетасованные репозитории из ближайших стран и так далее по шагам. В итоге получаем не совсем случайный список состоящий из нескольких случайных частей. Это имеет значение когда рабочих зеркал внутри одной страны не так много, например IPv6 зеркал в России всего 7 и они всегда будут вверху списка:
Ещё хуже дело обстоит с архитектурой i386 это альтернативная архитектура для Centos 7 и отдельная система зеркал. В России всего один такой сервер который поддерживает альтернативные архитектуры, он всегда будет на первом месте:
Список перестал быть случайным, если ориентироваться на первую строчку то выбор предопределён. Поддержка репозиториев для альтернативных архитектур Centos в принципе вызывает озабоченность, но тут для многих чистый альтруизм.
Сканирование репозиториев происходит постоянно и не учитывая механизмы кеширования результат обновляется примерно раз в 3 часа. Цитата из mirrorlist_crawler_deployment_notes.txt:
- A full scan of all repos and all versions without any cached data is going to take close to 3 hours, but typically altarch is <10min, C6 <25min, C7 <25min with all the repos enabled
Можно ожидать что каждые 15 минут у нас будет новый список, за 30 минут какие-то изменения в нём произойдут обязательно. Но! Помним что чем меньше активных зеркал тем менее случаен порядок и на первом месте сейчас в России всегда одно и то же зеркало.
Fastestmirror
Обработка происходит в несколько потоков поэтому ждать долго не приходится, даже для всех 17 зеркал которые числятся в России. Результат работы в виде двух списков, первый в котором указано время выполнения является отладочным и он не отсортирован, хотя может так показаться. Второй после слова Result отсортирован от меньшего отклика к большему, именно он используется для дальнейшей работы в полученном порядке.
В dnf тоже используется fastestmirror из набора библиотек RPM, но там это решено через libcurl и в целом всё сложнее устроено.
На практике получились следующие результаты первого места на недельном опросе через каждые 10 минут. Цифры — количество раз сколько узел выигрывал при сравнении, для fastestmirror и fping :
Видно что выбор не прямо однозначный, но тут скорее всего играет роль близость точки с которой я делал опрос — до нескольких зеркал, разница меньше миллисекунды. Второй момент, IPv6 список отличается и он хуже — ближайший IPv6 узел дальше чем ближайший IPv4 и выбор меньше. С учётом приоритета IPv6 получается не очень. Результаты fping лаконичнее, меньше выигрывавших узлов, но в целом одинаковы с fastestmirror .
RIPE Atlas
Пробники (синие маркеры) и зеркала (красные маркеры) распределены слишком неравномерно и тяготеют к столицам, поэтому результаты не стоит воспринимать как что-то значимое. Сырые данные доступны начиная с измерения номер 23159879 по 23159901, при желании их можно проанализировать более строго. Обобщённый итог количество первых мест для IPv4:
Лучшие результаты в районе одной или нескольких миллисекунд, а самый худший результат по отклику в Салехарде, пробник 22767:
Послесловие
При этом доля этого трафика изнутри нашей сети ничтожна.
Вот так на нём заканчивается место:
Хорошо различимые ступеньки — моменты когда мы добавляем новый дистрибутив. Когда всё начиналось это был VirtualBox работающий под Windows на офисном компьютере на котором хранились видеоархивы нашего рекламного отдела. Потом мы перебрались на боевую систему виртуализации и стало чуть полегче:
Посмотреть статус всех известных в Centos зеркал можно вот тут, а прочитать про то как присоединиться к проекту вот тут, это и просто и ответственно одновременно, но точно не бесполезно.
Теперь нужно подключить нужные репозитории и обновить систему.
Кроме того, каждый раз вставлять DVD-диск в сервер для установки какой-нибудь программы мне не хочется
Что делать? Конечно, скопировать содержимое установочного диска на локальный диск сервера и подключить его в качестве репозитория.
Шаг 1. Запускаем терминал.
Шаг 2. Производим предварительную подготовку.
Т.к. у нас суперпользователь root без пароля, зададим ему пароль.
Шаг 3. Создаём локальный репозиторий из установочного диска.
Для этого вставляем установочный диск в привод и копируем его содержимое в папку на диске. Правда, придётся предварительно установить rsync, т.к. эта программа по умолчанию не установлена в системе.
Шаг 4. Создаём локальный репозиторий из диска для разработчиков
Если у вас нет диска разработчиков на флешке, скачиваем его из интернета
Шаг 5. Создаём локальный репозиторий из диска обновлений.
Если у вас нет диска с обновлениями на флешке, скачиваем его из интернета. На момент написания статьи последнее обновление имело имя 20210730SE16
Шаг 6. Подключаем созданные репозитории.
Для этого редактируем файл /etc/apt/sources.list.
Приводим его к следующему виду
Обратите внимание, первую строчку, которая уже была в файле, я закомментировал. Действительно, зачем нам каждый раз вставлять DVD с установочным диском? 😉
Шаг 7. Обновляем систему.
Для этого сначала обновляем список подключенных репозиториев.
У apt есть ключ upgrade, который выполняет только обновление одной версии пакета на другую, более свежую. Он не будет устанавливать или удалять пакеты, даже если это необходимо для обновления других. Это наиболее безопасный и надежный вариант обновления, но он может обновить не все. Например, с ее помощью не обновить ядро до более свежей версии.
Ключ dist-upgrade или full-upgrade (это одно и то же) в дополнение к upgrade обрабатывает все изменения зависимостей для новых пакетов и во время работы может удалять ненужные и ставить необходимые пакеты для обновления.
Использование ключа dist-upgrade несколько опасно, я так несколько раз получал повреждённую систему.
Итак, обновляем систему
Придётся немного подождать.
(Моё субъективное мнение: Astra Linux обновляяется уж очень долго. Red Hat или Centos обновляются в 2-3 раза быстрее.)
После обновления рекомендую перезагрузить сервер
PS.
Так как я планирую установить ещё и модули дополнений для гостевой ОС от VirtualBox, установлю минимальный набор необходимых для этого пакетов
Ну, и собственно, ставлю сами дополнения гостевой ОС
Теперь точно всё.
Аренда серверов.
Надёжные сервера с Pro-бегом
У ВАС В ОФИСЕ!
Безопасный доступ к своей 1С из офиса, командировки и т.п.!
IP-телефония в офис.
IP-телефония давно перестала быть роскошью в офисах.
Хотите себе в офис цифровую АТС - обращайтесь. !
Читайте также: