Как сделать репозиторий для linux

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее, нужно создать локальное хранилище пакетов, пусть это будет каталог /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 (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:

И, наконец, прописываем свой репозиторий на клиентах:

Сеанс черной магии с разоблачением окончен, всем спасибо за внимание.

Источник

Aptly — создание собственного репозитория

Зарождение жизни

Итак, софт — коммерческая разработка, которая пишется на Qt, все собирается под две архитектуры (i386 и amd64) и под несколько дистрибутивов. На текущий момент определились так: два-три последних релиза Debian и два последних LTS от Ubuntu. Плюс ко всему имеется несколько версий (на текущий момент три), которые используются у клиентов.
Три версии получились таким образом: при покупке софта клиенту предлагается поддержка и за достаточно разумные деньги предоставление новых версий софта. Изменение минорных версий предоставляется бесплатно вне зависимости от наличия поддержки. Мажорных — или при наличии поддержки, или продается заново только уже с дисконтом.

Пока версий было мало, и количество инсталляций у клиентов было невелико, вполне можно было обходится ftp. Выглядело это так: после сборки всех исходников в deb пакеты набор файлов для каждого клиента (в зависимости от версии) тарился в архив и выкладывался для каждого клиента на ftp в его собственный раздел. Со временем на ftp накапливалась масса одинаковых tar-ов у разных клиентов, которые приходилось время от времени удалять.
Шло время, клиенты добавлялись, сети клиентов росли в размерах, и обновлять версию софта на точках стало еще той задачей, особенно если учесть, что на 99% точек интернет был (да и остался) GPRS.

Кстати, о сборе пакетов. Скипты, которые собирали deb пакеты, изначально были написаны “300 лет тому назад” по какому-то мануалу на английком языке и IMHO не совсем правильно. Причесать и умыть скрипты помогли следующие статьи (за что их авторам хочу сказать спасибо):

• Собираем deb-пакет
• Стать мэинтейнером
• Как собрать бинарный deb пакет: подробное HowTo

Начало эволюции

Само собой был поднят вопрос о распространении собранных пакетов как-то более правильным способом. “И тут Остапа понесло” (с), решил все сделать правильно, так чтобы на рутинные операции тратилось минимум времени.

В качестве софта, который поддерживал репозиторий был выбран reprepro. На тот момент возможностей, которые он предоставлял, вполне хватало.

Далее, основываясь на опыте обновления, конфигурирования большого числа компьютеров, захотелось иметь инструмент по управлению конфигурациями. В помощь был призван гугл и хабр. Знакомился с ansible, chef, puppet и другими системами, названия которых уже не вспомню. По понятности конфигов, документированности, порогу вхождения и совокупности других параметров на вооружение был взят puppet. К puppet был прикручен foreman. И счастье наступило.

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

Как пример: одним клиентом было обнаружено падение приложения при работе с документами. Их набор данных на компьютерах разработчиков летал без вопросов, все открывалось и не падая замечательно работало. Собрали стенд, поставили такой же linux, ту же версию ПО, опять все работает и не падает. Начали поступать уже максимально параноидально — собрали другую машину максимально приближенную по характеристикам к машине клиента, объем диска, памяти, процессор, разрешение монитора и о чудо! повторили падение. Начали разбираться: выяснили, что суть в разрешении монитора, вернее не в разрешении как таковом, а в соотношении сторон. У разработчиков и на первой тестовой машине соотношение сторон монитора было 16:9, а у второй тестовой 4:3. В итоге вычисли, что к падению приводит одна строка в qss. Что было, конечно, большой неожиданностью. Так вот к чему этот пример. На момент этих тестов такого репозитория не было и на каждую собранную машину пришлось по старинке через scp копировать deb пакеты, ручками же ставить зависимости, после чего устанавливать сами пакеты и только потом проверять. Вместо того, чтобы за пару минут установить через aptitude со всеми зависимостями.

Пришлось гуглить. Нагуглилась в итоге статья. Начал разбираться с описанными в ней вариантами. Успел посмотреть на:

• DAK — вообще не осилил. Начал именно с нее так как “official solution”, но к стыду своему вообще не смог понять, что делать с тем деревом проекта, который стянул мне git. Поэтому особо не напрягался и продолжил читать дальше.
• Вторым продуктом, на который обратил внимание, стал mini-dak. И как бы все понятно по конфигу и с описанием более-менее ясно. Вот только остановила невозможность сделать имена репозиториев (то, что в терминах mini-dak називается suite) такие как хочу. Например я хочу получть путь к репозитарию такой: A не могу, потому-что где-то в глубине скриптов создается имя переменной со знаками “-” что в bash-e не работает. Попытки доработать скрипты напильником успехом не увенчались, ибо мой уровень программирования на bash несколько не дотягивает до уровня человека, который их писал, а убить кучу времени на изучение всех тонкостей bash (хоть и не самое плохое времяпровождение), но все же не хотелось.
• Третим вариантом для ознакомления был выбран aptly. И похоже, что этот инструмент подходит.

Работа с aptly

Документация у aptly достаточно подробная и с примерами. Кроме того есть bash-completion.
Возможностей у aptly очень широкие, ниже приведу лишь те команды которые я использую. Интересующимся более глубоко ознакомиться рекомендую сайт продукта.

Создание репозитория:

Можно создавать сразу со всеми параметрами:

Можно параметры дописать позже, а создать просто так:

Источник