How often do you come across a cool application that isn’t available for your distribution? You’d probably next look to install it via Brew, Flatpak, or Snap, but often come up short.
The fragmented packaging landscape on Linux is a problem. Some distributions share a common—yet often incompatible—package format; others use an entirely different packaging system. Flatpak and Snap attempted to resolve this issue, but all they did was create more standards—relevant XKCD. Instead of creating more standards, what we should be doing is combining the standards that already exist—cue Distrobox.
The Software Distrobox Is Built On
Before explaining Distrobox itself, you need to understand some of the software it relies on: Docker and Podman. Docker is a software program that isolates processes into separate containers; such processes typically cannot interact with the system outside the container. Containers are built on top of Linux primitives like namespaces and control groups. But don’t worry about the details; just remember that a container isolates processes.
We call Docker a container runtime. Podman is another container runtime that looks and feels exactly like Docker, except for one key distinction: Podman does not (by default) run containers as root; this is important, as you will soon find out. Docker and Podman are nearly identical, so it’s possible to follow a beginner’s guide to Docker and apply almost everything to Podman too.
How Does Distrobox Work?
A list of Distrobox containers.
Distrobox blurs the lines between distributions and leverages existing tools to install cross-distribution packages. Distrobox wraps your chosen container runtime (i.e., Podman, Docker, or Lilypod) to run processes inside a container. When you execute a Distrobox command, it delegates to the underlying container runtime.
But why? Unlike Docker, Podman, etc., Distrobox tightly integrates containerized processes with your system; they can read your home directory, see other processes, and even communicate with them. Distrobox takes care of the difficult container configuration for you, such that it will run applications—in a Docker or Podman container—seamlessly with the host.
The goal of a container runtime is process isolation; the goal of Distrobox is tight integration with little configuration.
The official Distrobox documentation clarifies “tight integration” with technical details:
…seamlessly integrates with the rest of the operating system by providing access to the user’s home directory, the Wayland and X11 sockets, networking, removable devices (like USB sticks), systemd journal, SSH agent, D-Bus, ulimits, /dev and the udev database, etc…
Why I Recommend Podman Over Docker
You should use Podman as your container runtime because, by default, it runs containers as an unprivileged user, whereas Docker runs them as root. Why is that a problem? Containerized processes inherit the privileges of their container—it’s a little more complicated than that, but that’s the general idea. Distrobox tightly integrates containers with the host; any process running inside a rootful container may have full access to your system.
Distrobox will prompt you to set a password for a container if you run it as root, which provides some protection, but it’s far from a perfect solution.
How to Install Podman
Podman is available for at least a dozen distributions. The following commands cover the most common ones.
For Debian and its derivatives (e.g., Ubuntu, Mint, etc.):
sudo apt-get install podman
For Red Hat derivatives (e.g., Fedora, etc.):
sudo dnf install podman
For Arch Linux and its derivatives:
sudo pacman -S podman
You will probably find that Podman is available in your distribution’s default repositories. The most important thing is that you configure it for rootless mode. Unfortunately, for some distributions, it may require manual configuration. Refer to the manual for your distribution because the process is different for each one.
How to Install Distrobox
Distrobox is available for over 30 distributions, so once you’ve installed Podman (or Docker), go ahead and install Distrobox using your distribution’s package manager. Below are the installation commands for the most common distributions.
For Debian and its derivatives (e.g., Ubuntu, Mint, etc.):
sudo apt-get install distrobox
For Red Hat derivatives (e.g., Fedora, etc.):
sudo dnf install distrobox
For Arch Linux and its derivatives:
sudo pacman -S distrobox
If Distrobox is not in your distribution’s repository, you can use the following curl command:
curl -s https://raw.githubusercontent.com/89luca89/distrobox/main/install | sudo sh
Actions like curl … | sh may contain and inject malicious commands; always confirm the provider and review the script.
Related
Now you must set Podman as the container runtime in the Distrobox configuration file. Run the following command, but beware that it will overwrite any existing configuration file:
echo 'container_manager="podman"' > ~/.distroboxrc
Now you’re all set.
Creating Your First Distrobox Container
Containers store your changes, and they are a thin layer on top of immutable images. Images provide the distribution’s base system. When combined, they provide a complete system. Your installed packages will live inside a container. Distrobox integrates the container’s home directory into your own, such that your package’s configuration files will live there.
When you run the following command, it creates a container from the default image:
distrobox create -n my-container
However, for the duration, we shall use Arch Linux:
distrobox create --name my-arch --image archlinux:latest
Related
What Is Arch Linux, and How Is It Different From Other Versions of Linux?
If you’re thinking of using Arch, btw.
You can create a container using any image that you want—for example, Debian:
distrobox create --name my-debian --image debian:latest
Or you can create a Fedora container:
distrobox create --name my-fedora --image fedora:latest
Don’t interrupt the container creation process; otherwise, you may corrupt it, and you will need to recreate it.
Distrobox supports more than 30 distributions for containers, each supporting multiple releases and versions. Additionally, if you’re familiar with Toolbox, you can use their images too. Distrobox maintains a big list of image names for your convenience.
How to Install an Application in a Distrobox Container
Containers are an environment that you activate. All subsequent commands execute inside the container.
distrobox enter my-arch
You can play around with this system to get a feel for it. When you’re finished, type exit.
However, instead of entering a container to install a package, it’s often better to run a one-shot command. Here we shall install Firefox, which we’ll execute a little later:
distrobox enter my-arch -- sudo pacman -S firefox
If you’ve created a container for another distribution, you can probably use one of the following commands.
For Debian and its derivatives (e.g., Ubuntu, Mint, etc.):
distrobox enter my-container-name -- sudo apt-get install firefox
For Red Hat derivatives (e.g., Fedora, etc.):
distrobox enter my-container-name -- sudo dnf install firefox
If you’re struggling with the installation commands, you should probably first learn how to install and remove software via the terminal.
When using Podman, sudo just works. Rootless Podman runs containers as an unprivileged user by default. All processes inside the container (including sudo) cannot obtain privileges higher than the container itself. This protects your host system.
Related
How to Run an Application in a Distrobox Container
To run your newly installed Firefox, run:
distrobox enter my-arch -- firefox
The previous command doesn’t return control to the terminal until Firefox exits; it’s also long. Instead, you should probably use an alias. In your shell configuration file, type:
alias firefox="distrobox enter my-arch -- nohup firefox >/dev/null"
You can name this alias anything that you want.
One of the most useful features of Distrobox is that graphical packages work without additional configuration. It works with either X11 or Wayland. Distrobox also supports GPU acceleration; if that’s something that you’re interested in, then you should refer to the Distrobox manual.
How to Think About Distrobox Containers
As mentioned earlier, containers are a layer on top of an image. Distrobox shares images between multiple containers. For example, when you create a Debian-based container:
distrobox create --name deb-1 --image debian:latest
It’ll pull down a Debian image, use it as a base system, and then create a container on top of it. When you create two more containers:
distrobox create --name deb-2 --image debian:latest
distrobox create --name deb-3 --image debian:latest
Both of these will use the same immutable Debian image, but each container is separate from each other. Installing a package into deb-1 means that it won’t exist in deb-2 or deb-3. However, they will share the same configuration file, which lives in your host’s home directory.
You might be wondering whether you should create one container or many. Generally, create one container for each distribution that you use. For example, there’s a package in the AUR (a community-maintained software repository for Arch Linux) that you want, so you create an Arch container; there are three in the Debian repositories, so you create a single Debian container and put all three in it. However, there may be scenarios where there are some software conflicts—e.g., different versions of the same package; this is an ideal scenario to create separate containers.
Other Helpful Distrobox Commands to Know
The most useful resource for commands is always the –help menu:
distrobox --help
You can get help on specific commands by appending a –help flag to it. For example, to get help for the create command:
distrobox create --help
Creating Temporary Containers
To test something out quickly, you can use temporary containers. Distrobox destroys them automatically after completion:
distrobox ephemeral
Be aware that these are slower to boot up because they have to initialize—it’s similar to creating a new container.
See distrobox ephemeral –help for more options.
Managing Containers
You should treat Distrobox containers like a subsystem; this involves creating, starting, stopping, deleting, updating, and generally maintaining containers. Below is a list of common commands that help you do this.
At some point, you will want to know what containers exist on your system:
distrobox ls
Perhaps you want to delete a container. Before you do that, you may want to first stop it, then delete it:
distrobox stop my-container
distrobox rm my-container
It isn’t strictly necessary to stop a container before deleting it, because Distrobox will prompt you to force delete it if it’s running.
You almost certainly want to keep your containers up to date. To update them all, use:
distrobox upgrade --all
Or to update a specific container:
distrobox upgrade my-container
The upgrade command will use the container’s package manager to update all of its packages. Additionally, each container requires regular updates. When you delete a container, it also deletes its updates.
To uninstall packages, just use the distribution-specific package manager for that particular container. For example, if you want to uninstall Firefox from the Arch Linux container that we created earlier, use the following:
distrobox enter my-arch -- sudo pacman -R firefox
For Red Hat derivatives (e.g., Fedora), use:
distrobox enter my-conainer-name -- sudo dnf rm firefox
For Debian and its derivatives, use:
distrobox enter my-container-name -- sudo apt-get remove firefox
How to Uninstall Distrobox
If you don’t like Distrobox and want to remove it, below are the commands to do so.
If you used curl to install it, then you must use this curl command to uninstall it:
curl -s https://raw.githubusercontent.com/89luca89/distrobox/main/uninstall | sudo sh
Otherwise, for Debian and its derivatives (e.g., Ubuntu, Mint, etc.):
sudo apt-get remove distrobox
For Red Hat derivatives (e.g., Fedora, etc.):
sudo dnf rm distrobox
For Arch Linux and its derivatives:
sudo pacman -R distrobox
One of Distrobox’s strengths is the tight integration with the host. In the Docker world, this, to some degree, is a weakness, because Docker wants to isolate processes; Distrobox wants to integrate them—this is the key difference between them. It’s also critical to understand the differences between running a container as root and running a containerized process as root. I explicitly recommend Podman because it functions better than Docker as a rootless container runtime. The maintainers of Distrobox also agree.
Pay attention to these two key points, because they’re important to protect your system. Essentially, be careful when running a container as root; don’t then run applications inside that container as a limited account—this provides a false sense of security and may lead to privilege escalation.