Julio Biason
2 years ago
2 changed files with 354 additions and 0 deletions
@ -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. |
@ -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. |
Loading…
Reference in new issue