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?
