Как создать репозиторий linux
Настройка локальных репозиториев в 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.
Поднимаем собственный репозиторий пакетов для Ubuntu (Debian)
В жизни любого развивающегося проекта рано или поздно (и лучше рано) наступает момент, когда эксплуатация многозначительно смотрит на разработку и предлагает оформить отношения. Дальнейшее развитие событий, как водится, зависит от обеих сторон. О плохом сегодня не будем, рассмотрим сразу случай, когда разработка готова использовать нехитрый инструментарий сборки пакетов, подготовленный для нее эксплуатацией (шаблоны debian/rules и debian/control, команды fakeroot, debuild, и так далее). Осталась самая малость: поднять для собранных пакетов собственный репозиторий.
Поскольку изучения интернетов внезапно показали, что тема, хоть и освещалась, и даже на Хабре, вряд ли может считаться внятно раскрытой, попробуем восполнить этот пробел.
Для начала нам потребуется ключ, которым будет подписан репозиторий. В данном примере мы создаем RSA-ключ длиной 4096 бита, который не имеет срока давности:
Поскольку предполагается подписывать репозиторий при всяком изменении, пароль от ключа лучше оставить пустым, иначе скриптом репозиторий не обновишь, но если хочется полного контроля, можно и задать. Далее ключ нужно экспортировать в файл и в дальнейшем поместить в корень репозитория для дальнейшего импорта на клиентах.
Пора подготовить дерево репозитория. У нас есть только один дистрибутив Ubuntu, только Intel x86_64 и нет пакетов с исходным кодом, поэтому о создании других элементов дерева мы не беспокоимся. Если пакеты собираются под разные дистрибутивы и имеют разные зависимости, дерево получится более развесистым, да и помянутые ниже правила сборки усложнятся.
Создадим файл конфигурации репозитория:
Пора настроить автоматическое обновление репозитория при появлении в нем новых пакетов. Файл InRelease со встроенной подписью запрашивается новыми пакетными менеджерами, а связка из двух файлов Release и Release.gpg нужна старым. Зависимости нужно продублировать для всех дистрибутивов, которые вы планируете поддерживать.
Репозиторий готов, осталось настроить попадание всех вновь создаваемых пакетов в /var/www/repo/dists/xenial/contrib/binary-amd64 (за рамками данной статьи). Однако много ли проку от репозитория, если он сугубо локальный? Надо обеспечить его доступность по HTTP:
И, наконец, прописываем свой репозиторий на клиентах:
Сеанс черной магии с разоблачением окончен, всем спасибо за внимание.
Развёртывание репозиториев Linux
1. Создаём ключ RPM-GPG-KEY. Стандартно.
/.rpmmacros следующего содержания:
3. Создаём директорию repo, а в ней директории i386, i686 и x86_64. Переносим туда ключ RPM-GPG-KEY
4. Скачиваем и раскладываем по директориям пакеты для соответствующих архитектур. Для i386 и i686 в большинстве случаев будут идентичные пакеты. Для x86_64 может не существовать пакета (например, TeamViewer), в этом случае кладётся соответствующий пакет i686 и в большинстве случаев он в RHEL работает.
6. Запускаем скрипт и отвечаем парольной фразой ключика на запрос.
7. Закачиваем на хостинг директорию repo и описываем репозиторий в /etc/yum.repos.d/nobody.repo
8. Проверяем работу репозитория
1. Создаём ключ DEB-GPG-KEY. Стандартно.
/.rpmmacros следующего содержания:
3. Создаём директорию repo, а в ней директории dists и pool. В них уже будет система каталогов. Переносим туда ключ DEB-GPG-KEY
4. В директории dists у нас будут храниться данные о пакетах, а в директории pool — сами пакеты. Причём из имени /binary-i386/t/teamviewer уже видно, что пакеты раскладываются по архитектурам, затем по буквенным директориям и затем по директориям с именами происходящими от названия содержащегося в них ПО (в них может лежать десяток пакетов необходимых конкретному ПО по его зависимостям). Т.е. имеется заданная иерархия.
5. Кладём в директорию repo скрипт для подготовки репозитория. Меняем в первой строчке скрипта key_pass=«password» на пароль Вашего ключа.
6. Запускаем скрипт и ждём когда он отработает.
Aptly — создание собственного репозитория
Зарождение жизни
Итак, софт — коммерческая разработка, которая пишется на Qt, все собирается под две архитектуры (i386 и amd64) и под несколько дистрибутивов. На текущий момент определились так: два-три последних релиза Debian и два последних LTS от Ubuntu. Плюс ко всему имеется несколько версий (на текущий момент три), которые используются у клиентов.
Три версии получились таким образом: при покупке софта клиенту предлагается поддержка и за достаточно разумные деньги предоставление новых версий софта. Изменение минорных версий предоставляется бесплатно вне зависимости от наличия поддержки. Мажорных — или при наличии поддержки, или продается заново только уже с дисконтом.
Пока версий было мало, и количество инсталляций у клиентов было невелико, вполне можно было обходится ftp. Выглядело это так: после сборки всех исходников в deb пакеты набор файлов для каждого клиента (в зависимости от версии) тарился в архив и выкладывался для каждого клиента на ftp в его собственный раздел. Со временем на ftp накапливалась масса одинаковых tar-ов у разных клиентов, которые приходилось время от времени удалять.
Шло время, клиенты добавлялись, сети клиентов росли в размерах, и обновлять версию софта на точках стало еще той задачей, особенно если учесть, что на 99% точек интернет был (да и остался) GPRS.
Начало эволюции
Само собой был поднят вопрос о распространении собранных пакетов как-то более правильным способом. “И тут Остапа понесло” (с), решил все сделать правильно, так чтобы на рутинные операции тратилось минимум времени.
В качестве софта, который поддерживал репозиторий был выбран reprepro. На тот момент возможностей, которые он предоставлял, вполне хватало.
Далее, основываясь на опыте обновления, конфигурирования большого числа компьютеров, захотелось иметь инструмент по управлению конфигурациями. В помощь был призван гугл и хабр. Знакомился с ansible, chef, puppet и другими системами, названия которых уже не вспомню. По понятности конфигов, документированности, порогу вхождения и совокупности других параметров на вооружение был взят puppet. К puppet был прикручен foreman. И счастье наступило.
Прошло не очень много времени и захотелось в качестве управления репозиторием что-нибудь более другое. Reprepro всем устраивал, кроме возможности хранить в одном репозитории разные версии одного и того же пакета: чтобы была возможность быстро откатится на определенную версию в случае какой-то регрессии или, чтобы быстро поставить нужную версию и протестировать поведение системы определенной версии на определенном наборе данных на определенных аппаратных конфигурациях.
Как пример: одним клиентом было обнаружено падение приложения при работе с документами. Их набор данных на компьютерах разработчиков летал без вопросов, все открывалось и не падая замечательно работало. Собрали стенд, поставили такой же linux, ту же версию ПО, опять все работает и не падает. Начали поступать уже максимально параноидально — собрали другую машину максимально приближенную по характеристикам к машине клиента, объем диска, памяти, процессор, разрешение монитора и о чудо! повторили падение. Начали разбираться: выяснили, что суть в разрешении монитора, вернее не в разрешении как таковом, а в соотношении сторон. У разработчиков и на первой тестовой машине соотношение сторон монитора было 16:9, а у второй тестовой 4:3. В итоге вычисли, что к падению приводит одна строка в qss. Что было, конечно, большой неожиданностью. Так вот к чему этот пример. На момент этих тестов такого репозитория не было и на каждую собранную машину пришлось по старинке через scp копировать deb пакеты, ручками же ставить зависимости, после чего устанавливать сами пакеты и только потом проверять. Вместо того, чтобы за пару минут установить через aptitude со всеми зависимостями.
Работа с aptly
Документация у aptly достаточно подробная и с примерами. Кроме того есть bash-completion.
Возможностей у aptly очень широкие, ниже приведу лишь те команды которые я использую. Интересующимся более глубоко ознакомиться рекомендую сайт продукта.
Создание репозитория:
Можно создавать сразу со всеми параметрами:
Можно параметры дописать позже, а создать просто так:
Блог начинающего линуксоида.
советы, руководства, инструкции.
Страницы
воскресенье, 10 января 2016 г.
Как создать локальный репозиторий в Debian/Ubuntu
sudo apt install apt-mirror apache2
Создаём каталог для репозитория:
sudo mkdir /media/repo/debian
и служебные каталоги:
Настраиваем. Открываем конфигурационный файл:
sudo nano /etc/apt/mirror.list
############# config ##################
# Базовый каталог, в нём будет создано локальное зеркало репозитория Debian
set base_path /media/repo/debian
# Не запускать скрипт постобработки
set run_postmirror 0
# Служебные параметры, не
set nthreads 20
set _tilde 0
#
############# end config ##############
# Зеркало с пакетами для amd64 jessie (stable)+ исходные тексты
deb-amd64 http://mirror.yandex.ru/debian jessie main contrib non-free
deb-src http://mirror.yandex.ru/debian jessie main contrib non-free
# Зеркало с обновлениями безопасности amd64 jessie (stable)+ исходные тексты
deb-amd64 http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free
# Зеркало необходимое для сетевой установки (udebs)
deb-amd64 http://mirror.yandex.ru/debian jessie main/debian-installer
# Удаляем файлы не индексированные в Release
clean http://mirror.yandex.ru/debian
clean http://security.debian.org
# Запрещаем очистку выбранной папки
skip-clean http://mirror.yandex.ru/debian/dists/jessie/main/installer-amd64/
# Зеркало с пакетами для i386 jessie (stable)+ исходные тексты
deb-i386 http://mirror.yandex.ru/debian jessie main contrib non-free
deb-src http://mirror.yandex.ru/debian jessie main contrib non-free
# Зеркало с обновлениями безопасности i386 jessie (stable)+ исходные тексты
deb-i386 http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free
# Зеркало необходимое для сетевой установки (udebs)
deb-i386 http://mirror.yandex.ru/debian jessie main/debian-installer
# Удаляем файлы не индексированные в Release
clean http://mirror.yandex.ru/debian
clean http://security.debian.org
# Запрещаем очистку выбранной папки
skip-clean http://mirror.yandex.ru/debian/dists/jessie/main/installer-i386/
Сохраняем. Запускаем закачку репозитория:
После того как загрузятся индексные файлы, Apt-Mirror сообщит вам какой объём пакетов нужно скачать (объём будет весьма и весьма не маленький). Вам остаётся только ждать. Всё остальное система сделает сама. Для автоматической синхронизации и очистки зеркал нужно добавить строку в настройки cron и выставить подходящее время. Обновление официальных зеркал происходит каждые 6 часов: 3:00,9:00,15:00,21:00. Например так:
05 01 * * * apt-mirror >> /var/log/apt-mirror.log
05 03 * * * /media/repo/debian/var/clean.sh >> /var/log/apt-mirror.log
Для корректной работы обязательно необходимо добавить символические ссылки «stable»,«testing», «unstable» на jessie, stretch, sid соответственно (если они у вас есть). Пример для jessie:
Мы установили веб-сервер Apache неспроста. Он нам нужен чтобы раздавать пакеты из нашего локального репозитория по сети (локальной). Для начала, нужно настроить доступ к репозиторию. Для этого нужно создать одну символьную ссылку:
Теперь на клиентской машине (которой нужен доступ к локальному репозиторию), укажите адрес репозитория. Если у компьютера с репозиторием есть сетевое имя (к примеру server), то указывайте его. В противном случае, адресом указывайте его IP-адрес:
sudo nano /etc/apt/sources.list
deb http://server/debian jessie main contrib non-free
deb-src http://server/debian jessie main contrib non-free
deb http://server/debian jessie/updates main contrib non-free
Если вы указывали в конфиге загрузку 32-х битных пакетов (i386), то не забудьте добавить эту архитектуру в систему:
и обновите список пакетов:
sudo apt-get update
Дальше уже всё как обычно. Для Ubuntu всё то же самое, за исключением названий репозиториев и добавления 32-х битной архитектуры в 64-х битную систему (не нужно). Конфиг mirror.list для Ubuntu 14.04:
############# config ##################
# Базовый каталог, в нём будет создано локальное зеркало репозитория Debian
set base_path /media/repo/ubuntu
# Не запускать скрипт постобработки
set run_postmirror 0
# Служебные параметры, не
set nthreads 20
set _tilde 0
#
############# end config ##############
deb-amd64 http://archive.ubuntu.com/ubuntu trusty main restricted
deb-amd64 http://archive.ubuntu.com/ubuntu trusty-updates main restricted
deb-amd64 http://archive.ubuntu.com/ubuntu trusty universe
deb-amd64 http://archive.ubuntu.com/ubuntu trusty-updates universe
deb-amd64 http://archive.ubuntu.com/ubuntu trusty multiverse
deb-amd64 http://archive.ubuntu.com/ubuntu trusty-updates multiverse
deb-amd64 http://archive.ubuntu.com/ubuntu trusty-security main restricted
deb-amd64 http://archive.ubuntu.com/ubuntu trusty-security universe
deb-amd64 http://archive.ubuntu.com/ubuntu trusty-security multiverse
deb-i386 http://archive.ubuntu.com/ubuntu trusty main restricted
deb-i386 http://archive.ubuntu.com/ubuntu trusty-updates main restricted
deb-i386 http://archive.ubuntu.com/ubuntu trusty universe
deb-i386 http://archive.ubuntu.com/ubuntu trusty-updates universe
deb-i386 http://archive.ubuntu.com/ubuntu trusty multiverse
deb-i386 http://archive.ubuntu.com/ubuntu trusty-updates multiverse
deb-i386 http://archive.ubuntu.com/ubuntu trusty-security main restricted
deb-i386 http://archive.ubuntu.com/ubuntu trusty-security universe
deb-i386 http://archive.ubuntu.com/ubuntu trusty-security multiverse
Ну и соответственно, нужно изменить символьную ссылку: