Usability and Quality of Life

[desmond-rhodes]

I am using toolbox in Fedora Workstation. There are things I need to and would like to do with toolbox, but cannot. I believe these features will greatly improve the usability and quality of life when using toolbox.

1. Show what container I am in

I manage multiple containers to do different things in them. However, there is no way to tell what container I am currently active in. This causes lots of confusion as I have to mentally keeps track of in which container context I am working on.

My work around to ensure I'm working on the right container context right now is to exit from the current container first, then re-enter the intended container again. Abhorrent to my workflow.

2. Hot-switch between containers

Say I have containers a, b, and c.

If I'm currently working inside of container a, in order to switch to container b, I have to first exit from container a, then enter container b. This is greatly inconvenient.

If I instead do not exit from container a, and directly enter container b, then I am working inside of container b inside of container a. This is terrible since if I were to enter container a, then b, then c, I now have 4 stack of shells working on top of each other (also counting the host shell).

A functionality to hot-switch between containers is then a better solution. I can switch around between multiple containers easily and quickly without worrying about the stacks.

3. Duplicating containers

Right now, there is no way of duplicating existing containers quickly other than having to create an image backup of it first.

This horrible experience is most apparent when doing the initial setup of a container. In Fedora, I keeps on having to do sudo dnf upgrade --refresh -y on each and every new container I create. This is both a waste of time and a waste of internet bandwidth.

A second scenario of this functionality, is when I want to quickly try playing around on an already working container. The 3 options to do this are cumbersome. 1st is to create an image backup of the container, then load it as a new container. 2nd is to create a new fresh container and redo all of the setups. 3rd is to not create a new container and play around directly on the working container, risking to destroy it.

Hence, a feature to be able to quickly duplicate containers is necessary, if we were to keep the spirit of sandboxing.

4. Sandbox and-bleed through and read-only and read-write configuration

I have numerous scripts under /usr/local/bin. For every container, each have their own unique version of /usr/local/bin. Although ideal for testing, as to not destroy the original /usr/local/bin, also problematic for keeping functionality between containers. The work around to keep them consistent across containers right now is to duplicate them, and keep tracks of any changes and making sure to apply that change to all of the containers.

I do not want to sacrifice the sandboxing of /usr/local/bin on containers. I still want all of them to have a unique version of it and not have the ability to change the host's /usr/local/bin. However, I also would like to have access to my scripts on the host's /usr/local/bin.

On the same note, /usr/local/bin are sanboxed, but $HOME isn't. I would like every containers to have unique config files, such as .bashrc, .vimrc, .ssh, etc.

So, the bottom point of this is that, I want a way for containers to inherit existing functionalities and configs from the host, but also have the ability to have unique customization for each containers.

The only other work around on this right now is to mount a path from the host on the container. But this is an all or nothing work around. I can either sacrifice sandboxing, or I give up functionality consistency.

[erazemk]

1. Show what container I am in

+1 for this, maybe the hostname could be replaced with the container name. (Edit: This is apparently an existing pull request)

2. Hot-switch between containers

Why not just open another terminal window? If you open another tab, it will open it inside the container, but a new terminal window opens on the host. It's almost easier than opening a new terminal tab, since you can map gnome-terminal to something like Win+T and immediately open a new window.

3. Duplicating containers

+1 for this too.

4. Sandbox and-bleed through and read-only and read-write configuration

This is missing the point of toolbox, your system configuration should be specific to each container (e.g. which programs you have installed), but your home directory should be shared between containers so you still have access to all your files.
If you want to share your scripts between containers move or symlink them to $HOME/.local/bin or whichever other directory you have in your $PATH.
To have separate dotfiles add a few if-statements to your bashrc or config.fish or whatever zsh uses, based on whatever parameter you use to differentiate your containers, could be as simple as having some specific file in each container named after the container (e.g. /opt/container1). Then only source the files that are specific to that container.

[debarshiray]

2. Hot-switch between containers

Why are the stacked (or nested) shells so terribly worrying? :)

[MinmoTech]

For 1. see starship/starship#2590

Upvote that PR and this repo :)

I strongly wish 3. was a thing, I'd love to setup a base toolbox once and reuse that for multiple development environments afterwards.

[akhilman]

I believe that to solve 4 it will be enough to allow the user to pass podman's --volume parameter while creating the container with toolbox create.

Update:
This issue seems to be solved by #100

[debarshiray]

1. Show what container I am in

You can use the metadata in /run/.containerenv inside the Toolbx container to identify the container. You can use it to customize the shell's prompt, as some people have done already. #98 is about investigating whether we can do something better out-of-the-box.

maybe the hostname could be replaced with the container name

First, I suspect that the rules for a valid hostname are different from the rules for a valid container name. Secondly, the default container name tends to be long, and a lot of OSes default their shell's prompt to include the hostname. Simply setting the hostname to the container name will make the prompts unwieldy for most people. Users who are fine with that can already customize their prompts today, as I said above.

[debarshiray]

3. Duplicating containers

Right now, there is no way of duplicating existing containers quickly other than having to create an image backup of it first.

This horrible experience is most apparent when doing the initial setup of a container. In Fedora, I keeps on having to do sudo dnf upgrade --refresh -y on each and every new container I create. This is both a waste of time and a waste of internet bandwidth.

A second scenario of this functionality, is when I want to quickly try playing around on an already working container. The 3 options to do this are cumbersome. 1st is to create an image backup of the container, then load it as a new container. 2nd is to create a new fresh container and redo all of the setups. 3rd is to not create a new container and play around directly on the working container, risking to destroy it.

You can improve upon 2nd by keeping a Containerfile around that layers on all your custom set-up on top of the Toolbx image. Then you podman build ... a custom image from it, and use that to create the containers. Would that work?

[debarshiray]

4. Sandbox and-bleed through and read-only and read-write configuration

I have numerous scripts under /usr/local/bin. For every container, each have their own unique version of /usr/local/bin. Although ideal for testing, as to not destroy the original /usr/local/bin, also problematic for keeping functionality between containers. The work around to keep them consistent across containers right now is to duplicate them, and keep tracks of any changes and making sure to apply that change to all of the containers.

I do not want to sacrifice the sandboxing of /usr/local/bin on containers. I still want all of them to have a unique version of it and not have the ability to change the host's /usr/local/bin. However, I also would like to have access to my scripts on the host's /usr/local/bin.

The entire / from the host is available inside the Toolbx container at /run/host. You can then bind mount whatever you want from there inside the container with sudo mount --rbind .... One place to do this is a shell start-up script by checking for the existence of /run/.toolboxenv.

The plan is to make it easier to have such custom bind mounts by offering a static configuration file, but that's not available today.

Another option is to use ~/.local/bin for your scripts.

On the same note, /usr/local/bin are sanboxed, but $HOME isn't. I would like every containers to have unique config files, such as .bashrc, .vimrc, .ssh, etc.

That's #183

So, the bottom point of this is that, I want a way for containers to inherit existing functionalities and configs from the host, but also have the ability to have unique customization for each containers.

The only other work around on this right now is to mount a path from the host on the container. But this is an all or nothing work around. I can either sacrifice sandboxing, or I give up functionality consistency.

Umm... is it really all or nothing? Depending on how $PATH and the bind mounts are set up, you could have the executables specific to a container override the ones that came from the host.

[debarshiray]

I am tentatively closing this one, because it hasn't seen any activity in a while.

Feel free to leave a comment if you have something more to add.