HowTo: prevent breakage by isolating your dotfiles of Distrobox/Toolbox containers

Ask Fedora
, , ,
1

Why want containers?

Distrobox and Toolbox containers allow to run a different distro ontop of your host.

This allows:

  • testing
  • isolating apps
  • separating development environments,
  • using outdated software or
  • software only compatible with other distros

But, especially when using a different distro in the box than on your host OS, there is a big issue.

The mutable home directory

The home directory is completely unmanaged.

whereis fish

will not show your mutable (editable) config files, like in ~/.config/fish/.

Also, there is a ton of apps not following the FDO spec and placing their files all over the place, often in home (like ~/.mozilla).

Potential issues

By design, Toolbox and Distrobox containers use the same home directory as your user profile.

This breaks the fundamental idea of isolation, as doing random tests in the containers will not leave your home untouched.

The home directory is not cleaned by any package manager, so your dotfiles will grow and need to be manually deleted. Not nice.

Also as dnf system-upgrade does not work within a Toolbox/Distrobox, you need to recreate the container with the then new version. If you dont do this all the time you upgrade your host, even if you use Fedora containers, you may have programs conflicting with their dotfiles.

This can cause breakage, that not even a system reset can fix.

Solution

Toolbox does not have a config to use a different home directory.

You can use Podman and assemble a container using a dockerfile, like in this example.

Using distrobox, this setting is not default (which hopefully changes soon), but you can solve this easily:

sudo tee -a /etc/distrobox/distrobox.conf <<EOF
DBX_CONTAINER_HOME_PREFIX=$HOME/distrobox
EOF

From now on, every newly created box will automatically use ~/distrobox/$boxname/ as home directory, without any extra arguments.

distrobox create boxname
distrobox enter boxname

cd ~
$PWD
2 Likes
2

Anaconda, anaconda-navigator, conda, Rust Lang, Go Lang :exclamation: :exclamation:

:eyes:

2 Likes
3

Shouldn’t this be using tee? cat is not the process writing the file so using sudo here does nothing.

If isolation is required podman without toolbox/distrobox is also a good option. Once setup it’s pretty similar in usage. Create an alias for podman exec -it or use ptyxis to open the container.

1 Like
4

+1 for my favorite Terminal. and I’m not even using it for containers.

1 Like
5

There are many tools doing the same thing.

cat reads the input and passes it to the output location. No idea what is best, but heredocs are the only way I found to reliably print whatever you want

I will do a GNOME week or so and try to use it, already have a ton of better applications than the GNOME defaults :slight_smile:

6

@job79 is right
Like sudo echo 123 > /etc/foo, it doesn’t work because sudo is applied to the command and not to the redirection.
So the correct command is

sudo tee /etc/distrobox.conf.d/custom-home.conf <<EOF
DBX_CONTAINER_HOME_PREFIX=$HOME/distrobox
EOF

In addition, you wrote mkdir /etc/distrobox.conf.d/ then /etc/distrobox/distrobox.conf.d/

And, most important, where distrobox.conf.d comes from?
Reading the documentation, one of the possible configuration file is
/etc/distrobox/distrobox.conf
And IMO, it is better to use a configuration file in the home directory: ${HOME}/.config/distrobox/distrobox.conf or ${HOME}/.distroboxrc

Lastly, IMO, it is not always true that sharing the same home directory with the host system is an issue.
I use many boxes where I want to use stuff located in my home, and those boxes don’t interfere with all the rest. So, at least with distrobox, when I want isolation, I use --home /your/custom/home option with distrobox create

4 Likes
7

Oh well thanks! Fixed it up.

A conf.d is normally always supported and adding an additional file does not interfere with any distro upgrades.

But otherwise tee -a could work.

But I cant imagine that this does not interfere.

That is the alternative, but it is opt-in. I prefer the clean and automated way :slight_smile:

Disagree a lot. Doing this over years is likely to cause dotfile bloat or breakages.

I would like to have a system that I dont need to reinstall every few years because it breaks. And I would like to help other people have the same.

1 Like
8

I think it’s a good write up on how to isolate environments for those who would like to have the additional packages, experiment with Browsers and other software tools downloaded from Githlab/hub and not suffer the dependency hell that could happen.

I think it would be good practice for those who use Workstation as well, seeing as having the removal or installation of packages break during system-upgrades as they often do. People experimenting with tools tend to leave behind things that eventually make it difficult to upgrade via the Software Center as well.

Toolbox should have had :face_with_symbols_over_mouth: this feature in 2019 :exclamation:

1 Like
9

That’s fine. It doesn’t mean that the other way forcefully leads to “breakages”.

10

It should be sudo mkdir -p /etc/distrobox/distrobox.conf.d/ since /etc/distrobox doesn’t exist as well.

Anyway

It is just an assumption? A conf.d is supported if the software is made to make use of it; it is not a standard.

Indeed there is no mention of /etc/distrobox/distrobox.conf.d in the Distrobox documentation. And as far as I can see, /etc/distrobox/distrobox.conf.d/custom-home.conf is not taken into account when I create a new box. Am I doing something wrong, or do you need to review the procedure?

2 Likes
11

Yes I thought of the same. The parent dir may not exist. Also that it may be pretty standard that a conf.d is supported, but maybe not.

Just in case that Fedora would ship an own config, it would be useful to have this.

I will do a reinstall anyways and test this, then if it works add it back.