diff --git a/content/code/multiple-distros-with-toolbox.md b/content/code/multiple-distros-with-toolbox.md
new file mode 100644
index 0000000..ba1ffeb
--- /dev/null
+++ 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.
diff --git a/content/code/multiple-distros-with-toolbox.pt.md b/content/code/multiple-distros-with-toolbox.pt.md
new file mode 100644
index 0000000..b137868
--- /dev/null
+++ 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.