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

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

Источник

Настройка и управление репозиторием Debian с помощью Aptly

В инструкции мы рассмотрим основные моменты для создания и управления репозиторием для пакетов Deb с помощью инструмента Aptly.

Установка Aptly

Инструкцию по установке мы можем найти на официальном сайте. Давайте ее рассмотрим на примере Ubuntu и Rocky Linux.

Ubuntu (Debian)

Установку Aptly на Deb-системы выполнить, довольно, просто. Необходимо подключить репозиторий разработчика и выполнить установку.

Выполним импорт ключа репозитория:

wget -qO — https://www.aptly.info/pubkey.txt | apt-key add —

deb http://repo.aptly.info/ squeeze main

Обновим список пакетов и выполним установку:

apt install aptly

Для проверки введем команду:

Мы должны увидеть что-то на подобие:

aptly version: 1.4.0

Rocky Linux (RPM)

Для дистрибутивов на базе пакетов RPM предлагается для установки скачать и распаковать бинарник.

Для начала, нам понадобятся wget и tar:

yum install wget tar

Переходим на страницу последнего релиза и копируем ссылку для загрузки архива:

Используя ссылку, скачиваем на наш компьютер архив:

tar zxf aptly*tar.gz

Раскидаем полученные файлы по своим местам:

mv aptly_*_linux_amd64/aptly /usr/local/bin/

gzip -c aptly_*_linux_amd64/man/aptly.1 > /usr/share/man/man1/aptly.1.gz

Для проверки введем команду:

Мы должны увидеть что-то на подобие:

aptly version: 1.4.0

Начальная настройка

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

<
«rootDir»: «/opt/aptly»,
«downloadConcurrency»: 4,
«downloadSpeedLimit»: 0,
«architectures»: [],
«dependencyFollowSuggests»: false,
«dependencyFollowRecommends»: false,
«dependencyFollowAllVariants»: false,
«dependencyFollowSource»: false,
«dependencyVerboseResolve»: false,
«gpgDisableSign»: false,
«gpgDisableVerify»: false,
«gpgProvider»: «gpg»,
«downloadSourcePackages»: false,
«skipLegacyPool»: true,
«ppaDistributorID»: «ubuntu»,
«ppaCodename»: «»,
«FileSystemPublishEndpoints»: <
«pubtest»: <
«rootDir»: «/var/www/aptly»,
«linkMethod»: «symlink»,
«verifyMethod»: «md5»
>
>,
«enableMetricsEndpoint»: false
>

* для нас важны опции:

  • rootDir — базовая директория для приложения, где будет храниться база репозиториев.
  • FileSystemPublishEndpoints — точка публикации для репозитория. Данную опцию мы рассмотрим подробнее ниже.
    • pubtest — название для точки публикации.
    • rootDir — каталог, в котором должны находить файлы опубликованного репозитория.
    • linkMethod — способ создания копии. Возможны варианты: symlink, copy, hardlink. У каждого метода свои плюсы и минусы. Решение на усмотрение администратора репозитория.

Мы готовы начать работать с aptly.

Работа с репозиторием

Рассмотрим несколько действий:

  1. Создадим новый репозиторий.
  2. Добавим в него пакеты.

1. И так, создадим репозиторий командой:

aptly repo create -comment=»Testing first repo» -component=»main» -distribution=»focal» test

* в данном примере будет создан новый репозиторий test.
** а также:

  • comment — произвольный комментарий.
  • component — компонент по умолчанию, который будет использоваться при публикации. Обычно указываются:
    • main — DFSG-пакеты (соответствуют критериям Debian по определению свободного ПО), которым не требуются другие пакеты из других зон.
    • contrib — DFSG-пакеты с зависимостями из зоны main.
    • non-free — пакеты, которое не соответствует DFSG.
  • distribution — указать на название дистрибутива. Например, кодовое имя или класс релиза:
    • jessie/stretch/buster/sid.
    • stable/oldstable/testing/unstable.

При необходимости, можно отредактировать параметры нашего репозитория командой:

aptly repo edit -comment=»New comment» test

Источник

Про Debian

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

По сути, есть 3 способа (более или менее «легальных») способа собрать свой репозиторий: dpkg-scanpackages, mini-dinstall и reprepo. dpkg-scanpackages — достаточно простая тулза, но требует много ручной работы. Я хоть и напишу про неё, но использовать её в промышленных масштабах не стоит. С reprepo я особенно не разобрался — официальная документация старовата и далека от вменяемости. Так что в основном здесь написано про mini-dinstall.

