Как сделать зеркало ubuntu

Apt-mirror, локальный репозиторий Ubuntu — это очень просто

Не удержался, чтоб не описать свой опыт создания локального репозитория после прочтения этой статьи.
Сразу замечу, что у меня была задача обновлять кучу Ubuntu серверов, достаточно быстро и прочно обосновавшихся в организации под нужды разработчиков, не пуская их при этом в Интернет. Для Windows есть WSUS, а что же для Ubuntu?

Итак, небольшая заметка, как при помощи apt-mirror сделать локальное зеркало репозиториев Ubuntu.

Прежде всего, понадобится компьютер (или виртуальная машина) с Ubuntu (я использовал 10.04) с выходом в интернет и достаточным количеством свободного места на локальном диске. В моем случае зеркалировались репозитории только для версии 10.04 x64. Общий объем занятого пространства:

deb http:// /ubuntu/ lucid main restricted universe multiverse
deb http:// /ubuntu/ lucid-updates main restricted universe multiverse

deb-src http:// /ubuntu/ lucid main restricted universe multiverse
deb-src http:// /ubuntu/ lucid-updates main restricted universe multiverse
clean http:// /ubuntu/

Если не указать специально, apt-mirror будет качать только пакеты той архитектуры, на которой работает ваш сервер. В моем случае сервер 64-битный.
Если хочется добавить также пакеты под х86_32, то в конфиге надо продублировать пути до выбранного вами оффициального зеркала с командой deb-i386. Вот так:
deb-i386 http:// /ubuntu lucid main restricted universe multiverse

Сохраним конфиг и запустим команду:
sudo apt-mirror

Какое-то время займет на скачивание всех нужных пакетов под все указанные вами архитектуры и версии Ubuntu.
Осталась лишь одна вешь. Сообщить нашим безинтернетным серверам и десктопам Ubuntu, откуда же можно быстро обновиться. Для этого необходимо исправить в файле /etc/apt/sources.list пути до зеркала. В моем случае это выглядит так:

deb http:///ubuntu lucid main restricted
deb-src http:///ubuntu lucid main restricted

deb http:///ubuntu lucid-updates main restricted
deb-src http:///ubuntu lucid-updates main restricted

deb http:///ubuntu lucid universe
deb-src http:///ubuntu lucid universe
deb http:///ubuntu lucid-updates universe
deb-src http:///ubuntu lucid-updates universe

deb http:///ubuntu lucid multiverse
deb-src http:///ubuntu lucid multiverse
deb http:///ubuntu lucid-updates multiverse
deb-src http:///ubuntu lucid-updates multiverse

Наше локальное зеркало репозиториев готово!

Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.

Источник

Создание зеркала репозитория Ubuntu с помощью apt-mirror

Зачастую при развёртывании сети машин на Ubuntu возникает проблема с организацией доступа в интернет с целью установки новых программ из стандартных репозиториев. Например, когда доступен лишь очень узкий канал в интернет или траффик не является безлимитным. К счастью, принцип организации пакетной системы Ubuntu позволяет очень гибко управлять тем, что и откуда качать с использованием штатных средств управления пакетами. В частности, вы можете создать локальную копию нужных вам интернет-репозиториев Ubuntu и подключить её как основной источник приложений в вашу локальную сеть. Таким образом все компьютеры в вашей сети не будут требовать соединения с интернетом для установки новых программ и обновлений. И при этом, что самое важное, сохранится весь функционал пакетных менеджеров.

В этой статье я расскажу как создать локальную копию репозитория с помощью утилиты apt-mirror. Это простая и удобная утилита для создания локальных копий репозиториев Ubuntu, использующая такой же синтаксис, как и в файле /etc/apt/sources.list, в котором указываются все репозитории для Ubuntu.

Всё, что вам потребуется — это компьютер с установленной Ubuntu и безлимитным доступом к интернету.

Локальная копия официального репозитория Ubuntu 10.10 только для одной архитектуры i386 занимает 36.2 GiB, учтите это.

Итак, на компьютере, подключённом к интернету и с установленной Ubuntu, ставим пакет apt-mirror через любое средство установки пакетов, например, командой

Далее необходимо определиться, в какой каталог складывать копию репозитория. Будем считать для примера, что копия репозитория будет складываться в папку /media/data/ubuntu-repo/, которая находится на отдельном винчестере, примонтированном в каталог /media/data. Конечно нужно убедиться, что в указанной папке достаточно места для размещения полной копии нужных вам репозиториев.

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

