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

Поднимаем собственный репозиторий пакетов для 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:

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

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

Источник

• ru
• CreateLocalRepo

Создание локального репозитория

С помощью утилиты apt-mirror

Подготовка и установка apt-mirror

Это основной способ зеркалирования, помимо официального ftpsync, т.к. он гораздо надёжней debmirror.

Создаём каталог /mnt/repo/debian и дополнительные mirror,var,skel. В нём будет создаваться локальный репозиторий пакетов. Желательно чтобы это был примонтированный логический раздел жёсткого диска, чтобы в случае переустановки дистрибутива с нуля, при форматировании корневого раздела (/), не лишиться репозитория совсем.

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

Заранее предположим что нам нужны:

• Зеркало с готовыми к установке (бинарными) пакетами для amd64 jessie (stable)+ исходные тексты
• Зеркало с готовыми к установке (бинарными) обновлениями безопасности amd64 jessie (stable)+ исходные тексты
• Зеркало с готовыми к установке (бинарными) прочими обновлениями amd64 jessie (stable)+ исходные тексты
• Зеркало Backports, с готовыми к установке (бинарными) пакетами для amd64 jessie (stable)+ исходные тексты
• Зеркало необходимое для сетевой установки (udebs).

Примечание: Раскомментирование строк лишь заменяет настройки по умолчанию.

Редактируем конфигурационный файл /etc/apt/mirror.list:

Если необходимо хранить несколько зеркал для разных выпусков и архитектур, то добавляем новые строки аналогично для jessie amd64

Далее нужно убедиться что все указанные в файле mirror.list каталоги существуют.

Запуск и автоматизация apt-mirror

Для ручного запуска создания/обновления зеркала выполняем команду:

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

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

Для автоматической синхронизации и очистки зеркал нужно добавить строку в настройки cron и выставить подходящее время. Обновление официальных зеркал происходит каждые 6 часов: 3:00,9:00,15:00,21:00. Например так:

Настройка доступа к зеркалу

После завершения работы локальные копии всех указанных репозиториев окажутся в каталогах /mnt/repo/debian/mirror/имя_репозитория. Таким образом копия репозитория, которая была определена в файле mirror.list как:

окажется в каталоге /mnt/repo/debian/mirror/httpredir.debian.org/debian.

Доступ именно к этому каталогу можно открывать любым удобным для Вас способом — Web или FTP сервером. Для корректной работы обязательно необходимо добавить символические ссылки «stable»,»testing», «unstable» на те выпуски, которые вы зеркалируете (если они у вас есть).

Далее очень желательно подписать вновь созданный репозиторий.

C помощью утилиты debmirror

Создание каталога /mnt/repo/debian, в нём будет создаваться локальный репозиторий пакетов. Желательно чтобы это был примонтированный логический раздел жёсткого диска, чтобы в случае переустановки дистрибутива с нуля, при форматировании корневого раздела (/), не лишиться репозитория совсем.

Опции

тип архитектуры (i386, amd64 и т.п.)

ветка дистрибутива (stable, testing, unstable)

—nosource

не закачивать пакеты с исходным кодом

закачивать файлы переводов описаний пакетов

адрес сетевого репозитория

тип протокола передачи файлов (ftp, http, rsync)

—progress

показывать подробности загрузки

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

показывать, что сейчас происходит

—nosource

не скачивать исходные коды

-s main,contrib,non-free

секции, которые нужно скачать

—ignore-release-gpg

игнорировать проверку gpg-ключа

—ignore-missing-release

не прерывается, если нету файла Release

По умолчанию debmirror создаёт зеркало из секций main, contrib, non-free, main/debian-installer.

Можно исключать секции ненужных вам пакетов:

Имя секции обязательно в кавычках, иначе опция проигнорируется, это будет видно по общему объёму необходимых для скачивания пакетов выводимых программой в самом начале своей работы.

Принадлежность к определенной секции вашего пакета можно узнать по команде:

Пример получения бинарного зеркала (без пакетов с исходным кодом) Debian Stable для amd64:

C помощью утилиты reprepro

Создание каталога /mnt/repo/debian, в нём будет создаваться локальный репозиторий пакетов. Желательно чтобы это был примонтированный логический раздел жёсткого диска, чтобы в случае переустановки дистрибутива с нуля, при форматировании корневого раздела (/), не лишиться репозитория совсем.

Cоздание каталога /mnt/repo/debian/conf и пустого конфигурационного файла distributions:

В файл /mnt/repo/debian/conf/distributions указываем следующие параметры (пример для testing, архитектура i386):

Описание параметров

Codename: squeeze

кодовое имя дистрибутива: sarge, etch, lenny, squeeze и т.д.

Suite: stable

вертка дистрибутива: stable, testing ,unstable ,experimental

Version: 6.x

номер версии: squeeze — 6.x

Origin: Debian

