- Distrobox
- Execute complex commands directly from distrobox enter
- Create a distrobox with a custom HOME directory
- Mount additional volumes in a distrobox
- Use a different shell than the host
- Run the container with real root
- Using a command other than sudo to run a rootful container
- Duplicate an existing distrobox
- Export to the host
- Execute commands on the host
- Enable SSH X-Forwarding when SSH-ing in a distrobox
- Use distrobox to install different flatpaks from the host
- Using podman inside a distrobox
- Using docker inside a distrobox
- Using init system inside a distrobox
- Using distrobox as main cli
- Using a different architecture
- Improve distrobox enter performance
- Slow creation on podman and image size getting bigger with distrobox create
- Container save and restore
- Check used resources
- Pre-installing additional package repositories
- Build a Gentoo distrobox container
- Build a Dedicated distrobox container
Useful tips
Execute complex commands directly from distrobox enter
Sometimes it is necessary to execure complex commands from a distrobox enter, like multiple concatenated commands using variables declared inside the container.
For example:
distrobox enter test -- bash -l -c '"echo \$HOME && whoami"'
Note the use of single quotes around double quotes, this is necessary so that quotes are preserved inside the arguments. Also note the dollar escaping needed so that $HOME is not evaluated at the time of the command launch, but directly inside the container.
Create a distrobox with a custom HOME directory
distrobox create
supports the use of the --home
flag, as specified in the
usage HERE
Simply use:
distrobox create --name test --image your-choosen-image:tag --home /your/custom/home
Mount additional volumes in a distrobox
distrobox create
supports the use of the --volume
flag, as specified in the
usage HERE
Simply use:
distrobox create --name test --image your-choosen-image:tag --volume /your/custom/volume/path
Use a different shell than the host
By default distrobox will pick up the shell from the host and use it inside the container. If you want a different one you can use:
SHELL=/bin/zsh distrobox create -n test
SHELL=/bin/zsh distrobox enter test
Run the container with real root
When using podman, distrobox will prefer to use rootless containers. In this mode the root
user inside the container is not the real root
user of the host. But it still has
the same privileges as your normal $USER
.
But what if you really really need those root
privileges even inside the container?
Instead of running sudo distrobox
to do stuff, it is better to simply use normal
command with the --root
or -r
flag, so that distrobox can still integrate better
with your $USER
.
distrobox create --name test --image your-choosen-image:tag --root
Using a command other than sudo to run a rootful container
When using the --root
option with Distrobox, internally, it uses sudo
to be able to
interact with the rootful container through podman/docker, which will prompt for a valid
root password on the terminal. However, some users might prefer to use a command other
than sudo
in order to authenticate as root; for example, pkexec
could be used to
display a graphical authentication prompt. If you need this, make sure to specify
the desired command through the DBX_SUDO_PROGRAM
environment variable
(supported by most distrobox
subcommands), alongside --root
. Sample usage:
DBX_SUDO_PROGRAM="pkexec" distrobox create --name test --image your-chosen-image:tag --root
Additionally, you may also have any further distrobox commands use pkexec
(for example)
for rootful containers by appending the line distrobox_sudo_program="pkexec"
(replace pkexec
with the desired program) to one of the config file paths that
distrobox supports; for example, to ‘~/.distroboxrc’.
It is also worth noting that, if your sudo program does not have persistence
(i.e., cooldown before asking for the root password again after a successful authentication)
configured, then you may have to enter the root password multiple times, as distrobox
calls multiple podman/docker commands under the hood. In order to avoid this, it is
recommended to either configure your sudo program to be persistent, or, if that’s
not feasible, use sudo
whenever possible (which has persistence enabled by default).
However, if you’d like to have a graphical authentication prompt, but would also like
to benefit from sudo
’s persistence (to avoid prompting for a password multiple times in a row),
you may specify sudo --askpass
as the sudo program.
The --askpass
option makes sudo launch the program in the path (or name, if it is in $PATH
)
specified by the SUDO_ASKPASS
environment variable, and uses its output (to stdout)
as the password input to authenticate as root. If unsuccessful, it launches the program again,
until either it outputs the correct password, the user cancels the operation, or
a limit of amount of authentication attempts is reached.
So, for example, assume you’d like to use zenity --password
to prompt for the sudo password.
You may save a script, e.g. my-password-prompt
, to somewhere in your machine - say,
to ~/.local/bin/my-password-prompt
- with the following contents:
#!/bin/sh
zenity --password
Make it executable using, for example, chmod
(in the example, by running chmod +x ~/.local/bin/my-password-prompt
-
replace with the path to your script). Afterwards, make sure SUDO_ASKPASS
is set to your newly-created script’s path,
and also ensure DBX_SUDO_PROGRAM
is set to sudo --askpass
, and you should be good to go. For example,
running the below command should only prompt the root authentication GUI once throughout the whole process:
SUDO_ASKPASS="$HOME/.local/bin/my-password-prompt" DBX_SUDO_PROGRAM="sudo --askpass" distrobox-ephemeral -r
You may make these options persist by specifying those environment variables in your shell’s rc file (such as ~/.bashrc
).
Note that this will also work if distrobox_sudo_program="sudo --askpass"
is specified in one of distrobox’s config files
(such as ~/.distroboxrc
), alongside export SUDO_ASKPASS="/path/to/password/prompt/program"
(for example - however, this
last line is usually better suited to your shell’s rc file).
Duplicate an existing distrobox
It can be useful to just duplicate an already set up environment, to do this,
distrobox create
supports the use of the
--clone
flag, as specified in the usage HERE
Simply use:
distrobox create --name test --clone name-of-distrobox-to-clone
Export to the host
Distrobox supports exporting to the host either binaries, applications or systemd services. Head over the usage page to have an explanation and examples.
Execute commands on the host
You can check this little post about executing commands on the host.
Enable SSH X-Forwarding when SSH-ing in a distrobox
SSH X-forwarding by default will not work because the container hostname is different from the host’s one. You can create a distrobox with will have the same hostname as the host by creating it with the following init-hook:
distrobox create --name test --image your-choosen-image:tag \
--init-hooks '"$(uname -n)" > /etc/hostname'`
This will ensure SSH X-Forwarding will work when SSH-ing inside the distrobox:
ssh -X myhost distrobox enter test -- xclock
Use distrobox to install different flatpaks from the host
By default distrobox will integrate with host’s flatpak directory if present:
/var/lib/flatpak
and obviously with the $HOME one.
If you want to have a separate system remote between host and container, you can create your distrobox with the followint init-hook:
distrobox create --name test --image your-choosen-image:tag \
--init-hooks 'umount /var/lib/flatpak'`
After that you’ll be able to have separate flatpaks between host and distrobox.
You can procede to export them using distrobox-export
(for distrobox 1.2.14+)
Using podman inside a distrobox
If distrobox
is using podman
as the container engine, you can use
podman socket
to control host’s podman from inside a distrobox
, just use:
podman --remote
inside the distrobox
to use it.
It may be necessary to enable the socket on your host system by using:
systemctl --user enable --now podman.socket
Using docker inside a distrobox
You can use docker
to control host’s podman from inside a distrobox
,
by default if distrobox
is using docker as a container engine, it will mount the
docker.sock into the container.
So in the container just install docker
, add yourself to the docker
group, and
you should be good to go.
Using init system inside a distrobox
You can use an init system inside the container on supported images. Example of such images are:
- docker.io/almalinux/8-init
- registry.access.redhat.com/ubi7/ubi-init
- registry.access.redhat.com/ubi8/ubi-init
You can use such feature using:
distrobox create -i docker.io/almalinux/8-init --init --name test
Note however that in this mode, you’ll not be able to access host’s processes from within the container.
Example use:
~$ distrobox create -i docker.io/almalinux/8-init --init --name test
user@test:~$ sudo systemctl enable --now sshd
user@test:~$ sudo systemctl status sshd
● sshd.service - OpenSSH server daemon
Loaded: loaded (sshd.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2022-01-28 22:54:50 CET; 17s ago
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 291 (sshd)
Using distrobox as main cli
In case you want (like me) to use your container as the main CLI environment,
it comes handy to use gnome-terminal
profiles to create a dedicated setup for it:
Personally, I just bind Ctrl-Alt-T
to the Distrobox profile and Super+Enter
to the Host profile.
For other terminals, there are similar features (profiles) or you can set up a dedicated shortcut to launch a terminal directly in the distrobox
Using a different architecture
In case you want to run a container with a different architecture from your host,
you can leverage the use of qemu
and support from podman/docker.
Install on your host the following dependencies:
- qemu
- qemu-user-static
- binfmt-support
Then you can easily run the image you like:
~$ uname -m
x86_64
~$ distrobox create -i aarch64/fedora -n fedora-arm64
~$ distrobox enter fedora-arm64
...
user@fedora-arm64:~$ uname -m
aarch64
Improve distrobox enter performance
If you are experiencing a bit slow performance using podman
you should enable
the podman socket using
systemctl --user enable --now podman.socket
this will improve a lot podman
’s command performances.
Slow creation on podman and image size getting bigger with distrobox create
For rootless podman 3.4.0 and upward, adding this to your ~/.config/containers/storage.conf
file will improve container creation speed and fix issues with images getting
bigger when using rootless containers.
[storage]
driver = "overlay"
[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"
Note that this is necessary only on Kernel version older than 5.11
.
From version 5.11
onwards native overlayfs
is supported and reports noticeable
gains in performance as explained HERE
Container save and restore
To save, export and reuse an already configured container, you can leverage
podman save
or docker save
and podman import
or docker import
to
create snapshots of your environment.
To save a container to an image:
with podman:
podman container commit -p distrobox_name image_name_you_choose
podman save image_name_you_choose:latest | gzip > image_name_you_choose.tar.gz
with docker:
docker container commit -p distrobox_name image_name_you_choose
docker save image_name_you_choose:latest | gzip > image_name_you_choose.tar.gz
This will create a tar.gz of the container of your choice at that exact moment.
Now you can backup that archive or transfer it to another host, and to restore it just run
podman load < image_name_you_choose.tar.gz
or
docker load < image_name_you_choose.tar.gz
And create a new container based on that image:
distrobox create --image image_name_you_choose:latest --name distrobox_name
distrobox enter --name distrobox_name
And you’re good to go, now you can reproduce your personal environment everywhere in simple (and scriptable) steps.
Check used resources
- You can always check how much space a
distrobox
is taking by usingpodman
command:
podman system df -v
or docker system df -v
Pre-installing additional package repositories
On Red Hat Enterprise Linux and its derivatives, the amount of packages in the base repositories is limited, and additional packages need to be brought in by enabling additional repositories such as EPEL.
You can use --init-hooks
to automate this, but this does not solve the
issue for package installations done during initialization itself, e.g. if
the shell you use on the host is not available in the default repos (e.g.
fish
).
Use the pre-initialization hooks for this:
distrobox create -i docker.io/almalinux/8-init --init --name test --pre-init-hooks "dnf config-manager --enable powertools && dnf -y install epel-release"
distrobox create -i docker.io/library/almalinux:9 -n alma9 --pre-init-hooks "dnf -y install dnf-plugins-core && dnf config-manager --enable crb && dnf -y install epel-release"
distrobox create -i quay.io/centos/centos:stream8 c8s --pre-init-hooks "dnf config-manager --enable powertools && dnf -y install epel-next-release"