Toolbx

2 years ago · b908a39592
2 changed files with 354 additions and 0 deletions
--- a/content/code/multiple-distros-with-toolbox.md
+++ b/content/code/multiple-distros-with-toolbox.md
@ -0,0 +1,175 @@
 +++
 title = "Multiple Distros with Toolbx"
 date = 2022-06-24
 [taxonomies]
 tags = ["linux", "podman", "containers", "toolbox", "toolbx"]
 +++
 When I switched from Fedora to
 [Silverblue](https://silverblue.fedoraproject.org/), I got used to use
 `toolbox` to check for packages and whatnot. But when I needed to test a
 project in multiple distributions, I decided it was time to explore Toolbx a
 little deeper.
 <!-- more -->
 ## What's it?
 First of what, Toolbx (or `toolbox`) is a tool created to make it easier to
 play with [Podman](https://podman.io/) images. You know when you use Docker to
 create an image that you can work along your normal install, so you can break
 as much as you want without damaging the external system, and still have access
 to your data? Well, that's Toolbx.
 By default, on Silverblue, there is basically just one image: fedora-toolbox.
 It is the default Fedora Workstation install, but you can pick any version you
 want. You can do 
 ```
 toolbox create
 ```
 ... to create an environment with a Fedora install in the same version of the
 current Silverblue install and then 
 ```
 toolbox enter
 ```
 ... to get into the image. So now you can install whatever you want without
 burdening your system.
 `toolbox create` have an option to select an image, and that's when I got the
 idea of using it to have different distributions in my system, each in their
 own container, with their own tools, so I could break them as much as I wanted
 without breaking my base system.
 ## Getting Other Images
 To use a different image for your Toolbx, you can simply download them with
 `podman pull` and an image name. Unfortunately, not every image is ready to be
 used, 'cause there are some requirements that Toolbx needs to interact with the
 image.
 ## Requirements
 First, you'll need `capsh` to be available inside the image. The name of the
 package depends on the distribuition, but in the images I tried, none had it
 installed by default.
 Second, you'll probably need "sudo" so you can install packages on the
 container and, again, it doesn't seeem to be part of the base images.
 Third, because "sudo" is not available, there will be no `sudoers` file,
 requiring that you create one.
 Fourth, the sudo group can change from distribuition to distribution; some call
 it "sudo", others call it "wheel". But the group must exist.
 And fifth, Toolbx will mess with the entrypoint of the container, so you must
 be sure that there is no command in the entrypoint. 
 {% note() %}
 There is a line that basically removes the entrypoint no matter what the base
 image uses, and I added it in all examples, just to be in the safe side.
 {% end %}
 ## An OpenSuse Image
 Let me start with an OpenSuse image: Suse doesn't have a sudo group, doesn't
 come with `capsh` installed not `sudo`. So I had to create my own image.
 This can be done with a `Containerfile` file or, if you prefer, you can create
 it with the name `Dockerfile`, which Podman is pretty chill in using without
 issues.
 So I have this `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 []
 ```
 The labels are just to inform Toolbx that the image is a Toolbx image. Because
 there is no sudo group, I had to need to create a `wheel` group; libcap-progs
 is the source for the `capsh` app; a `sudoers` file that was added to allow
 using `sudo` without a password.
 {% note() %}
 If you're curious, the whole `sudoers` I use have just one line:
 ```
 %wheel        ALL=(ALL)       NOPASSWD: ALL
 ```
 {% end %}
 With that in place, the image can be created with `podman create . -t suse51`,
 where "suse51" will be the image name.
 Image created, the Toolbx environment can created with `toolbox create -i
 <hash> suse`; the `<hash>` part is the image ID and `suse` is the toolbox name.
 Dunno why, but sometimes referring to the image by its name (the one used in
 the `build` part) doesn't seem to work, but the hash always do.
 And then, to use the environment, simply do `toolbox enter suse`.
 Other distributions I build images:
 ## Ubuntu Image
 Similar to OpenSuse, Ubuntu default image also doesn't come with `capsh` and
 `sudo`, but this can fixed with this `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 []
 ```
 Also, the `sudo` group is "sudo", so the `sudoers` file had to reflect this.
 ## Centos 7 Image
 Centos 7 comes with `capsh`, but not `sudo`. So another custom image needs to
 be used:
 ```
 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 []
 ```
 `sudo` group is "wheel", so `sudoers` had to be adjusted.
 ## Conclusion
 That's basically it. I had to mess a bit with the images, check the logs trying
 to create the environment with `toolbox create -i <image> <somename>
 --log-level DEBUG` to see any complains, figure out how to fix those but once
 the first image (the Suse one) was created, figuring out what was needed was
 pretty easy.
 And now I don't need to do distro hopping to figure out if our project work on
 them.
--- a/content/code/multiple-distros-with-toolbox.pt.md
+++ b/content/code/multiple-distros-with-toolbox.pt.md
@ -0,0 +1,179 @@
 +++
 title = "Múltiplas Distribuições com Toolbx"
 date = 2022-06-24
 [taxonomies]
 tags = ["linux", "podman", "conteineres", "toolbox", "toolbx"]
 +++
 Quando eu troquei meu Fedora pelo
 [Silverblue](https://silverblue.fedoraproject.org/), 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.
 <!-- more -->
 ## O que é?
 Antes de mais nada, Toolbx (ou `toolbox`) é uma ferramente criada para
 facilitar o uso de imagens com  [Podman](https://podman.io/). 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.
 {% note() %}
 Existe uma linha que basicamente remove o entrypoint não importa o que a imagem
 base usa, e eu adicionei a mesma em todos os exemplos, só por garantia.
 {% end %}
 ## 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.
 {% note() %}
 Se você estiver curioso, esse é o conteúdo inteiro do `sudoers` é apenas uma
 linha:
 ```
 %wheel        ALL=(ALL)       NOPASSWD: ALL
 ```
 {% end %}
 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.