возможно у вас не Debian, а его производная, например, Ubuntu, Kubuntu, если оригинал, то Debian

Label: Debian 6.x

смесь двух секций Origin и Version

Description: Debian testing repository

расшифровка, какой репозиторий

Architectures: amd64

архитектура дистрибутива: i386, amd64 и т.д.

Components: main contrib non-free

компоненты дистрибутива: main — СПО, contrib — СПО с зависимостями от несвободного, non-free — несвободное ПО

SignWith: default

можно не указывать, если не планируете подписывать репозиторий ключём gnupg

DebIndices: Packages Release . .gz .bz2

индексные файлы Packages для двоичных пакетов и файлы Release с контрольными суммами; 3 типа: несжатые, сжатые gzip, сжатые bzip

DscIndices: Sources Release . .gz .bz2

тоже самое только для пакетов с исходным кодом

Contents: . .gz .bz2

файлы со списком содержимого каждого пакета, пригодиться при поиске файлов в установленных и ещё неустановленных пакетах

Дополнительные важные опции:

AlsoAcceptFor: unstable experimental

другие ветки

UDebComponents: main contrib non-free

Udeb-пакеты

Инициализация репозитория

Создаём каталоги, файлы, ссылки:

Базовый каталог не задан, т.к. мы уже в нём находимся.

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

Параметр -b задаёт базовый каталог репозитория, в нашем случае это /mnt/repo, если вы находитесь уже в нём, то его можно не задавать, т.к. reprepro ищет файл conf/distributions в текущем каталоге.

Добавление Дебиановских исходников в репозиторий. Они состоят обычно из 2-3 файлов, главным (управляющим) из которых является dsc-файл. Чтобы все файлы исходников добавились в репозиторий, нужно использовать includedsc, остальное аналогично.

Добавление дебиановских исходников вместе с собранным из них пакетом (пакетами). После сборки пакета (пакетов) из дебиановских исходников, кроме самих пакетов и исходников появляется файл *.changes там же, где и пакеты. В этом файле перечислены как сами собранные пакеты, так и исходники. Поэтому для добавления всех этих файлов можно воспользоваться такой командой (в общем виде):

Параметр —ask-passphrase подпишет ваш репозиторий с помощью вашего ключа GnuPG. Его можно не указывать, если не планируете подписывать репозиторий ключём gnupg. На не подписанные репозитории, aptitude будет выдавать предупреждение, что он ненадежный. Для использования подписанного репозитория, надо сделать выгрузку вашего ключа, а на машине использующей репозиторий:

Добавление пакетов расположенных на CD/DVD Debian

Они уже лежат в иерархии каталога pool на дисках, но reprepro не поддерживает рекурсивный поиск по подкаталогам, но это достаточно легко обойти шаблоном (pool/*/*/*/*.deb). Пример:

Она найдёт и добавит всё пакеты.

Удаление deb-пакета из репозитория

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

Использование

Для использования репозитория нужно добавить его в файл /etc/apt/sources.list в виде следующей строки (в общем виде):

Подпись локального репозитория своим ключом

Генерирование ключа

Чтобы не было проблем с тем, что ключи созданы не там, рекомендуется все делать от учётной записи «root». Для генерирования ключа нужно выполнить команду:

Ответ на вопрос о типе ключа (обычно — 1):

Ответ на вопрос о длине ключа (тоже по умолчанию — 2048):

Ответ на вопрос о сроке истечения ключа (0 — никогда не истекает):

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

Далее ввести информацию о себе и подтвердить (буква O (не ноль)). Потом задать пароль и подтвердить его. После этого начинается генерация ключа, в течение которой просят попечатать чего-нить, подвигать мышкой или еще чего поделать. Это нужно для генерации уникального ключа.

По завершении генерации будет выведена информация о сгенерированном ключе, такая как: — ID ключа — короткий набор символов: pub 1024D/5A81CBE3 2008-04-27 — отпечаток — длинный набор символов: Key fingerprint = уникальный отпечаток — и ещё немного информации. Самой важной информацией является ID ключа и отпечаток.

Экспорт ключа

Где mylocalkey.asc это имя файла, в который внесен данный экспорт (новый файл, он создатся в процессе).

Добавление ключа в apt

Команда выполняется из того же каталога, что и предыдущая (из того, где находится mylocalkey.asc):

После этого можно проверить наличие ключа в списке apt:

Выведет все ключи, в том числе и созданный.

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

В этом случае ID_ключа будет 5A81CBE3 (см.выше).

Подписывание локального репозитория созданным ключом

Сначала нужно убедиться в том, что в локальном репозитории имеется файл Release (находится в каталоге /mnt/repo/debian/dists/ветка_дистрибутива). В этом файле хранится информация о репозитории.

Перейти в каталог, где находится файл Release и выполнить команду:

Источник

Настройка локальных репозиториев в 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.

Источник