Offer a better way to visually distinguish between containers

[juhp]

It could be nice if the toolbox container hostname included the OS release version.
If one is running multiple toolbox releases it could be confusing which is which.

Maybe could use toolbox:30 etc. Well this is just a suggestion.

[juhp]

Well, I see there are envvars

DISTTAG=f30container
FGC=f30

defined.

[debarshiray]

Yes, I agree that this is a genuine problem.

[mildred]

Around hostname in the toolbox, I miss my machine hostname. Also, I suppose that if I start using silverblue on my servers (which will be the case when upgrading from CoreOS), I might get confused when seeing the prompt with just toolbox, not knowing if I'm on localhost or on my servers via ssh.

[mildred]

May I suggest that the default hostname should be composed of the machine hostname and the toolbox name ? For example, I run multiple toolboxes (gui, wine, dev, ...) and I have several computers (laptop, server, ...). The toolbox hostname could be a composition of both such as: laptop-gui, laptop-dev, server-dev, ...

In the meantime, I created an init script that executes when the shell starts:

if [[ "$(hostname)" = toolbox ]] && [[ "$(cat /etc/hostname)" != toolbox ]]; then
  hostname="$(cat /etc/hostname)"
  sh="$SHELL"
  if ! [[ -e "$sh" ]]; then
    sh=/bin/bash
  fi
  echo "Changing hostname from toolbox to $hostname and re-executing $sh..."
  sudo hostname "$hostname" && exec "$sh"
fi

[Jmennius]

Since there is already a way to name containers on podman level with toolbox create --container NAME - we can just use this name for internal hostname (with minor modifications to satisfy hostname limitations).
Essentially:

@@ -1079,7 +1079,7 @@ create()
             --dns none \
             --env TOOLBOX_PATH="$TOOLBOX_PATH" \
             --group-add "$group_for_sudo" \
