From b908a39592ac3ec8613e50a99fb1e8441b0f143b Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Fri, 24 Jun 2022 17:10:43 -0300 Subject: [PATCH] Toolbx --- content/code/multiple-distros-with-toolbox.md | 175 +++++++++++++++++ .../code/multiple-distros-with-toolbox.pt.md | 179 ++++++++++++++++++ 2 files changed, 354 insertions(+) create mode 100644 content/code/multiple-distros-with-toolbox.md create mode 100644 content/code/multiple-distros-with-toolbox.pt.md 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. + + + +## 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 + suse`; the `` 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 +--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. + + + +## 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 suse`; o `` é 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 + --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.