Локальное зеркало linux mint что это

Обновлено: 07.07.2024

Выбор зеркала репозиториев в системе Linux Mint 17.3

Настройка аплета списка окон в Cinnamon 8.2

Настройка оконного менеджера в MATE 1.12

Опубликована очередная версия дистрибутива Linux Mint. Это уже четвёртый релиз, вышедший в соответствии с новой концепцией, согласно которой все выпуски основываются исключительно на Ubuntu с длительным сроком поддержки.

Таким образом, Linux Mint 17.3 основан на Ubuntu 14.04 LTS. И поддерживаться система будет, соответственно, до 2019 г. Подобный подход наверняка устраивает корпоративного пользователя, а некая избыточность консерватизма компенсируется тем, что в промежуточных выпусках используются новые версии рабочих столов Cinnamon и MATE.

Это позволяет обслуживающему ИТ-инфраструктуру подразделению минимизировать число «эпох перемен», но вместе с этим позволяет конечному пользователю применять для решения своих задач новое и более функциональное ПО. Хороший компромисс, удобный обеим сторонам.

Впрочем, это пока только теоретически и в перспективе. Текущий релиз показал, что привлекательная на первый взгляд схема привела к интересному результату. Дело в том, что Ubuntu 14.04 LTS, на котором основан Linux Mint 17.3 — последняя версия, использующая upstart. В следующих выпусках в качестве системы инициализации применяется systemd.

С одной стороны, таким образом разработчики Linux Mint предоставили Ubuntu почётное право «пройти по всем граблям» перехода с upstart на systemd. Следующая версия родительского дистрибутива с длинным сроком поддержки наверняка будет уже достаточно стабильной, поэтому все проблемы Linux Mint «пройдёт экстерном».

Однако у всякой медали две стороны. Текущая версия Linux Mint основана на репозитории Trusty, сформированном ещё в начале прошлого года. Версии программ в нём соответствующие. Например, пользователи актуальной версии Ubuntu уже могут установить всплывающий терминал Guake версии 0.7 с полнофункциональным конфигуратором. А в Linux Mint пока доступна только версия 0.44, в которой такого конфигуратора нет.

Пока сложно судить о том, является ли это спецификой текущего момента, или любителям нового прикладного ПО придётся либо выбирать другой дистрибутив, либо использовать какие-то «нестандартные» способы установки программ. Тут всё зависит от политики разработчиков. Сумеют ли они на практике реализовать концепцию умеренного консерватизма? Или перегибы в любую сторону всё-таки неизбежны?

Разумеется, помимо рабочих столов были обновлены некоторые специфические для Linux Mint инструменты. В частности, «Источники приложений», входящие в набор «Параметры системы». Текущие зеркала репозиториев теперь проверяются на актуальность — в случае обнаружения неполадок пользователь получит предупреждение.

К тому же система предлагает пользователю выбрать самое «быстрое» зеркало. Для России оно предсказуемо является отечественным (хотя у некоторых пользователей самым быстрым зеркалом оказалось белорусское).

Представленный в релизе рабочий стол Cinnamon 8.2 ничего принципиально нового пользователям не принёс. Все изменения носят исключительно косметический характер. Экран аплета управления звуком теперь показывают информацию о текущем произведении, а настройки приложений и устройств перемещены в контекстное меню. В аплете управления питанием можно узнать данные о производителе аккумулятора. Аплет переключения рабочих столов показывает эскизы состояния каждого рабочего стола. В настойках аплета списка окон появилась опция показа миниатюр при наведении курсора.

В MATE 1.12 изменений тоже немного. В настройках рабочего стола включается не только Compiz, но и Compton, который теперь включен в поставку по умолчанию. Получить информацию о используемых оконном и композитном менеджерах можно командой wm-detect, а вернуться в выбору по умолчанию — командой wm-recovery.

Для системных администраторов данная тема является чуть ли не первоочередной по важности. Ведь обычно любая организация, заботясь о безопасности и надёжности работы своих серверов и вообще сетей, разрабатывает и внедряет определённые политики безопасности. Которые, в свою очередь, предусматривают ограничения на доступ в открытый интернет для большинства клиентских машин из локальной сети. Однако и без этого никак нельзя, поскольку при их обслуживании необходимо проводить обновления программного обеспечения (ПО). Распространение этих обновлений при помощи сменных носителей очень неудобно, а при наличии большого числа компьютеров в обслуживаемой локальной сети практически невозможно. В данном случае, рациональным вариантом является организация локальных репозиториев пакетов, предварительно загруженных из Интернет. О двух основных подходах при решении данной задачи на примере систем Ubuntu будет далее изложено в данной статье.

Как работают репозитории пакетов в системах Linux?

Разработчики для поддержки своих дистрибутивов и комфортной работы пользователей снабжают системы управления пакетами (СУП) специальными ссылками. Они указывают на удалённые сервера, на которых хранятся самые актуальные и протестированные разработчиками пакеты ПО для данного дистрибутива. Благодаря этим ссылкам СУП «знает» когда и откуда загрузить и установить обновления пакетов. Эти ссылки могут указывать как на удалённый ресурс, так и на локальный. Во втором случае это может быть как другой компьютер в локальной сети, так и локальный накопитель и/или даже, если постараться — оптический привод.

