Как настроить хранилище APT?

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

Здесь подробно описано, как нужно организовать файлы и как создавать индексные файлы.

Вы также можете использовать утилиту reprepro, если вы хотите установить этот пакет. Это сделает администрирование немного более удобным.

Возможно, вы также можете рассмотреть Launchpad PPA

Для тех, кто столкнется с этой ошибкой после ответа Марио:

Unable to find expected entry 'Packages' in Release file (Wrong sources.list entry or malformed file)

сделайте следующее:

dpkg-scanpackages debs /dev/null > Packages
gzip -k Packages
apt-ftparchive release . > Release
gpg --default-key $KEYID -abs -o Release.gpg Release

Я поместил свои файлы *. Deb в папка debs .

Просто настройте простой, но подписанный репозиторий на веб-сервере. Поскольку большинство других руководств несколько устарели или громоздки, я попытаюсь воспроизвести эту процедуру здесь. Первоначальная настройка требует немного усилий, но простой скрипт сборки позволяет легко управлять. И вы можете просто добавить новые файлы *. Deb , затем обновить или позволить заданию cron справиться с этим.

Сгенерируйте несколько ключей подписи

Сначала вам нужно создать gpg ключ подписи для пакетов и вашего репозитория. Сделайте это (4) ключ подписи RSA, без пароля, и присвойте ему уникальный $ KEYNAME , когда его попросят. (В дальнейших примерах предполагается, что в качестве имени ключа используется " dpkg1 ".)

 gpg --gen-key
 gpg -a --export-secret-key dpkg1 > secret.gpg
 gpg -a --export dpkg1            > public.gpg

Я не сказал пароля, потому что ваш веб-сервер не имеет встроенной обезьяны, чтобы вводить его повторно. И подписанные пакеты и репозиторий предназначены только для удовлетворения жалоб менеджеров обновлений по этому поводу.Просто загрузите оба ключа в новый каталог репозитория / apt / на своем веб-сервере, но удалите ключ secret.gpg после инициализации .

Обновите сценарий CGI

Это простой сценарий оболочки / CGI обновления для него:

#!/bin/sh
echo Status: 200 Okay
echo Content-Type: text/plain
echo
echo Rebuilding APT repository:

{
  #-- settings
  export GNUPGHOME=/var/www/usr12345/files
  export KEYNAME=dpkg1
  #-- one-time setup
  if [ ! -e "$GNUPGHOME/secring.gpg" ] ; then
     gpg --import -v -v ./secret.gpg
     gpg --import -v -v ./public.gpg
     gpg --list-keys
  fi

  #-- symlink .deb files from adjacent sub-directories
  find .. -name '*.deb' -exec ln -s '{}' . \;

  #-- build Packages file
  apt-ftparchive packages . > Packages
  bzip2 -kf Packages

  #-- signed Release file
  apt-ftparchive release . > Release
  gpg --yes -abs -u $KEYNAME -o Release.gpg Release

} 2>&1

Три строки gpg нужно выполнить только один раз, чтобы инициализировать установку GPG в некотором каталоге $ GNUPGHOME (над корнем документа). Удалите только secret.gpg после успеха.

Уникальной особенностью этого небольшого сценария оболочки является то, что он принимает любые файлы *. Deb , которые вы вставляете, но также выполняет рекурсивный поиск (начиная с одного уровня выше) для других и привязывая к ним символические ссылки. (В конечном итоге потребуется .htaccess Options FollowSymLinks .)

Вы можете выполнить этот сценарий вручную как CGI или для каждого задания cron. Но спрячьте его, а еще лучше переместите из корня документа.

Поскольку это «тривиальный» репозиторий apt, ему нужна следующая запись apt-sources.list :

deb http://example.org/deb/  ./    # Simple signed repo

Это подходит для одиночного -архитектурные репозитории, и если вы не ожидаете появления сотен пакетов.

Подписание пакетов

Подписание ваших индивидуальных пакетов также тривиально, если вы настроили свои ключи gpg:

dpkg-sig -k dpkg1 -s builder *.deb

(Это должно быть сделано на рабочая станция, на которой создаются пакеты, а не на веб-сервере репозитория.)

Неподписанный репозиторий

Если вам не нужны подписанные пакеты, вы можете сократить сценарий обновления до:

  dpkg-scanpackages . > Packages
  bzip2 -kf Packages

Который все еще можно использовать обычными пользователями, но необходим собственный флаг для apt.sources :

deb [trusted=yes] http://apt.example.org/deb/ ./

Но, пожалуйста, не используйте обычно флаг trust = yes для всего, или если вы не действительно уверен в происхождении пакета.

Для удобства использования

Для конечных пользователей просто поместите HEADER.html в каталог репозитория. Apache mod_auto_index добавит это примечание:

<h1>http://example.org/apt/</h1>
<dl>
<dt>Add this repository to /etc/apt/sources.list as:
 <dd><kbd>deb http://example.org/apt/ ./  # example repo</kbd>
<dt>Import verification key with:
 <dd><kbd>wget -q http://http://example.org/apt/public.gpg -O- | sudo apt-key add -</kbd>
</dl>

Альтернативы

В наши дни есть несколько инструментов для автоматизации управления репозиториями. И есть даже онлайн-хостеры репозиториев и службы сборки пакетов ( gemfury , packagecloud , bintray и т. Д.)

• Довольно удобная альтернатива - prm . Это сценарий Ruby, который создает сложные репозитории APT и YUM. (Но будем надеяться, что RPM когда-нибудь наконец вымрет ..) - Лучше всего установить его согласно gem install prm .

• И я также написал небольшой скрипт, чтобы автоматизировать это аналогичным образом: http : //apt.include-once.org/apt-phparchive - Обратите внимание, что он не слишком надежен и написан на PHP (на этот раз, это случайно), и изначально предназначался для DEB и RPM-over- Пакеты APT и Phar.

Поскольку это тесно связано с исходным вопросом, существуют также инструменты для упрощения сборки пакетов Debian. Немного устарело: EPM . Намного более современно: FPM . И моя личная его вилка: XPM (более ленивый подход для упаковки приложений на языке сценариев.)