Настройка локальных репозиториев в 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 следующий:
- установка необходимых пакетов: apt-mirror и apache2;
- создание локального хранилища и настройка источников для загрузки, загрузка пакетов в хранилище;
- открытие доступа к готовому хранилищу для клиентов;
- настройка клиентов для использования локального репозитория.
Итак, установка необходимых утилит и пакетов:
Далее, нужно создать локальное хранилище пакетов, пусть это будет каталог /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.
Источник
Развёртывание репозиториев 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. Запускаем скрипт и ждём когда он отработает.
Источник
Про 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.
Источник