Сами эти ссылки хранятся в файле sources.list, который в Ubuntu расположен по адресу /etc/apt/sources.lis t. Сама ссылка (для Ubuntu) выглядит примерно так:

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

Это репозиторий, созданный разработчиком среды разработки CodeLite, специально для Ubuntu. И эта ссылка была добавлена в файл sources.list уже вручную самим пользователем-администратором компьютера. После чего становится возможной автоматическая установка актуальных и стабильных версий пакетов CodeLite, а также их обновление. А вот так может выглядеть ссылка на репозиторий, хранимый на оптическом носителе:

Использование прокси для организации локального репозитория

Данный метод подразумевает доступ к репозиториям через кеш на прокси-компьютере, который имеет прямое подключение в Интернет. Механизм работы такого локального репозитория заключается в следующем:

на какой-либо клиентской машине в обычном порядке запрашивается какой-либо пакет для установки/обновления через компьютер-сервер;
запрошенный пакет скачивается сервером, сохраняется в специально отведённом хранилище-кеше и далее становится доступным всем остальным клиентам;
в качестве распространителя пакетов клиентам выступает веб-сервер Apache, поэтому его установка обязательна.

Итак, для начала необходимо установить всё необходимое, т. е. веб-сервер и саму утилиту кеширования пакетов:

При установке apt-cacher будет показан диалог настройки, в котором можно настроить нужное поведение утилиты, например задать автозапуск и работу в режиме демона. Также эти и некоторые другие важные настройки можно сделать (например с помощью редактора nano) в конфигурационном файле /etc/default/apt-cacher . Для включения автозапуска apt-cacher нужно установить параметр AUTOSTART в значение «1»:

Далее, необходимо определить, какие клиенты должны иметь доступ к кешу репозитория, отредактировав конфигурационный файл /etc/apt-cacher/apt-cacher.conf:

Как можно видеть, просто указывается диапазон нужных IP-адресов. После сохранения сделанных настроек необходимо перезапустить веб-сервер Apache:

Теперь необходимо указать клиентам, куда им нужно обращаться для установки пакетов и обновлений. Для этого на клиентских машинах нужно создать файл /etc/apt/apt.conf.d/01proxy с помощью того же редактора nano:

И добавить в него строку со следующей инструкцией:

Здесь в качестве адреса сервера, на котором установлен и работает apt-cacher указывается 192.168.1.100. Конечно, это может быть любой другой адрес, настроенный для этого сервера.

Теперь можно проверить работу локального репозитория (а точнее удалённого, но доступного через прокси), выполнив команду обновления данных о доступных пакетах:

APT-MIRROR – полноценный локальный репозиторий

Данный способ является более «продвинутым» по сравнению с использованием apt-cache. Поскольку предполагает наличие полноценного хранилища пакетов прямо на локальном компьютере/сервере или в локальной сети. Но сначала такое хранилище необходимо создать, загрузив в него все необходимые пакеты. Как и в случае с apt-cache, в качестве распространителя пакетов выступает веб-сервер Apache. Порядок настройки локального репозитория при помощи утилиты apt-mirror следующий:

установка необходимых пакетов: apt-mirror и apache2;
создание локального хранилища и настройка источников для загрузки, загрузка пакетов в хранилище;
открытие доступа к готовому хранилищу для клиентов;
настройка клиентов для использования локального репозитория.

Итак, установка необходимых утилит и пакетов:

Далее, нужно создать локальное хранилище пакетов, пусть это будет каталог /localrepo :

Теперь в конфигурационном файле /etc/apt/mirror.list нужно отредактировать строку с инструкцией «set base_path». Указав в ней только что созданный каталог для хранилища:

Далее, в этом же файле можно добавить необходимые репозитории, с которых будут загружены пакеты. Можно скопировать все стандартный репозитории из /etc/apt/sources.list .
Сохранив настройки можно запустить загрузку пакетов командой:

Это может занять длительное время, в зависимости от скорости соединения с Интернет. Данную команду очень полезно добавить в список регулярных процедур cron, чтобы локальный репозиторий обновлялся автоматически.

После того, как локальный репозиторий будет полностью загружен, его содержимое должно быть примерно следующим:

Для последующего удобства настройки клиентов полезно создать символическую ссылку на хранилище, которое содержится в каталоге mirror:

Теперь ссылка ubuntu будет использоваться для задания репозиториев на стороне клиентов с помощью редатирования файла /etc/apt/sources.list:
Открыв этот файл (с использованием команды sudo) с помощью редактора nano, нужно теперь добавить в него следующие репозитории:

Здесь адрес 192.168.1.100 — это IP-адрес компьютера, на котором был создан и настроен локальный репозиторий.
Теперь, для работы с пакетами можно использовать обычные команды apt:

Заключение

В заключение следует напомнить, что способы организации локальных репозиториев, описанные выше подходят для систем на базе формата debian-пакетов. Для систем, основанных на RPM следует использовать другие инструменты.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

