Как мне создать локальный репозиторий, доступный из локальной среды chroot для сборки O/S?

Я заинтересован в создании своего собственного ремикса Ubuntu, и делаю это с Ubuntu Mini Remix ISO.

Для этого я монтирую образ диска и помещаю в него chroot способом, аналогичным описанному в этом руководстве.

Моя иерархия каталогов для моих сборок такова:

home
  |
  \builds
     |
     +build(n)
     |  |
     |  +mnt
     |  +extract-cd
     |  +edit
     |  \&
     |
     +build(n+1)
     |  |
     |  \&
     |
     \sources (various debfiles/ISOs)

В каждой сборке $HOME установлено значение./edit/root, поэтому все, что выше по иерархии (./mnt, ./extract-cd и т. Д.), Недоступно для среды chroot.

Есть ли способ, чтобы пакеты, загруженные командой chroot, могли быть отражены, например, в каталог ~/builds/cache (или, что еще лучше, ~/builds/cache/[ubuntu-version]), который затем можно было бы используется в качестве хранилища для других сборок?

Такая настройка сэкономила бы мне большую пропускную способность, поскольку из Интернета нужно было бы извлекать только те пакеты, которые еще не были загружены / отражены в хранилище.

В любом случае, заранее спасибо за любые предложения / помощь.

3 ответа

Решение

В итоге я воспользовался ответом user7134 и некоторой информацией отсюда.

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

Способ решения проблемы заключается в следующем: после build(n) директории, перед тем как вложить в сборку, запустите

`sudo mount --bind /home/[username]/builds/cache edit/var/cache/apt/archives`

Это будет эффективно кэшировать пакеты, которые загружает chrooted сборка.

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

Закончив сборку, при размонтировании вещей и очистке chroot наберите

umount /var/cache/apt/archives

Затем мы можем сделать репо для использования в будущих сборках.

Для этого создайте файл repobuild.sh, который будет выглядеть так:

#! /bin/bash
cd /home/[username]/builds/cache
dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz

Сделайте наш скрипт исполняемым, запустив chmod u+x /home/[username]/repobuild.shи запустите скрипт: /home/[username]/repobuild.sh

Приготовьтесь выполнить chroot в новой сборке, убедившись, что /home/[username]/builds/cache в edit/var/cache/apt/archives как показано выше.

Врезаться в edit а затем добавить

deb file:/var/cache/apt/archives ./

в /etc/apt/sources.list

Запустите apt-get update, и все готово. Теперь вы можете использовать кэшированные пакеты, набрав apt-get install [packagename], как обычно.

Имейте в виду, что каждый раз, когда пакет добавляется в cache каталог, repobuild.sh придется перезапустить, если вы хотите использовать кэшированный пакет.

Одна из стратегий, которая может сработать, - это смонтировать (с опцией --bind) общую папку в кеш пакета chroot. Этот кеш находится по адресу /var/cache/apt/archives/

Использование этого метода сделает так, что любая команда, запускаемая apt, будет работать с общим локальным архивом.

Примеры

Имея два chroot, делимся общим подходящим архивом

sudo mount --bind ~/builds/cache <chroot location>/var/cache/apt/archives
sudo mount --bind ~/builds/cache <another chroot location>/var/cache/apt/archives

Это сделало бы ~/builds/cache и apt-архив chroot работающими в одном и том же каталоге.

Имею два chroot-ресурса в локальном архиве установки

sudo mount --bind /var/cache/apt/archives <chroot location>/var/cache/apt/archives
sudo mount --bind /var/cache/apt/archives <another chroot location>/var/cache/apt/archives

Аналогично первому, но теперь основная установка и оба chroot будут использовать один и тот же архив apt, т. Е. Apt во всех трех будет искать в одном месте загруженные файлы.deb.

(Я думал, что пакеты напрямую не заботятся о выпуске ubuntu, только о версиях связанных пакетов. Поэтому вам может не понадобиться беспокоиться об отдельных папках для каждого выпуска, и вы даже можете использовать локальный архив пакетов установки.)

Убираться

