Aptly

Система управления deb-репозиториями. Позволяет как клонировать уже существующие, так и создавать свои, однако следует учесть, что при клонировании репозиторий подписывается своим ключём, поэтому всем пользователям придётся раздать свой публичный ключ, который они подсунут в apt-key.

Создание зеркала

# aptly mirror create -architectures="amd64" stretch-mirror http://mirror.yandex.ru/debian stretch main contrib non-free
  • -architectures - список архитектур, которые будут клонироваться
  • stretch-mirror - название зеркала в apt
  • http:// - исходный адрес для зеркала
  • stretch - версия дистрибутива
  • main contrib non-free etc - секции, которые надо будет клонировать

После того, как зеркало создастся - можно проверить атрибуты того, что будет у нас и того, что предлагает источник

# aptly mirror show stretch-mirror

Если нас всё устраивает - то клонируем зеркало

# aptly mirror update stretch-mirror

Далее создаём снапшот

# aptly snapshot create stretch-20180215 from mirror stretch-mirror

А снапшоты уже можно паблишить вовне:

# aptly publish snapshot -component="main,contrib,non-free" stretch-20180215 stretch-20180215 stretch-20180215 debian
  • -component - секции, которые будут запаблишены
  • stretch-20180215 - название снапшота, из которого будет производиться паблишинг, причём количество снапшотов должно быть равно количеству секций. Можно паблишить из одного и того же снапшота
  • debian - префикс репозитория

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

# aptly publish list

Удалить, соответственно, через

# aptly publish drop <name> <prefix>

Хитрости работы с репозиториями

Поскольку обычная реализация bzip2 однопоточная - паблиш реп на несильных, но многоядерных процессорах превращается в сборку генты на кофеварке. Однако в соверменном мире практически к любой задаче есть несколько инструментов, так и здесь люди придумали pbzip2 - parallel bzip2. Он хорошо размазывается по ядрам и сокращает скорость упаковки в разы, однако у pbzip2 есть одна архитектурная особенность, которая не позволяет распаковывать файлы размером боле 900000 байт стандартным bzip2. Особенность заключается в том, что pbzip2 упаковывает данные чанками: [bz chunk1][bz chunk2][bz chunk3][…] Обычный bzip2 же не умеет работать с чанками, распаковывает первый и на этом выходит, что приводит на больших репозиториях к проблеме Hash sum mismatch.

Есть несколько решений - вернуть обычный bzip2 и ждать тысячелетия, поставить на всех машинах инфраструктуры pbzip2 и молиться, что ничего не сломается или использовать lbzip2, который так же упаковывает в несколько потоков, однако делает это одним чанком.