При тестировании плейбуков на чистой Ubuntu (а как же еще?) самые большие накладные расходы по времени (субъективно) и уж точно самые большие по трафику уходят на установку пакетов из системного репозитория. Особенно это заметно, когда видишь, что один и тот же тест Travis CI прогоняет в 1.5 раза быстрее.

Tl;dr: не делайте локальный репозиторий через apt-mirror для мелких задач, не стоит оно того. Вместо этого нужно поднять кеширующий сервер через apt-cacher-ng.

Настройка apt-mirror

Для синхронизации локального репозитория с основным вариант один - apt-mirror . Официальный сайт считает нас умными, поэтому все его инструкции заключаются в 3 строчках:

Все действительно почти так просто. Почти.

Выбор самого быстрого репозитория

Пакета нет в репозитории Ubuntu, поэтому качаем из репозитория Debian В результате вы получите список из 3 самых быстрых (по пингу) репозиториев:

Конфигурация

Это же в виде команд:

Добавляем в cron задание по обновлению репозитория, я буду запускать в 1 ночи:

Настраиваем nginx на отдачу репозитория, у меня конфиг такой:

Все готово, осталось запустить apt-mirror и подождать денек: у меня выкачивалось 142 Гб. Причем обновления тоже будут весить ощутимо, как я понял: через день я запустил apt-mirror еще раз, он скачал 1.5 Гб.

После этого можете сменить системные репозитории в ваших локальных убунтах и наслаждаться скоростью.

date = “Ошибка” slug = “Ошибка/why-you-should-not-use-apt-mirror-for-ansible-tests-in-docker” Хотя нет, насладиться сразу конечно не получилось. По какой-то причине (наверное причина в месте на диске), apt-mirror выкачивает только amd64 пакеты, из-за чего apt-get update ругается:

Казалось бы ничего страшного, но уверен, что в тестах ненулевой код выхода apt-get будет все останавливать, поэтому придется чинить.

Решение напрашивается: явно указывать в sources.list , что в репозитории только amd64 пакеты, то есть вместо:

С настройкой apt-mirror закончили, перейдем к использованию в тестах.

Переключение Docker контейнера на локальный apt репозиторий

[Плохой способ] Подмена через DNS
[Хороший способ] Подмена /etc/apt/sources.list

Я выбрал хороший. Делается это монтированием файла на место /etc/apt/sources.list :

Чтобы не тащить с собой артефакты, файл создается командой.

После этого проверяем, это должно отработать нормально:

Если readlink выдает ошибку readlink: illegal option -- f , тогда вы скорее всего сидите на MacOS и вам нужно сделать brew install coreutils и прописать в переменную PATH то, что он просит.

Сравнение скорости

Я потратил около 4 часов на то, чтобы настроить локальные репозитории, посмотрим, сколько я сэкономил времени. Скорость инета у меня 30 мбит.

Я сравнил отработку time molecule test на 3 ansible ролях, вот результаты:

Роль	Стандартный репозиторий	Локальный репозиторий	Travis CI:
ansible-role-common	8:04	6:18	4:32
ansible-role-mysql	3:41	3:22	3:46
ansible-role-zsh	3:29	2:54	4:08

Как видно, прирост небольшой, всего 20-30%. UPD 26.02.2017: на при написании статьи про apt-cacher-ng я перепроверил результаты и разница сократилась до 10-20%.

Тут надо заметить, что в test входит проверка идемпотентности, где никакие пакеты не ставятся. Тогда я сравнил время выполнения ‘molecule converge’ для ansible-role-mysql и получил немного лучшие результаты: 2:30 против 3:17, это уже почти в 2 раза быстрее.

Роль	Стандартный репозиторий	Локальный репозиторий
ansible-role-common	8:15	6:09
ansible-role-mysql	3:17	2:30
ansible-role-zsh	4:05	2:43

Выводы по поводу apt-mirror

Результаты меня немного расстроили. Оказалось, что поразительного прироста в скорости, на который я надеялся, не будет.

Плюсы:

один раз потратил время, чтобы при каждом тесте ждать меньше
уменьшает желание тестировать не на чистой машине
интернет-канал не занимается в рабочее время

Минусы

эффект слабый, 20-30%
сложности с пробросом файла sources.list
уход от стандартной конфигурации Gitlab CI
разные конфиги для Travis CI и Gitlab CI

На основе этого сделал для себя вывод: это подходит только для локального постоянного применения, в остальных случаях минусы перевешивают.

Что-то тут не так…

После этого я задумался: а как делают “большие”? Из серьезных решений для локальных репозиториев я знаю только Artifactory. Пошел посмотреть, как у них обстоят дела с зеркалами и нашел: они умеют быть зеркалом, но не рекоменуют их так использовать, т.к. это неэффективно. Вместо этого они предлагают пользоваться ими как кеширующим сервером. Такие дела…

UPD 26.02.2017: перешел на использование apt-cacher-ng, в моем случае он лучше по всем параметрам, подробности читайте в продолжении

Устанавливаем операционную систему 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 по воскресеньям.

Читайте также: