blog/content/code/multiple-distros-with-toolbox.md

+++ title = "Multiple Distros with Toolbx" date = 2022-06-24

[taxonomies] tags = ["linux", "podman", "containers", "toolbox", "toolbx"] +++

When I switched from Fedora to Silverblue, 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 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.