Como eu crio um repositório local acessível a partir de um ambiente chroot local para construção de O / S?

Question

Estou interessado em criar meu próprio remix personalizado do Ubuntu, e tenho feito isso com o Ubuntu Mini Remix ISO .

Para fazer isso, montei a imagem do disco e chroot nela, de maneira semelhante a este guia .

Minha hierarquia de diretórios para minhas compilações é assim:

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

Cada build tem $ HOME definida como ./edit/root, então qualquer coisa acima da hierarquia (./mnt, ./extract-cd, etc.) é inacessível para o ambiente chroot.

Existe uma maneira de os pacotes baixados pelo apt do chroot serem espelhados para um diretório, por exemplo, ~ / builds / cache (ou, melhor ainda, ~ / builds / cache / [ubuntu-version]), que poderia então ser usado como um repositório para outras compilações?

Essa configuração economizaria muita largura de banda, já que somente os pacotes que ainda não foram baixados / espelhados para o repositório precisariam ser extraídos da web.

De qualquer forma, obrigado antecipadamente por qualquer sugestão / ajuda.

    

Answer 1

Acabei usando a resposta do user7134, juntamente com algumas informações de aqui.

Desde que sua resposta não cumpriu totalmente o que eu tinha em mente, estou escrevendo minha própria resposta. No entanto, eu estou dando a ele a recompensa, uma vez que me apontou para o caminho certo.

A maneira de resolver o problema é a seguinte: depois de digitar no diretório build(n) , antes de executar o chroot na compilação, execute

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

Isso armazenará em cache, de maneira efetiva, os pacotes que a compilação do chroot faz download.

Continue com a construção como normal. Não há necessidade, ainda, de fazer o nosso repo, pois não haveria nada nele.

Quando terminar a compilação, quando desmontar coisas e limpar o chroot, digite

umount /var/cache/apt/archives

Podemos então fazer o repositório para uso em futuras construções.

Para isso, crie o arquivo repobuild.sh, , que ficará assim:

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

Torne nosso script executável executando chmod u+x /home/[username]/repobuild.sh e execute o script: /home/[username]/repobuild.sh

Prepare-se para fazer o chroot na nova compilação, certificando-se de montar /home/[username]/builds/cache em edit/var/cache/apt/archives conforme mostrado acima.

Chroot em edit e, em seguida, adicione

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

para /etc/apt/sources.list

Execute o apt-get update e pronto! Agora você pode usar os pacotes em cache digitando apt-get install [packagename], como faria normalmente.

Lembre-se de que toda vez que um pacote for adicionado ao diretório cache , repobuild.sh terá que ser executado novamente se você quiser usar o pacote em cache.

    

Answer 2

Eu nunca usei o ISO do Ubuntu Mini Remix, mas há algumas maneiras que eu usei para realizar isso quando eu executo o build do vmbuilder:

1. Instale o apt-cacher-ng no seu sistema (ou um servidor no seu rede local) e usá-lo como um proxy para suas compilações. Isso cria um cache local dos pacotes usados durante a construção. Assim, após a primeira compilação, você acessará o cache de qualquer pacote que tenha sido usado anteriormente e não possui uma versão mais recente do upstream. Ele ainda requer uma conexão de rede, porque ele se comunica com os repositórios upstream para obter versões mais recentes ou pacotes que você ainda não usou. O segundo benefício é que ele armazena em cache apenas os arquivos necessários, o que é significativamente menor do que um espelho completo.

EDIT: O próprio apt-cahcer-ng não precisa ser configurado de forma alguma - basta instalá-lo usando sudo apt-get install apt-cacher-ng . Existem algumas opções avançadas de configuração que eu nunca precisei. Você pode encontrar instruções sobre como configurar seus clientes (compilações) para usar o cache aqui .

2. Você pode usar debmirror ou apt-mirror para criar um espelho completo. Mas esteja ciente de que isso geralmente ocupa algumas centenas de gigabytes de espaço em disco, dependendo de quais repositórios você escolheu para espelhar (principal, restrito, universo, multiverso) e assim por diante. Além disso, geralmente leva muito mais tempo para espelhar (centenas de gigabytes). E também você tem que ter cron job para atualizá-lo ou atualizá-lo manualmente quando precisar. A falta de atualização automática pode ser vista como um benefício (eu tenho visto casos em que pacotes ruins foram publicados e levei alguns dias para substituí-los por bons) ou uma desvantagem (você não tem os últimos patches de segurança). / li>

Answer 3

Uma estratégia que poderia funcionar seria montar (com a opção --bind) uma pasta comum no cache de pacotes do chroot. Este cache está localizado em /var/cache/apt/archives/

Usar esse método faria com que qualquer comando executado pelo apt funcionasse com o arquivo local comum.

Exemplos

Ter dois chroot compartilhando um arquivo apt comum

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

Isso tornaria o ~ / builds / cache e o arquivo apt do chroot operando no mesmo diretório.

Havind dois chroot compartilham o arquivo da instalação local

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

Semelhante ao primeiro, mas agora a instalação principal e ambos os chroots usarão o mesmo arquivo apt, ou seja, o apt em todos os três irá procurar no mesmo lugar por arquivos .deb baixados.

(Eu pensei que os pacotes não se importam diretamente com a versão do ubuntu, apenas as versões dos pacotes associados. Então você pode não precisar se preocupar com pastas separadas para cada versão, e você pode até usar o arquivo de pacotes da instalação local. )

Limpar

Por último, e mais importante, na seção sobre como limpar o chroot em preparação para a compilação final, você não quer executar o apt clean. Já que o apt agora está usando a mesma pasta em toda a configuração de chroots, o apt clean irá limpar o arquivo para todos os chroots de uma só vez. Em vez disso, dentro do chroot, execute:

umount /var/cache/apt/archives

Isto irá efetivamente "limpar" o arquivo apenas do chroot onde o comando é executado, enquanto deixa a pasta comum intocada.

Vincular informações manuais de montagem

A seguir, uma cópia direta da página man mount . Por favor, dê uma olhada nele para uma explicação completa sobre o mount -bind e, possivelmente, para ver outras formas de usar 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.