Как сделать локальный репозиторий ubuntu

Добавил пользователь Дмитрий К.
Обновлено: 05.10.2024

Возникла необходимость в локальном репо, чтобы при обновлении пакетов не забивать канал интернета. Были протестированы несколько пакетов. О них подробнее.

Apt-cache. Создает локальную копию репозитория. Проблема с данным пакетом в том, что он на момент конца 2019 года заброшен, ведутся поиски человека, который будет его поддерживать. Ubuntu 19.04 ругается, что не все пакеты были докачены, попытки погуглить выявили, что не я один с такой проблемой и решения пока нет.

Aptly. Так же создает локальную копию репозитория. Проблема возникла в его подписи. Не смотря на свежесгенерированный сертификат в pgp2 софт не его не использует. Да же с указанием ключа вручную. Провозившись день и не найдя ответа я перешел к тестированию другого пакета. Плюсом избыточность функционала: хранение снапшотов из зеркал и их последующая публикация с возможностью откатить, создать дополнительный или объединить — это круто. Но для простого зеркала не нужно.

Apt-Cacher NG. На нем я и остановился.

  • Удобный Web интерфейс для управления;
  • По-умолчанию кэширует пакеты, а не выкачивает весь репозиторий, что экономит место;
  • Может не кэшировать, а выкачивать пакеты всего репозитория;
  • Есть импорт пакетов

По минусам — мало использовал, дополню в будущем.

Установим его как кеширующий сервер:

sudo apt install apt-cacher-ng

Настроим пароль администратора в файле /etc/apt-cacher-ng/security.conf:

Настроим конфиг файл /etc/apt-cacher-ng/acng.conf.

Теперь нужно отредактировать файл /etc/apt-cacher-ng/backends_ubuntu и добавить туда репозитории. В моем случае выглядит так.

sudo systemctl restart apt-cacher-ng

На клиентской машине выполняем, указав ip или имя сервера:

dpkg-scanpackages. Если всё-таки нужен полноценный локальный репозиторий, то самый простой способ тут. Устанавливаем web сервер и настраиваем на удобную директорию. Копируем туда deb пакеты. В моем случае будет:

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

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

В этой инструкции я расскажу как настроить локальный репозиторий Ubuntu 16.04 двумя способами.

Способ 1. Apt-mirror

В этом способе мы скачаем все пакеты из публичного репозитория на жесткий диск сервера Ubuntu. Сначала нужно установить веб-сервер Apache. Он необходим для распространения пакетов по локальной сети:

Теперь установите apt-mirror:

Создайте директорию куда будут скачиваться все пакеты:

Теперь откройте файл /etc/apt/mirror.list и добавьте следующую строчку:

Здесь /myrepo - адрес только что созданной папки. Также в этом конфигурационном файле можете указать репозитории, которые хотите использовать, мы будем использовать стандартные, но вы можете добавить и PPA. Если вы хотите использовать обе архитектуры и x64 и x32, репозитории для них нужно указать в файле отдельно.

Например, для x32 строчка будет начинаться deb-i386 а для х64: deb-amd64. Когда завершите с настройкой запустите загрузку пакетов командой:

В терминал будет выведено что-то вроде:

Сейчас все пакеты из публичного репозитория Ubuntu загружаются и сохраняются в локальной папке. В нашем случае в папке /myrepo. В зависимости от вашей скорости интернет это может занять несколько часов. Отменить загрузку можно в любое время, когда вы ее возобновите она продолжится там, где вы ее прервали.

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

В этом примере Cron будет запускать обновление пакетов в четыре утра каждый день.

После заввершения загрузки проверим есть ли пакеты в каталоге /myrepo

Теперь нужно сделать пакеты доступными по сети. Для этого создадим символическую ссылку:

Конфигурация клиентов

Настройка на клиентской машине не вызовет никаких трудностей. Просто откройте файл /etc/apt/sources.list и добавьте свой локальный репозиторий, так же как вы добавляли удаленный, только используйте ваш ip адрес вашей машины:

Вот и все, здесь 192.168.1.102 - адрес сервера с репозиторием. Теперь обновим списки пакетов:

Для установки программы достаточно выполнить стандартную команду:

Настройка apt-mirror ubuntu 16.04 завершена. Теперь клиентам не нужно подключение к интернету для загрузки пакетов. Они будут получать все пакеты и обновления с локального репозитория Ubuntu.

Способ 2: APT-Cacher

Создание локального репозитория ubuntu возможно не только одним способом. Apt-cacher немного отличается от apt-mirror. Он не скачивает все пакеты из репозитория, а только сохраняет и делает доступными для всех, те которые были один раз запрошены.

Сначала установите сервер Apache:

Выберите способ запуска - daemon и нажмите ок:


Теперь нужно отредактировать /etc/default/apt-cacher, установив параметр autostart в 1.

Также можно настроить с каких ip можно будет получить доступ к кэшу, для этого откройте файл /etc/apt-cacher/apt-cacher.conf и отредактируйте соответствующую строчку: Например, разрешим подключение только компьютерам с ip от 192.168.1.20 до 192.168.1.30:

После завершения настроек перезапустите apache:

Настройка на стороне клиента

Создайте файл sudo nano /etc/apt/apt.conf.d/01proxy и добавьте в него следующую строчку:

Здесь 192.168.1.102 адрес нашего локального репозитория. Осталось обновить списки пакетов:

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

Выводы

Вот и все. Эта технология будет очень полезной системным администраторам, а также обычным пользователям, у которых слабый интернет. Если у вас остались вопросы, спрашивайте в комментариях!

Понимание работы сетей на базовом уровне имеет очень важное значение для каждого администратора сервера или веб-мастера. Это необходимо для правильной

Когда-нибудь задумывались, почему 127.0.0.1 IP-адрес назначается на localhost? Почему не какой-то другой IP-адрес, такой как 121.9.1.1 или что-то еще? Ответ на

Вы когда-нибудь задумывались, почему 127.0.0.1 является локальным IP адресом? Почему не какой-то 121.9.1.1 или что-нибудь другое? Дело в том, что в 1981 году

В данной статье я расскажу о настройке шлюза на Debian для раздачи интернета в небольшой локальной сети. Для получения доступа к интернет, на сервере

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


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

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

Для полного зеркального кеша вашему серверу необходимо не менее 120 ГБ свободного места, зарезервированного для локальных репозиториев.

  1. Минимум 120 ГБ свободного места.
  2. Сервер Proftpd установлен и настроен в анонимном режиме.

Шаг 1. Настройте сервер

1. Первое, что вы можете сделать, это определить ближайшие и самые быстрые зеркала Ubuntu рядом с вашим местоположением, посетив страницу Ubuntu Archive Mirror и выбрав свою страну .


Если ваша страна предоставляет больше зеркал, вам следует определить адрес зеркала и выполнить некоторые тесты на основе результатов ping или traceroute .


2. Следующим шагом будет установка необходимого программного обеспечения для настройки локального зеркального репозитория. Установите пакеты apt-mirror и proftpd и настройте proftpd как автономный системный демон.



3. Пришло время настроить сервер apt-mirror . Откройте и отредактируйте файл /etc/apt/mirror.list , добавив ваши ближайшие местоположения ( Шаг 1 ) - необязательно, если зеркала по умолчанию работают достаточно быстро или вы не в спешите - и выберите свой системный путь, по которому должны быть загружены пакеты. По умолчанию apt-mirror использует местоположение /var/spool/apt-mirror для локального кеша, но в этом руководстве мы собираемся использовать изменение системного пути и точку set base_path к местоположению /opt/apt-mirror .


Также вы можете раскомментировать или добавить другой список источников перед директивой clean, включая источники Debian , в зависимости от того, какие версии Ubuntu используют ваши клиенты. Вы можете добавить источники с 12.04 , если хотите, но имейте в виду, что для добавления дополнительных источников требуется больше свободного места.

Для просмотра списков источников Debian посетите Генератор списков источников Debian.

4. Все, что вам нужно сделать сейчас, это просто создать каталог пути и запустить команду apt-mirror для синхронизации официальных репозиториев Ubuntu с нашим локальным зеркалом.


Как видите, apt-mirror продолжает индексацию и загрузку архивов, отображающих общее количество загруженных пакетов и их размер. Как мы можем догадаться, 110–120 ГБ достаточно велик, чтобы загрузить его некоторое время.

Вы можете запустить команду ls для просмотра содержимого каталога.


После завершения начальной загрузки будущие загрузки будут небольшими.

5. Пока apt-mirror загружает пакеты, вы можете настроить свой сервер Proftpd . Первое, что вам нужно сделать, это создать анонимный файл конфигурации для proftpd, выполнив следующую команду.

Затем добавьте следующее содержимое в файл anonymous.conf и перезапустите службу proftd.

6. Следующий шаг - связать путь apt-mirror с путем proftpd, запустив bind mount, введя команду.

Чтобы проверить это, запустите команду mount без параметров или опций.


7. Последний шаг - убедиться, что сервер Proftpd автоматически запускается после перезагрузки системы , а каталог mirror-cache также автоматически монтируется на ftp-сервере. дорожка. Чтобы автоматически включить proftpd, выполните следующую команду.

Чтобы автоматически монтировать кеш apt-mirror на proftpd, откройте и отредактируйте файл /etc/rc.local .

Добавьте следующую строку перед директивой exit 0 . Также используйте задержку 5 перед попыткой сесть.


Если вы извлекаете пакеты из репозиториев Debian , выполните следующие команды и убедитесь, что включены соответствующие настройки для указанного выше файла rc.local .

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

В последней строке добавьте следующую строку.


Теперь каждый день в 2 часа ночи кеш вашего системного репозитория будет синхронизироваться с официальными зеркалами Ubuntu и создавать файл журнала.

Шаг 2. Настройте клиентов


10. Для просмотра репозиториев вы можете открыть браузер и указать IP-адрес вашего сервера доменного имени, используя протокол FTP.


Та же система применяется также к клиентам и серверам Debian , единственное, что необходимо изменить, - это зеркало debian и список источников .

Также, если вы устанавливаете новую систему Ubuntu или Debian , укажите локальное зеркало вручную с протоколом ftp, когда установщик спросит, какой репозиторий использовать.

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

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

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

Tux and servers

Настройка 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 репозиторий

  1. [Плохой способ] Подмена через DNS
  2. [Хороший способ] Подмена /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, в моем случае он лучше по всем параметрам, подробности читайте в продолжении

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