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

Я интересуюсь созданием моего собственного ремикса Ubuntu и делал так с Ubuntu Мини-Ремикс 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, которая будет зеркально отражена к a, например, ~/builds/cache (или, еще лучше, ~/builds/cache / [версия человечности]) каталог, который мог затем использоваться в качестве репозитория для других сборок?

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

Так или иначе, спасибо заранее за любые предложения/помогать.

1
задан 15 November 2014 в 03:42

3 ответа

Я закончил тем, что использовал ответ user7134, наряду с некоторой информацией отсюда.

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

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

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

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

Возобновите сборку как нормальная. Нет никакой потребности, еще, сделать наш repo, поскольку не было бы ничего в нем.

После того, как законченный со сборкой, при размонтировании вещей и очистке chroot, типа

umount /var/cache/apt/archives

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

Для этого создайте файл 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 как показано выше.

Chroot в edit и затем добавьте

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

кому: /etc/apt/sources.list

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

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

0
ответ дан 11 November 2019 в 09:29

Я никогда не использовал Ubuntu Мини-Ремикс ISO, но существует несколько способов, которыми я раньше выполнял это при выполнении vmbuilder сборок:

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

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

  1. можно использовать debmirror или способное зеркало для создания полного зеркала. Но знайте, что это обычно берет дисковое пространство на несколько сотен гигабайтов, в зависимости от которых репозиториев Вы приняли решение зеркально отразить (основной, ограниченный, вселенная, мультивселенная) и так далее. Также, это обычно берет значительно дольше для зеркального отражения (сотни гигабайтов). И также у Вас должно быть задание крона, чтобы обновить его или обновить его вручную, когда Вам нужно. Отсутствие автоматического обновления может быть просмотрено и как преимущество (я видел случаи, когда плохие пакеты были опубликованы в восходящем направлении и заняли несколько дней для замены их хорошими), или недостаток (у Вас нет последних патчей безопасности).
1
ответ дан 11 November 2019 в 09:29

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

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

Примеры

Наличие доли двух 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 и способный архив обоих chroot, работающий против того же каталога.

Havind доля двух 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

Подобный первому, но теперь основной установке и обоим chroots будет использовать тот же способный архив, т.е., склонный во всех трех посмотрит в том же месте для загруженных .deb файлов.

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

Чистка

Наконец, и значительно, в разделе о чистке chroot при подготовке к заключительной сборке, Вы не хотите работать склонный чистый. С тех пор склонный теперь использует ту же папку через всю установку chroots, этот путь, склонный чистый, будет чрезвычайно ясный архив для всего chroots сразу. Вместо этого в chroot, выполненном:

umount /var/cache/apt/archives

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

Связывают, монтирует ручную информацию

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

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.
1
ответ дан 11 November 2019 в 09:29

Другие вопросы по тегам:

Похожие вопросы: