Múltiplas Distribuições com Toolbx

Quando eu troquei meu Fedora pelo Silverblue, eu passei a usar toolbox para verificar pacotes e coisas do genêro. Mas quando eu precisei testar um projeto em múltiplas distribuiçoes, eu decidi que era hora de explorar Toolbx um pouco mais a fundo.

O que é?

Antes de mais nada, Toolbx (ou toolbox) é uma ferramente criada para facilitar o uso de imagens com Podman. Sabe quando você usa o Docker para criar uma imagem que você possa usar junto com a sua instalação atual, que você possa quebrar de várias maneiras sem estragar o sistema externo e ainda tem acesso aos seus dados? Bom, isso é o Toolbx.

Por padrão, no Silverblue, existe apenas uma imagem: fedora-toolbox. É a instalação padrão do Fedora Workstation, mas você pode usar qualquer versão do Fedora. Você pode fazer

toolbox create

... para criar um ambiente com o a instalação do Fedora na mesma versão que a versão do Silverblue e então

toolbox enter

... para entrar na imagem. A partir daí você pode instalar qualquer coisa sem que isso afete o seu sistema.

toolbox create tem uma opção para selecionar uma imagem, é foi nisso que eu tive a ideia de usar o Toolbx para ter várias distribuições no meu sistema, cada uma no seu contêiner isolado, com suas próprias ferramentas, e que eu pudesse estragar a vontade sem estragar a instalação básica.

Usando outas imagens

Para usar uma imagem diferente no Toolbx, você pode simplesmente baixar a imagem usando podman pull e o nome da imagem. Infelizmente, nem toda imagem está pronta para ser usada, porque o Toolbx tem alguns requisitos para conseguir interagir com a imagem.

Requisitos

Primeiro, é preciso que capsh esteja disponível dentro da imagem. O nome do pacote depende da distribuições, mas nas imagens que eu tentei usar, nenhuma delas tinha o mesmo instalado por padrão.

Segundo, você possivelmente vai precisar do "sudo" para que você possa instalar pacotes no container e, novamente, parece que ele não é padrão nas outras imagens.

Terceiro, como "sudo" não vai estar disponível, não vai haver um arquivo sudoers, fazendo necessário que você crie um.

Quarto, o grupo de usuários do sudo muda de distribuição para distribuição; algumas chamam o grupo de "sudo", outras chama de "wheel". Mas o grupo deve existir.

E quinto, Toolbx vai alterar o entrypoint do container, então você precisa garantir que o não há nenhum comando no entrypoint da imagem.

Uma imagem OpenSuse

Vou começar com uma imagem do OpenSuse: Suse não tem um grupo de sudo, não vem com o capsh nem com sudo. Assim, eu tive que criar minha própria imagem. Isso pode ser feito com um arquivo Containerfile or, se você preferir, pode criar o mesmo com o nome Dockerfile, que o Podman não tem o menor problema em usar.

Assim, eu tenho esse Containerfile:

FROM opensuse/leap:15.1

LABEL com.github.containers.toolbox="true" \
      com.github.debarshiray.toolbox="true"

RUN groupadd wheel
RUN zypper install -y libcap-progs sudo
COPY sudoers /etc/sudoers

ENTRYPOINT []

Os labels são apenas para informar o Toolbx que a imagem é uma imagem Toolbx. Como não há um grupo de sudo, eu tive que criar um grupo chamado "wheel"; libcap-progs é onde o capsh se encontra; um arquivo sudoers foi adicionado para permitir usar sudo sem senha.

%wheel        ALL=(ALL)       NOPASSWD: ALL

Com isso, a imagem pode ser criada com podman create . -t suse51 onde "suse51" vai ser o nome da imagem.

Com a imagem criada, o ambiente do Toolbx pode ser criado com toolbox create -i <hash> suse; o <hash> é a parte do ID da imagem e suse vai ser o nome do toolbox. Não sei porque, mas algumas vezes referenciar a imagem pelo nome (o nome que usamos na parte do build) não parece funcionar, mas o hash sempre funciona.

E, com isso, para usar o ambiente, basta usar toolbox enter suse.

Outras distribuições que eu tive que construir a imagem:

Uma Imagem Ubuntu

Parecido com o OpenSuse, a imagem padrão do Ubuntu não vem com capsh nem sudo, mas isso pode ser corrigido com este Containerfile:

FROM ubuntu:18.04

LABEL com.github.containers.toolbox="true" \
      com.github.debarshiray.toolbox="true"

RUN apt update && apt upgrade -y
RUN apt install -y libcap2-bin sudo
COPY sudoers /etc/sudoers

ENTRYPOINT []

Ainda, o grupo do sudo é "sudo", e o arquivo sudoers tem que refletir isso.

Uma Imagem Centos 7

Centos 7 vem com capsh, mas não com o sudo. Assim, precisamos de mais uma imagem customizada:

FROM centos:7.3.1611

LABEL com.github.containers.toolbox="true" \
      com.github.debarshiray.toolbox="true"

RUN yum -y update yum-skip-broken
RUN yum install -y sudo
COPY sudoers /etc/sudoers

ENTRYPOINT []

O grupo do sudo é o "wheel", e assim o sudoers tem que ser ajustado.

Conclusão

Bom, é basicamente isso. Eu tive que trabalhar um pouco com as iagens, verificar os logs tentando criar ambientes com toolbox create -i <imagem> <umnome> --log-devel DEBUG para ver o que o Toolbx estava encontrando de problemas, encontrar uma solução para isso, mas depois que a primeira imagem foi criada (a do Suse), encontrar o que estava falando foi bem fácil.

E agora eu não preciso ficar pulando de distribuição em distribuição para descobrir se o nosso projeto funciona nelas.