dpkg-scanpackages — утилита, которая индексирует каталог и создаёт для него файл Packages. Эту тулзу можно использовать как временную локальную замену (чтобы, например, проверить, что пакеты будут ставиться через apt-get), но не нужно использовать её там, где важна проверка подписи пакетов — dpkg-scanpackages сам по себе этого просто не умеет (хотя и можно подписывать репозиторий лапками).

Сам dpkg-scanpackages живет в пакете dpkg-dev, так что:

# apt-get install dpkg-dev

Представим, что наши пакеты в прошлых статьях мы собирали в /home/user/packages:

$ ls /home/user/packages
example-package_0.3_amd64.build example-package_0.3_amd64.changes example-package_0.3_amd64.deb

Тогда мы генерируем Packages.gz следующим образом:

$ dpkg-scanpackages -t deb /home/user/packages/ | gzip | cat > /home/user/packages/Packages.gz

А в sources.list.d добавляем строчку «deb file:/home/user/ packages/» :

# echo «deb file:/home/user/ packages/» > /etc/apt/sources.list.d/my-own-repo.list

Проверяем, что репозиторий работает:

# apt-get update; apt-cache policy example-package
.
example-package:
Installed: (none)
Candidate: 0.3
Version table:
0.3 0
500 file:/home/ inkvizitor68sl/ Packages

Так в простейшем виде работает и mini-dinstall — генерирует Packages.gz. Но он умеет проверять подписи пакетов, работать по крону/демоном и прочие плюшки.

Повеселились, хватит. Давайте ставить mini-dinstall и другой софт, который пригодится:

# apt-get install mini-dinstall debian-keyring gnupg acl

Дальше всё я буду расписывать исходя из того, что заливать пакеты в репозиторий будет несколько пользователей. Конечно, можно использовать dput и всё делать под одним пользователем, но если у вас полтора разработчика — то такой вариант вас уже не устроит и захочется предоставить возможность заливать пакеты с подписями разных разработчиков. Поэтому мы создадим отдельного пользователя и отдельный gpg-ключ, которым будем подписывать репозиторий. А подписи пакетов будем проверять перед тем, как добавить их в репозиторий.
Mini-dinstall незачем работать под рутом (если запустить его под рутом — нам не придется вводить целую дополнительную команду по выставлению вменяемых прав на каталог incoming, гы). Создадим отдельного пользователя:

# adduser repokeeper

Пойдем под этого пользователя:

# su repokeeper

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

$ mkdir /home/repokeeper/repo/

Напишем конфиг /home/repokeeper/.mini-dinstall.conf для нашей собиралки репозиториев:

/sign-release.sh
incoming_permissions = 0
chown_changes_files = false

Генерируем ключ уже знакомой нам командой:

$ LANG=C gpg —gen-key

Что там отвечать уже написано, стоит только заметить, что нам нужен именно новый ключ, а не ключ с теми же ответами. Ну там ник и почту измените для приличия.

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

$ mkdir /home/repokeeper/keys

Сначала экспортируем публичный ключ репозитория. Под пользователем repokeeper делаем такое:

$ gpg —export —armor repo@vlad.pro >

Где repo@vlad.pro — почта, которую мы использовали при генерации ключа для пользователя repokeeper.

Так же экспортируем ключ, которым мы подписываем пакеты и «добавим его» в валидные ключи для repokeeper (разрешив тем самым заливать пакеты, подписанные тем ключом). Под пользователем, из-под которого мы собираем пакеты, выполняем команду:

$ gpg —export —armor root@vlad.pro >

(напомню, что свою почту я использовал в прошлом примере)
Файл inkvizitor68sl.gpg нам нужно закинуть в каталог /home/repokeeper/keys на том сервере, где у вас будет работать mini-dinstall. О правах на файлы можно не сильно беспокоиться (в конце концов, это публичная подпись — обладая ей хуже вам не сделают).

Теперь под пользователем repokeeper импортируем ключ «разработчика»:

$ gpg —no-default-keyring —ignore-time-conflict —keyring .gnupg/pubring.gpg —import