-            --hostname toolbox \
+            --hostname ${toolbox_container//_/-} \
             --ipc host \
             --label "com.github.containers.toolbox=true" \
             --label "com.github.debarshiray.toolbox=true" \

We can also allow overriding this name (#210), but I don't see why this would be necessary with adequate default.
I can open a pull featuring this change if there is any interest (or should I look into Rust or Go versions?).

[Jmennius]

I've been using #383 which is a good place to start... ;)

Since I use Zsh with powerlevel10k theme - I decided to implement a simple toolbox indication for p10k which would include the toolbox hexagon and container name, it looks like that:

This displays the hostname as a container name.

At this point, I've come to realize that when taken to this level, the hostname will be a limitation (doesn't allow underscores, semicolons, etc) and wouldn't allow seeing the actual hostname in the shell too (see comment).

What we should do instead is provide all the toolbox metadata in some standardized format inside a container.
Potentially, we can use /run/.toolboxenv to store environment variables for container name (TOOLBOX_CONTAINER_NAME), image name (TOOLBOX_IMAGE_NAME), image version (TOOLBOX_IMAGE_VERISON), etc.
Default PS1 can use this info to present a nicer OOB experience and other shell themes/plugins would be able to depend on this to provide an even richer experience.

Please share your thoughts.
I would like to open a PR for p10k, but I can't do it until this is a standard thing for toolbox.

[mgomes]

@Jmennius I think it'd be great to expose environment variables like that versus taking over the hostname. That also provides more flexibility for people with custom prompts that may not even display the hostname.

[Jmennius]

I think we should actually create a new issue, with proper name and description (with regards to environment variables), and close this one in its favor (ff maintainers actually agree with us 😄 )

@HarryMichal your take? Should we aim to use special environment variables instead of fiddling with the hostname? See my comment.

[HarryMichal]

I'm wondering how to go around this. Adding just the OS version to the hostname is the most short-term solution since Toolbox aims to support even other distros. So maybe something in the format of <distro>-toolbox-<release>? I don't think the container's name should be also its hostname as is done in #383.

Another thing, Podman does not provide info about the container to the container itself (file /run/.containerenv is empty unlike /.flatpak-info in flatpaks). More info about this is in an upstream issue: containers/podman#6192

I'm also kinda inclined towards adding a --hostname option to toolbox create as is proposed in #210. But for that, I need an opinion from @debarshiray.

[Jmennius]

Another thing, Podman does not provide info about the container to the container itself (file /run/.containerenv is empty unlike /.flatpak-info in flatpaks). More info about this is in an upstream issue: containers/podman#6192

This is exactly what I am proposing to do - populate some variables that we can use inside of the toolbox.

I think it is inferior to have stuff automatically put into either hostname or container name, it should be all up to the user.
For example, if one wants to add a container name to shell prompt - it (prompt) may become too long or even irrelevant.

Regarding #383, yes, this is more of a temporary solution in my opinion.
If we have some identification inside the container - I think there is no reason to care about the hostname.

[debarshiray]

Duplicate of #969

[debarshiray]

May I suggest that the default hostname should be composed of
the machine hostname and the toolbox name ? For example, I run
multiple toolboxes (gui, wine, dev, ...) and I have several computers
(laptop, server, ...). The toolbox hostname could be a composition
of both such as: laptop-gui, laptop-dev, server-dev, ...

Yes, #969 has some good suggestions in this direction.

In the meantime, I created an init script that executes when the shell starts:

Yes, a start-up script is a way to hack around this.

if [[ "$(hostname)" = toolbox ]] && [[ "$(cat /etc/hostname)" != toolbox ]]; then
  hostname="$(cat /etc/hostname)"
  sh="$SHELL"
  if ! [[ -e "$sh" ]]; then
    sh=/bin/bash
  fi
  echo "Changing hostname from toolbox to $hostname and re-executing $sh..."
  sudo hostname "$hostname" && exec "$sh"
fi

By the way, looking for the existence of /run/.toolboxenv is a better way to detect whether you are inside a Toolbx container or not. This is also what /etc/profile.d/toolbox.sh uses.

[debarshiray]

At this point, I've come to realize that when taken to this level, the
hostname will be a limitation (doesn't allow underscores, semicolons,
etc) and wouldn't allow seeing the actual hostname in the shell too
(see
comment).

Yeah. :/

What we should do instead is provide all the toolbox metadata in some
standardized format inside a container. Potentially, we can use
/run/.toolboxenv to store environment variables for container name
(TOOLBOX_CONTAINER_NAME), image name
(TOOLBOX_IMAGE_NAME), image version
(TOOLBOX_IMAGE_VERISON), etc.

/run/.containerenv inside Toolbx containers have had this metadata for a while already.

Default PS1 can use this info to present a nicer OOB experience and
other shell themes/plugins would be able to depend on this to provide
an even richer experience.

Yeah. We might need a PS1 that doesn't use \h to supersede the limitations of the hostname.

Please share your thoughts. I would like to open a PR for p10k, but I
can't do it until this is a standard thing for toolbox.

Go for it! :)

I think the end goal would be to convince distributions to make their default shell prompts Toolbx aware, so that the prompt changes as necessary inside a container. Or, we could also hack something up using /etc/profile.d/toolbox.sh.

[debarshiray]

Since I use Zsh with powerlevel10k theme - I decided to implement a simple toolbox indication for p10k which would include the toolbox hexagon and container name, it looks like that: This displays the hostname as a container name.

I forgot to ask ...

What's that -o option in your screenshot? :)

[debarshiray]

Please share your thoughts. I would like to open a PR for p10k, but I
can't do it until this is a standard thing for toolbox.

Go for it! :)

I see that it got done in Powerlevel10k already.

/me is still catching up

[debarshiray]

Adding just the OS version to the
hostname is the most short-term solution since Toolbox aims to support
even other distros. So maybe something in the format of
<distro>-toolbox-<release>? I don't think the container's name should
be also its hostname as is done in #383.

Well, <ID>-toolbox-<VERSION_ID> is usually the default name of the Toolbx containers, so using that as the hostname for Toolbx containers is very close to using the container's name. :)

The problem with using <ID>-toolbox-<VERSION_ID> as the hostname is that using \h in the shell's prompt makes the prompt quite long. It would also have the problems brought up in #969

I'm also kinda inclined towards adding a --hostname option to
toolbox create as is proposed in #210. But for that, I need an opinion
from @debarshiray.

That's #563

[debarshiray]

#969 has some good ideas on how to chose a better default for the container's host name. It's not going to solve everything, but it's still going to be an improvement, and we have a clear way ahead, so let's focus on that first. Baby steps. :)

[debarshiray]

