Alternatives to toolbox on Silverblue?

Silverblue worked well as a hypervisor. However, we are having problems attempting to use it as an OS for development. Namely, that the suggested toolbox commands do not work as advertised. So how should development project specific tools be installed?

The initial toolbox create problem was raised in post toolbox create ask . And the create problem proposed solution lead to the enter problem toolbox enter ask. These posts do not have solutions given. Toolbox is foobar out of the box.

[Saying toolbox is foobar, i.e. unusable, apparently makes Scott Williams unhappy as he failed to reproduce the problem, so he closed my post asking for alternatives. Hopefully he won’t prevent us from hearing about alternatives here. But if you are wondering why there are two posts asking for alternatives, this is why.]

People with separate project users, how are you installing project specific tools on Silverblue, are they using docker? podman directly? Will flatpak work?

I have used Toolbx with different toolboxe containers for different projects before (see Toolbx documentation about having multiple named Toolbx containers.

I have however gradually moved from this and now mostly either have scripts for each project to build/run them through Podman, or use CRC, depending on the type of project I’m working on.

Flatpak generally works, but I don’t use it for my editor, since I find it makes interaction between it and Podman unnecessarily complicated.

Your issue in the other post seems to be about trying to use it through su, which I don’t see the point of, as you can easily keep separate sets of containers under the same user account. That makes it appear like an X-Y problem, so if you are not going to explain why this is useful to do, I think you should drop it and instead continue on thw path taken in this question, which is to find out how other people do development work using containers. Being belligerent about it will however make people less inclined to want to help you.

Bjorn, All you had to do was ask. There is no recalcitrance on my side … though sometimes sleep breaks and pesky people creating interrupts and delay my replies…

Each development project on the server has its own user. This has a number purposes: 1) builds on one project will not affect files in other projects, because they can’t. 2) Some projects have accessible portions through unix sockets, and this assures the security when gating through the unix socket. 3) There is a nifty log of when a developer enters a project. 4) The project ownership becomes the same as the user ownership, which is nice when looking at archives to know what a file belongs to. 5) it allows the use of ACLs to create temporary ‘administrators’ over projects. 6) Actually we enter projects through a script, the su is embedded in the script. The script sets up the environment. (A similar approach is used by Python env with their bin/activate.) Thus a developer may log into the server under his or her own username, and do other work or to enter and leave projects. (I tacked on the sudo, because that is a real example, and I did not have the password for the development user I logged into for the example, it was expedient. I apologize if you found this confusing.)

I think it is fairly common practice to do something like this. A Bing search reveals quite a few posts from people complaining about toolbox mounting the whole of the home directory in toolbox. “Toolbox: A Silverblue Misadventure”, “Toolbox should not mount /home by default: This is an issue …” “Toolbox should have an option to mount only a specific directory: …” There are also a few articles with people having difficulty of using toolbox create, and arriving at the fix mentioned in the ask question mentioned in the original post just above. There are reasons people are using toolbox after an su -l, it is probably related to some of the points in the prior paragraph.

This workflow has existed for a long time. In the prior step in its evolution, projects were given groups, but then project users could not adjust file permissions even when they were given write access to the given directories. ACLS are more flexible.

I hope someone will speak more specifically about how their workflow works with Silverblue for installing project specific tools as that is would be a good thing to have, then developers could install their own tools. … though is that really a great idea … hmmm. Many copies of the same thing, stuff forgotten, no clear path for maintaining the tools as it is not even clear which ones are being used. Anyway, I wanted to try it out, and I hope someone will discuss what they do.

It is interesting to me that containers re-invent the user concept. The concept of the ‘user’ was invented along with that of virtual memory and processes so as to be a container for separate jobs at compute centers. I.e. the ‘user’ is the original container. Users also have local bin directories for local tool installs. The whole PATH concept is to control which tool set gets used. I suspect that at some point these two paradigms will be unified. In a sense, if toolbox worked with su, we would have that unification here, and then have the best of both paradigms.

… though there is still that issue about administering tools … Does Silverblue eliminate all the duplication by sharing immutable files, or only some of it? Only the part in the OS?

There are ways to get what you want. Toolbox was created with one purpose in mind, it may not be your purpose for wanting container usage. Toolbox just makes it easy to start using a containerized development environment, not necessarily the right one for everyone though. You should check some of the blog posts about using Podman, I bet your solution lies there. https://www.redhat.com/sysadmin/podman-inside-container talks about privileges in containers, and there are more posts about using Podman Buildah and Skopeo to make your own container images, etc…

Please keep things polite here.

I was simply unable to reproduce your problem. That doesn’t mean that you don’t have a problem. If I can’t reproduce it, I’m not going to be as much help in solving it. I didn’t close your topics because you had trouble with toolbox - I closed them because you created three topics for the same issue in attempts to consolidate around the topic where people were already trying to help you.


As far as alternatives go, you might check out DistroBox. Perhaps this is what you’re trying to accomplish?

1 Like

I’m also confused. What led you down the path to want to use the container interactively with toolbox as opposed to using the containers directly with podman?

Like, is the purpose of the server act a shared development environment? Do they code directly on that box or are do they push code in there and then get it to build? I’m trying to understand what the workflow looks like. Thanks!

2 Likes

distrobox does everything that toolbox does, but better.

And shameless plug, I recommend my tool host-spawn to make interacting with the host from within the container even better (it comes bundled with distrobox).

I’ve been using these two tools on Silverblue for the past 2 years and it’s been a total breeze, and my best Linux experience of the past 23 years I’ve used this OS.

1 Like

Thank you for host-spawn :pray:

Distrobox is an even more attractive product with it, and I find it quite invaluable.

1 Like