как создать свой репозиторий linux
Поднимаем собственный репозиторий пакетов для 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.
Начало эволюции
Само собой был поднят вопрос о распространении собранных пакетов как-то более правильным способом. “И тут Остапа понесло” (с), решил все сделать правильно, так чтобы на рутинные операции тратилось минимум времени.
В качестве софта, который поддерживал репозиторий был выбран reprepro. На тот момент возможностей, которые он предоставлял, вполне хватало.
Далее, основываясь на опыте обновления, конфигурирования большого числа компьютеров, захотелось иметь инструмент по управлению конфигурациями. В помощь был призван гугл и хабр. Знакомился с ansible, chef, puppet и другими системами, названия которых уже не вспомню. По понятности конфигов, документированности, порогу вхождения и совокупности других параметров на вооружение был взят puppet. К puppet был прикручен foreman. И счастье наступило.
Прошло не очень много времени и захотелось в качестве управления репозиторием что-нибудь более другое. Reprepro всем устраивал, кроме возможности хранить в одном репозитории разные версии одного и того же пакета: чтобы была возможность быстро откатится на определенную версию в случае какой-то регрессии или, чтобы быстро поставить нужную версию и протестировать поведение системы определенной версии на определенном наборе данных на определенных аппаратных конфигурациях.
Как пример: одним клиентом было обнаружено падение приложения при работе с документами. Их набор данных на компьютерах разработчиков летал без вопросов, все открывалось и не падая замечательно работало. Собрали стенд, поставили такой же linux, ту же версию ПО, опять все работает и не падает. Начали поступать уже максимально параноидально — собрали другую машину максимально приближенную по характеристикам к машине клиента, объем диска, памяти, процессор, разрешение монитора и о чудо! повторили падение. Начали разбираться: выяснили, что суть в разрешении монитора, вернее не в разрешении как таковом, а в соотношении сторон. У разработчиков и на первой тестовой машине соотношение сторон монитора было 16:9, а у второй тестовой 4:3. В итоге вычисли, что к падению приводит одна строка в qss. Что было, конечно, большой неожиданностью. Так вот к чему этот пример. На момент этих тестов такого репозитория не было и на каждую собранную машину пришлось по старинке через scp копировать deb пакеты, ручками же ставить зависимости, после чего устанавливать сами пакеты и только потом проверять. Вместо того, чтобы за пару минут установить через aptitude со всеми зависимостями.
Работа с aptly
Документация у aptly достаточно подробная и с примерами. Кроме того есть bash-completion.
Возможностей у aptly очень широкие, ниже приведу лишь те команды которые я использую. Интересующимся более глубоко ознакомиться рекомендую сайт продукта.
Создание репозитория:
Можно создавать сразу со всеми параметрами:
Можно параметры дописать позже, а создать просто так:
Операционные системы Astra Linux
Оперативные обновления и методические указания
Операционные системы Astra Linux предназначены для применения в составе информационных (автоматизированных) систем в целях обработки и защиты 1) информации любой категории доступа 2) : общедоступной информации, а также информации, доступ к которой ограничен федеральными законами (информации ограниченного доступа).
1) от несанкционированного доступа;
2) в соответствии с Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 5, пункт 2).
Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. С 17 декабря 2019 года правообладателем, разработчиком и производителем операционной системы специального назначения «Astra Linux Special Edition» является ООО «РусБИТех-Астра».
На web-сайтах https://astralinux.ru/ и https://wiki.astralinux.ru представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения.
Мы будем признательны Вам за вопросы и предложения, которые позволят совершенствовать наши изделия в Ваших интересах и адаптировать их под решаемые Вами задачи!
Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков.
Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить в статье Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов.
В целях обеспечения соответствия сертифицированных операционных систем Astra Linux Special Edition требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.
Очередные обновления (версии) предназначены для:
Оперативные обновления предназначены для оперативного устранения уязвимостей в экземплярах, находящихся в эксплуатации, и представляют собой бюллетень безопасности, который доступен в виде:
Ввиду совершенствования нормативно-правовых документов в области защиты информации и в целях обеспечения соответствия информационных актуальным требованиям безопасности информации, а также обеспечения их долговременной эксплуатации, в том числе работоспособности на современных средствах вычислительной техники, рекомендуется на регулярной основе планировать проведение мероприятий по применению очередных и оперативных обновлений операционной системы.
Развёртывание репозиториев 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 следующим образом:
А в 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
Генерируем ключ уже знакомой нам командой:
Что там отвечать уже написано, стоит только заметить, что нам нужен именно новый ключ, а не ключ с теми же ответами. Ну там ник и почту измените для приличия.
Создадим каталог keys, в который для начала положим публичный ключ нашего репозитория. Там же мы будем складировать публичные ключи наших разработчиков (себя для начала).
$ mkdir /home/repokeeper/keys
Сначала экспортируем публичный ключ репозитория. Под пользователем repokeeper делаем такое:
Где repo@vlad.pro — почта, которую мы использовали при генерации ключа для пользователя repokeeper.
Так же экспортируем ключ, которым мы подписываем пакеты и «добавим его» в валидные ключи для repokeeper (разрешив тем самым заливать пакеты, подписанные тем ключом). Под пользователем, из-под которого мы собираем пакеты, выполняем команду:
(напомню, что свою почту я использовал в прошлом примере)
Файл inkvizitor68sl.gpg нам нужно закинуть в каталог /home/repokeeper/keys на том сервере, где у вас будет работать mini-dinstall. О правах на файлы можно не сильно беспокоиться (в конце концов, это публичная подпись — обладая ей хуже вам не сделают).
Теперь под пользователем repokeeper импортируем ключ «разработчика»:
Так же нам понадобится скрипт, который будет запускаться для подписывания собранного репозитория. Подходящий скрипт есть в документации к mini-dinstall, утащим его себе:
$ cp /usr/share/doc/mini-dinstall/examples/sign-release.sh
Немного подправим для своих нужд:
/.gnupg/passphrase нужно написать пароль от GPG ключа, который мы сгенерировали для репозитория.
Так как мы запускаем mini-dinstall не от рута, нам нужны корректные права на его incoming-каталог. При помощи chmod/chown надежно добиться у нас этого не получится (разработчики обязательно будут заливать с такими правами, что у mini-dinstall не будет хватать прав на удаление залитых файлов — и он будет падать с ошибкой), посему сделаем это через acl:
А так же создадим группу, присутствие в которой будет позволять системным пользователям заливать пакеты на сервер (от рута):
# addgroup repouploaders
И выставим права этим пользователям на каталог incoming:
И добавим пользователя, от которого собираем пакеты в группу аплоадеров. Точнее, добавим пользователя, которому мы хотим дать права на заливание файлов в репозиторий. Это может быть и аккаунт разработчика, который будет заливать пакеты по sftp/scp через dupload.
Заодно по дороге запретим заливать файлы всем остальным:
# 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/
Наконец-то запускаем сборку нашего репозитория (обратите внимание, не от рута):
Если ошибок не видно, то проверяем содержимое файла 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-get update
Пробуем поставить пакет:
# apt-get install example-package
Вуаля. Поставился молча и сделал нам пустой /root/.ssh/authorized_keys, ибо я ленивая жопа и собрал таки пакет с пустыми файлами)
Теперь мы можем закидывать файлы в repo/mini-dinstall/incoming когда нам нужно и перегенерировать репозиторий командой от рута
или просто от пользователя repokeeper
Дальше нам предстоит научиться использовать upload, запускать mini-dinstall по крону и демоном. А ещё не забыть расшарить репозиторий по http и https. А потом уже перейдем ко всяким забавным полезностям в dpkg.