I am going to close this issue in favour of #969 so that the list of open issues doesn't balloon out of control, and continues to roughly reflect the items that are on the current to-do list. However, it will still be around for future reference.

[debarshiray]

Duplicate of #969

On second thoughts, there are two different high level items here.

One is to improve the default hostname which is important for various technical reasons and that's what #969 is about.

The second is about offering a better way to visually distinguishing one Toolbx container from another. As @Jmennius and others have pointed out, that can also be done by customizing the shell's prompt by using the metadata from /run/.containerenv without involving the hostname, or being constrained by the rules that govern valid hostnames. Let's use this issue to represent this second item.

Reopening.

[Jmennius]

Since I use Zsh with powerlevel10k theme - I decided to implement a simple toolbox indication for p10k which would include the toolbox hexagon and container name, it looks like that: This displays the hostname as a container name.

I forgot to ask ...

What's that -o option in your screenshot? :)

Ah, that's an option to only enter the container 'once' (since I do not want all tabs to be in a container by default) - just disables terminal container tracking, see #384.

[akdev1l]

imo setting the container hostname to container-name.$(hostname) achieves the distinction between host and different containers while also satisfying the technical requirements for correct name resolution.

a custom script that changes the prompt would mean that regular PS1 values inside toolbox containers wouldn't work as expected as one would have to call the custom scripts/metadata instead of using standard escape codes (eg: \u @ \h >)

this is also the approach taken by distrobox - which has risen in popularity in the community so having the behaviour be compatible seems beneficial.

sample output from distrobox:

[akdev@toronto toolbox (main)]$ distrobox --version
distrobox: 1.4.1
[akdev@toronto toolbox (main)]$ distrobox create test-alex-distrobox
[akdev@toronto toolbox (main)]$ distrobox enter test-alex-distrobox
[akdev@test-alex-distrobox toolbox (main)]$ hostname
test-alex-distrobox.toronto.hq.akdev.xyz

[matthiasclasen]

I recently came across this problem again when I was using a f36 and f38 toolbox in parallel for a while, and it was very hard to figure out what was what, since I don't set up any custom prompts or bling out my shell. I think the goal for this issue should be to make the default experience in this case non-confusing.

[jkemp814]

@Jmennius

Since I use Zsh with powerlevel10k theme - I decided to implement a simple toolbox indication for p10k which would include the toolbox hexagon and container name, it looks like that: This displays the hostname as a container name.

I forgot to ask ...
What's that -o option in your screenshot? :)

Ah, that's an option to only enter the container 'once' (since I do not want all tabs to be in a container by default) - just disables terminal container tracking, see #384.

I created a new toolbox name fedora-develop-37 and install all the 'dev tools' I would need to do rustlang development. Also install ZSH, TMUX, Oh-My-ZSH, and Powerlevel10k and Powerline bindings in TMUX. To my surprise, the toolbox name is in the Prompt of Powerlevel10k

I have another toolbox, name fedora-toolbox-37 and the name does not show up, just the 'tool icon' I wonder which package is reporting the toolbox hostname to Powerlevel10k segment in the fedora-develop-37 so I can install it in the regular fedora-toolbox-37 container, so it shows there also?

https://ask.fedoraproject.org/t/name-of-toolbox-showing-in-powerlevel10k-prompt/31590

[akdev1l]

I don't want to sound disrespectful but the fact that simple feature requests/bugs sit stale for months doesn't speak well to the general state of this project. ;-(

[lrittel]

@Jmennius
…

I took a quick look into the theme's source and the code that figures out the toolbox name is here:

https://github.com/romkatv/powerlevel10k/blob/cb9788b12a1fade6be631ad905928f9a5f7eb03f/internal/p10k.zsh#L8334

It reads /run/.containerenv and extracts the toolbox name from there.

This may be a workaround until #1086 is merged.

[juhp]

I personally don't care too much about the hostname itself particularly, but I think the only thing that makes sense is to have the container name appear in prompts by default (even my original suggestion of <os-version> was not good enough since one can easily have more than one toolbox for the same OS version). Then defaulting the hostname to the container name seems the simplest thing one can do and would make it easy to have it appear in the prompt (though, sure, if there is demand create could have an option to override the hostname).

This is really not that hard, right? Let's just do it?
With things like this I think it is better to iterate and course-correct quicker.