И наконец, что важно, в разделе об очистке chroot для подготовки к финальной сборке вы не хотите запускать apt clean. Поскольку apt теперь использует одну и ту же папку во всех настройках chroot, apt clean по существу очистит архив для всех chroot одновременно. Вместо этого в chroot выполните:

umount /var/cache/apt/archives

Это эффективно "очистит" архив только от chroot, где выполняется команда, оставив общую папку без изменений.

Информация о ручных креплениях

Ниже приведена прямая копия man mount стр. Пожалуйста, посмотрите на него для полного объяснения mount --bind и, возможно, чтобы увидеть другие способы использования bind.

The bind mounts.
          Since  Linux  2.4.0  it  is possible to remount part of the file
          hierarchy somewhere else.  The call is:

                 mount --bind olddir newdir

          or by using this fstab entry:

                 /olddir /newdir none bind

          After this call the same contents are accessible in two  places.
          One  can  also  remount  a single file (on a single file).  It's
          also possible to use the bind mount to create a mountpoint  from
          a regular directory, for example:

                 mount --bind foo foo

          The bind mount call attaches only (part of) a single filesystem,
          not possible submounts.  The  entire  file  hierarchy  including
          submounts is attached a second place by using:

                 mount --rbind olddir newdir

          Note  that  the filesystem mount options will remain the same as
          those on the original mount point,  and  cannot  be  changed  by
          passing  the  -o  option  along  with --bind/--rbind.  The mount
          options can be changed by a separate remount command, for  exam‐
          ple:

                 mount --bind olddir newdir
                 mount -o remount,ro newdir

          Note  that  the behavior of the remount operation depends on the
          /etc/mtab file.  The first command stores the 'bind' flag in the
          /etc/mtab  file  and  the second command reads the flag from the
          file.  If you have a system without the /etc/mtab file or if you
          explicitly  define  source  and  target  for the remount command
          (then mount(8) does not read /etc/mtab), then you  have  to  use
          the  bind  flag  (or  option)  for the remount command too.  For
          example:

                 mount --bind olddir newdir
                 mount -o remount,ro,bind olddir newdir

          Note that remount,ro,bind will  create  a  read-only  mountpoint
          (VFS  entry),  but the original filesystem superblock will still
          be writable, meaning that the olddir will be writable,  but  the
          newdir will be read-only.

Я никогда не использовал Ubuntu Mini Remix ISO, но я использовал несколько способов для достижения этой цели при запуске сборок vmbuilder:

  1. Установите apt-cacher-ng в вашей системе (или на сервере в вашей локальной сети) и используйте его в качестве прокси для ваших сборок. Это создает локальный кеш пакетов, которые используются во время сборки. Таким образом, после первой сборки вы попадете в кеш любого пакета, который использовался ранее и не имеет более новой версии в апстриме. Для этого по-прежнему требуется сетевое соединение, поскольку он связывается с вышестоящими репозиториями для получения более новых версий или пакетов, которые вы еще не использовали. Второе преимущество заключается в том, что он кэширует только необходимые файлы, что значительно меньше, чем у полноразмерного зеркала.

РЕДАКТИРОВАТЬ: apt-cahcer-ng сам по себе не требует никакой настройки - просто установите его, используя sudo apt-get install apt-cacher-ng, Есть несколько расширенных опций конфигурации, которые мне никогда не нужны. Инструкции по настройке клиентов (сборок) для использования кэша вы можете найти здесь.

  1. Вы можете использовать debmirror или apt-mirror, чтобы создать полное зеркало. Но имейте в виду, что это обычно занимает несколько сотен гигабайт дискового пространства, в зависимости от того, какие репозитории вы выбрали для зеркалирования (основной, ограниченный, юниверс, мультиверс) и так далее. Кроме того, для зеркалирования обычно требуется значительно больше времени (сотни гигабайт). А также вам нужно иметь задание cron для его обновления или обновления вручную, когда вам это нужно. Отсутствие автоматического обновления можно рассматривать как как преимущество (я видел случаи, когда плохие пакеты публиковались в апстриме и потребовалось несколько дней, чтобы заменить их хорошими), либо недостатком (у вас нет последних исправлений безопасности).
Другие вопросы по тегам