Создаём свой репозиторий с deb-пакетами.
Мы научились собирать пакеты и подписывать их. Теперь самое время сделать свой репозиторий с пакетами.
По сути, есть 3 способа (более или менее «легальных») способа собрать свой репозиторий: dpkg-scanpackages, mini-dinstall и reprepo. dpkg-scanpackages — достаточно простая тулза, но требует много ручной работы. Я хоть и напишу про неё, но использовать её в промышленных масштабах не стоит. С reprepo я особенно не разобрался — официальная документация старовата и далека от вменяемости. Так что в основном здесь написано про mini-dinstall.
dpkg-scanpackages — утилита, которая индексирует каталог и создаёт для него файл Packages. Эту тулзу можно использовать как временную локальную замену (чтобы, например, проверить, что пакеты будут ставиться через apt-get), но не нужно использовать её там, где важна проверка подписи пакетов — dpkg-scanpackages сам по себе этого просто не умеет (хотя и можно подписывать репозиторий лапками).
Сам dpkg-scanpackages живет в пакете dpkg-dev, так что:
Представим, что наши пакеты в прошлых статьях мы собирали в /home/user/packages:
user@server:~$ ls /home/user/packages
example-package_0.3_amd64.build example-package_0.3_amd64.changes example-package_0.3_amd64.deb
Тогда мы генерируем Packages.gz следующим образом:
user@server:~$ dpkg-scanpackages -t deb /home/user/packages/ | gzip | cat > /home/user/packages/Packages.gz
А в sources.list.d добавляем строчку «deb file:/home/user/ packages/» :
Проверяем, что репозиторий работает:
root@server:~# 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 и другой софт, который пригодится:
Дальше всё я буду расписывать исходя из того, что заливать пакеты в репозиторий будет несколько пользователей. Конечно, можно использовать dput и всё делать под одним пользователем, но если у вас полтора разработчика — то такой вариант вас уже не устроит и захочется предоставить возможность заливать пакеты с подписями разных разработчиков. Поэтому мы создадим отдельного пользователя и отдельный gpg-ключ, которым будем подписывать репозиторий. А подписи пакетов будем проверять перед тем, как добавить их в репозиторий.
Mini-dinstall незачем работать под рутом (если запустить его под рутом — нам не придется вводить целую дополнительную команду по выставлению вменяемых прав на каталог incoming, гы). Создадим отдельного пользователя:
Пойдем под этого пользователя:
Создадим папочку, куда будем складывать наш репозиторий:
Напишем конфиг /home/repokeeper/.mini-dinstall.conf для нашей собиралки репозиториев:
[DEFAULT]
archivedir = /home/repokeeper/repo/
mail_to = root@vlad.pro
verify_sigs = true
architectures = all, amd64, i386
archive_style = flat
generate_release = true
mail_on_success = true
release_codename = SomeShit
release_description = My Own Repo
release_label = someshit
release_origin = someshit
release_suite = None
extra_keyrings = ~/.gnupg/pubring.gpg
release_signscript = ~/sign-release.sh
incoming_permissions = 0
chown_changes_files = false
Генерируем ключ уже знакомой нам командой:
Что там отвечать уже написано, стоит только заметить, что нам нужен именно новый ключ, а не ключ с теми же ответами. Ну там ник и почту измените для приличия.
Создадим каталог keys, в который для начала положим публичный ключ нашего репозитория. Там же мы будем складировать публичные ключи наших разработчиков (себя для начала).
Сначала экспортируем публичный ключ репозитория. Под пользователем repokeeper делаем такое:
Где repo@vlad.pro — почта, которую мы использовали при генерации ключа для пользователя repokeeper.
Так же экспортируем ключ, которым мы подписываем пакеты и «добавим его» в валидные ключи для repokeeper (разрешив тем самым заливать пакеты, подписанные тем ключом). Под пользователем, из-под которого мы собираем пакеты, выполняем команду:
(напомню, что свою почту я использовал в прошлом примере)
Файл inkvizitor68sl.gpg нам нужно закинуть в каталог /home/repokeeper/keys на том сервере, где у вас будет работать mini-dinstall. О правах на файлы можно не сильно беспокоиться (в конце концов, это публичная подпись — обладая ей хуже вам не сделают).
Теперь под пользователем repokeeper импортируем ключ «разработчика»:
repokeeper@server:~$ gpg —no-default-keyring —ignore-time-conflict —keyring .gnupg/pubring.gpg —import ~/keys/inkvizitor68sl.gpg
Так же нам понадобится скрипт, который будет запускаться для подписывания собранного репозитория. Подходящий скрипт есть в документации к mini-dinstall, утащим его себе:
Немного подправим для своих нужд:
В файл ~/.gnupg/passphrase нужно написать пароль от GPG ключа, который мы сгенерировали для репозитория.
Так как мы запускаем mini-dinstall не от рута, нам нужны корректные права на его incoming-каталог. При помощи chmod/chown надежно добиться у нас этого не получится (разработчики обязательно будут заливать с такими правами, что у mini-dinstall не будет хватать прав на удаление залитых файлов — и он будет падать с ошибкой), посему сделаем это через acl:
А так же создадим группу, присутствие в которой будет позволять системным пользователям заливать пакеты на сервер (от рута):
И выставим права этим пользователям на каталог incoming:
root@server:~# setfacl -R —modify group:repouploaders:rwx /home/repokeeper/repo/mini-dinstall/incoming/
root@server:~# setfacl -R —modify default:group:repouploaders:rwx /home/repokeeper/repo/mini-dinstall/incoming/
И добавим пользователя, от которого собираем пакеты в группу аплоадеров. Точнее, добавим пользователя, которому мы хотим дать права на заливание файлов в репозиторий. Это может быть и аккаунт разработчика, который будет заливать пакеты по sftp/scp через dupload.
Заодно по дороге запретим заливать файлы всем остальным:
«Зальём» наш собранный ранее пакетик в репозиторий. Сейчас мы это делаем при помощи простого cp, в будущем я напишу о том, как использовать dupload.
repokeeper@server:~$ cp /home/user/packages/example-package_0.3_amd64.deb /home/repokeeper/repo/mini-dinstall/incoming/
repokeeper@server:~$ cp /home/user/packages/example-package_0.3_amd64.changes /home/repokeeper/repo/mini-dinstall/incoming/
Наконец-то запускаем сборку нашего репозитория (обратите внимание, не от рута):
Если ошибок не видно, то проверяем содержимое файла Packages:
Как видим, у нас в репозитории появился наш example-package. Попробуем поставить его.
Для начала подключим репозиторий локально:
root@server:~# echo «deb file:/home/repokeeper/repo/ unstable/» > /etc/apt/sources.list.d/my-own-repo.list; apt-get update
Проверяем, что пакет появился в индексе apt’a:
root@server:~# apt-cache policy example-package
example-package:
Installed: (none)
Candidate: 0.3
Version table:
0.3 0
500 file:/home/repokeeper/repo/ unstable/ Packages
root@server:~# apt-get install example-package
.
Install these packages without verification [y/N]?
Фиг нам, как говорится. apt считает пакеты недоверенным. Что ж мы, зря мучались с подписями) ? Скормим публичный ключ нашего репозитория нашему локальному apt-у:
Обновим индекс apt-а, как обычно:
Вуаля. Поставился молча и сделал нам пустой /root/.ssh/authorized_keys, ибо я ленивая жопа и собрал таки пакет с пустыми файлами)
Теперь мы можем закидывать файлы в repo/mini-dinstall/incoming когда нам нужно и перегенерировать репозиторий командой от рута
или просто от пользователя repokeeper
Дальше нам предстоит научиться использовать upload, запускать mini-dinstall по крону и демоном. А ещё не забыть расшарить репозиторий по http и https. А потом уже перейдем ко всяким забавным полезностям в dpkg.
dpkg-scanpackages
Thanks for this example ! — It will be moderated and published shortly.
Feel free to post other examples Oops ! There is a tiny cockup. A damn 404 cockup. Please contact the loosy team who maintains and develops this wonderful site by clicking in the mighty feedback button on the side of the page. Say what happened. Thanks!
Thanks for this example ! — It will be moderated and published shortly.
It will surely help many people ! Feel free to post other examples Oops ! There is a tiny cockup. A damn 404 cockup. Please contact the loosy team who maintains and develops this wonderful site by clicking in the mighty button on the bottom right corner of this page. Say what happened. Thanks!
examples
dpkg-scanpackages -m debs >Packagesbzip2 -zkf Packages
description
dpkg-scanpackages sorts through a tree of Debian binary packages and creates a Packages file, used by apt(8), dselect(1), etc, to tell the user what packages are available for installation. These Packages files are the same as those found on Debian archive sites and CD-ROMs. You might use dpkg-scanpackages yourself if making a directory of local packages to install on a cluster of machines.
Note: If you want to access the generated Packages file with apt you will probably need to compress the file with bzip2(1) (generating a Packages.bz2 file) or gzip(1) (generating a Packages.gz file). apt ignores uncompressed Packages files except on local access (i.e. file:// sources).
binary-dir is the name of the tree of the binary packages to process (for example, contrib/binary-i386). It is best to make this relative to the root of the Debian archive, because every Filename field in the new Packages file will start with this string.
override-file is the name of a file to read which contains information about how the package fits into the distribution (it can be a compressed file); see deb-override(5).
path-prefix is an optional string to be prepended to the Filename fields.
If more than one version of a package is found only the newest one is included in the output. If they have the same version and only differ in architecture only the first one found is used.
options
-t, —type type
Scan for *.type packages, instead of *.deb.
-e, —extra-override file
Scan file to find supplementary overrides (the file can be compressed). See deb-extra-override(5) for more information on its format.
-a, —arch arch
Use a pattern consisting of *_all.deb and *_arch.deb instead of scanning for all debs.
Include all found packages in the output.
-M, —medium id-string
Add an X-Medium field containing the value id-string. This field is required if you want to generate Packages.cd files for use by the multicd access method of dselect.
Show the usage message and exit.
Show the version and exit.
diagnostics
dpkg-scanpackages outputs the usual self-explanatory errors. It also warns about packages that are in the wrong subdirectory, are duplicated, have a Filename field in their control file, are missing from the override file, or have maintainer substitutions which do not take effect.
dpkg , dselect, deb-override, deb-extra-override, dpkg-scansources .
How can this site be more helpful to YOU ?
—> Other cool sites :
extractemailaddress.com : Your army-swiss knife for email address extraction
getthisjobfast.com : Get a new job fast : thousands of kick-ass tricks to help you in your job search site by Cédric P. (LeBerger). copyright © 2012 — 2023. All Rights Reserved.
Love it ? Hate it ? Say it !!
A problem ? An idea for a new feature ? An advice ? A command is missing ?
Your opinion does matter !