Так же нам понадобится скрипт, который будет запускаться для подписывания собранного репозитория. Подходящий скрипт есть в документации к mini-dinstall, утащим его себе:

$ cp /usr/share/doc/mini-dinstall/examples/sign-release.sh

Немного подправим для своих нужд:

$ sed -i ‘s/export GNUPGHOME=.*/export GNUPGHOME=

/.gnupg/passphrase нужно написать пароль от GPG ключа, который мы сгенерировали для репозитория.

Так как мы запускаем mini-dinstall не от рута, нам нужны корректные права на его incoming-каталог. При помощи chmod/chown надежно добиться у нас этого не получится (разработчики обязательно будут заливать с такими правами, что у mini-dinstall не будет хватать прав на удаление залитых файлов — и он будет падать с ошибкой), посему сделаем это через acl:

# setfacl -R —modify user:repokeeper:rwx /home/repokeeper/repo/

# setfacl -R —modify group:repokeeper:rwx /home/repokeeper/repo/

# setfacl -R —modify default:user:repokeeper:rwx /home/repokeeper/

# setfacl -R —modify default:group:repokeeper:rwx /home/repokeeper/

А так же создадим группу, присутствие в которой будет позволять системным пользователям заливать пакеты на сервер (от рута):

# addgroup repouploaders

И выставим права этим пользователям на каталог incoming:

# setfacl -R —modify group:repouploaders:rwx /home/repokeeper/repo/mini-dinstall/incoming/

# setfacl -R —modify default:group:repouploaders:rwx /home/repokeeper/repo/mini-dinstall/incoming/

И добавим пользователя, от которого собираем пакеты в группу аплоадеров. Точнее, добавим пользователя, которому мы хотим дать права на заливание файлов в репозиторий. Это может быть и аккаунт разработчика, который будет заливать пакеты по sftp/scp через dupload.

# usermod -a -G repouploaders user

Заодно по дороге запретим заливать файлы всем остальным:

# chmod 0700 /home/repokeeper/repo/mini-dinstall/incoming/

«Зальём» наш собранный ранее пакетик в репозиторий. Сейчас мы это делаем при помощи простого cp, в будущем я напишу о том, как использовать dupload.

$ cp /home/user/packages/example-package_0.3_amd64.deb /home/repokeeper/repo/mini-dinstall/incoming/

$ cp /home/user/packages/example-package_0.3_amd64.changes /home/repokeeper/repo/mini-dinstall/incoming/

Наконец-то запускаем сборку нашего репозитория (обратите внимание, не от рута):

$ mini-dinstall -b -v

Если ошибок не видно, то проверяем содержимое файла Packages:

/repo/unstable/Packages | grep Package
Package: example-package

Как видим, у нас в репозитории появился наш example-package. Попробуем поставить его.
Для начала подключим репозиторий локально:

# echo «deb file:/home/repokeeper/repo/ unstable/» > /etc/apt/sources.list.d/my-own-repo.list; apt-get update

Проверяем, что пакет появился в индексе apt’a:

# apt-cache policy example-package
example-package:
Installed: (none)
Candidate: 0.3
Version table:
0.3 0
500 file:/home/repokeeper/repo/ unstable/ Packages

Пробуем его поставить:

# apt-get install example-package
.
Install these packages without verification [y/N]?

Фиг нам, как говорится. apt считает пакеты недоверенным. Что ж мы, зря мучались с подписями) ? Скормим публичный ключ нашего репозитория нашему локальному apt-у:

# cat /home/repokeeper/keys/repo.key | apt-key add —
OK

Обновим индекс apt-а, как обычно:

# apt-get update

Пробуем поставить пакет:

# apt-get install example-package

Вуаля. Поставился молча и сделал нам пустой /root/.ssh/authorized_keys, ибо я ленивая жопа и собрал таки пакет с пустыми файлами)

Теперь мы можем закидывать файлы в repo/mini-dinstall/incoming когда нам нужно и перегенерировать репозиторий командой от рута

# su -c «mini-dinstall -b -v» repokeeper

или просто от пользователя repokeeper

$ mini-dinstall -b -v

Дальше нам предстоит научиться использовать upload, запускать mini-dinstall по крону и демоном. А ещё не забыть расшарить репозиторий по http и https. А потом уже перейдем ко всяким забавным полезностям в dpkg.

Источник

Mac OS X Hints
Adblock
detector