Всё, что осталось сделать, это отредактировать конфигурационный файл apt-mirror, добавив туда нужные опции и нужные репозитории, и запустить сам процесс зеркалирования. Этот файл называется /etc/apt/mirror.list. Ниже представлено комментированное его содержимое для случая создания копии официальных репозиториев Ubuntu 10.10 для архитектуры i386 в папке /media/data/ubuntu-repo/:

Теперь осталось запустить apt-mirror и дождаться окончания его выполнения. Перед запуском необходимо убедиться, что основной каталог /media/data/ubuntu-repo/, а так же все вспомогательные каталоги mirror, var и skel внутри него, существуют и доступны для записи пользователю apt-mirror. Создать все эти каталоги можно командами

Присвоить нужные права проще всего выставив владельцем этих каталогов пользователя apt-mirror:

После этого можно запустить apt-mirror командой

После загрузки индексов apt-mirror сообщит вам, какой объём пакетов будет загружен:

Вам останется только дождаться завершения скачивания.

Автоматическое обновление локальной копии репозитория

Можно настроить автоматическое обновление локальной копии репозиториев с помощью заданий cron. Для этого просто раскомментируйте нужную строчку с заданием в файле /etc/cron.d/apt-mirror:

Можете изменить время выполнения задания (по умолчанию — в 04:00 каждый день).

Дополнительные возможности apt-mirror

При использовании схемы, описанной выше, apt-mirror скопирует из указанных репозиториев только пакеты. Однако кроме этого в репозиториях Ubuntu содержится ещё достаточно много полезных данных, например, сетевые установщики. Всё это при использовании инструкции «clean» для этих репозиториев будет удалено, поскольку не содержится в актуальных индексах. Чтобы принудительно не очищать некоторые директории можно указать в файле mirror.list инструкцию «skip-clean» с нужным адресом. Например:

Можно указывать архитектуру непосредственно в APT строке репозитория, например вот так:

Кроме того, можно подключаться к HTTP и FTP хостам, требующим авторизацию. Для этого необходимо в адресе указать имя, пароль и по необходимости — порт:

Дальнейшая работа с локальной копией репозитория

После завершения работы локальные копии всех репозиториев, указанных в mirror.list, окажутся в папках mirror/имя_репозитория в указанной основной рабочей папке apt-mirror. Таким образом копия репозитория, который был задан в mirror.list как

окажется в нашем случае в папке /media/data/ubuntu-repo/mirror/archive.ubuntu.com/ubuntu. И именно эту папку нужно будет подключать как репозиторий к другим системам с помощью HTTP или FTP сервера, или же непосредственно через физическое подключение файлового носителя.

Для подключения с помощью HTTP сервера можно установить Apache:

Затем сделать симлинк /var/www/ubuntu, указывающий на вашу папку с репозиторием:

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

В вашем случае, возможно, кроме main и restricted, будут и другие компоненты.

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

Путь, конечно, в вашем случае может отличаться.

Напоследок хочется заметить, что во многих случаях совершенно не обязательно делать копию всего репозитория, а достаточно использовать что-то вроде apt-cache или apt-move.

Источник

Настройка локальных репозиториев в Linux

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

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

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

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

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

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

Как видно, ключевым словом, определяющим протокол доступа является значение, следующее после «deb». Для оптического носителя это «cdrom», а для доступа по сети — «https».
Получается, что источники репозиториев можно дополнять по собственному усмотрению, предварительно организовав соответствующим образом хранилище пакетов.

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

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

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

Далее, необходимо определить, какие клиенты должны иметь доступ к кешу репозитория, отредактировав конфигурационный файл /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 следующий:

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

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

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

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

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

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

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

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

Заключение

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

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

Источник

Как я создал и отказался от локального репозитория apt-mirror для Ubuntu для ускорения тестирования ansible ролей

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

Ниже описано, как создать зеркало из http://mirror.yandex.ru/ubuntu и подружить его с Gitlab CI и molecule.

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

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

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

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

Пока гуглил тему, случайно наткнулся на инструкцию, как выбрать самый быстрый репозиторий. Скорее всего, для нас для всех это будет http://mirror.yandex.ru/ubuntu, но можно в этом убедиться:

Пакета нет в репозитории 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 будет все останавливать, поэтому придется чинить.

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

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

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

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

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

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

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

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

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

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

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

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

Плюсы:

Минусы

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

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

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

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

Источник