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]

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.

[castedo]

I imagine one can run podman exec --user root on a toolbx container because it's a container. Perhaps those that want to customize their prompt can callpodman exec after container creation (but in this case toolbx is creating the container) and do something like this:

podman exec -i --user root $CONTAINER_ID \
    cp --no-preserve=all /dev/stdin /etc/profile.d/fancy_prompt.sh <<'EOF'
        PS1=$(
            source /etc/os-release
            echo "⬢$ID:$VERSION_ID [\u@\h \W]\$"
        )
EOF

If toolbx sets an environment variable with the container name then you can throw that into the PS1 too.

The actual lines of bash code that I rely on for this starts at https://github.com/castedo/cnest/blob/cnest-2.1-2/bin/create-cnest#L72

The key observation here is that podman and most Linux distribution already offer a way to achieve this feature. Specifically they offer:

• podman exec --user root
• placing scripts in /etc/profile.d (with filename ending in .sh)
• scripts in /etc/profile.d can set the users PS1 ... well on Fedora and friends you can, set debian_chroot on Debian and friends
• using podman exec -i to stream in a script
• using cp --no-preserve=all /dev/stdin to pick up what is streamed in
• using bash heredoc to write out the script
• sourcing /etc/os-release to get distro name and version
• using $( ... ; echo ...) to keep bash variable temporary

[castedo]

Regarding messing with the hostname, for a generic tool that I assume should work well with lots of different applications, I recommend against setting the hostname to something other than the host hostname if the container shares the network. distrobox was doing that and it causes enough problems they changed it. There's a lot more discussion and detail here:
89luca89/distrobox#62

For most apps it's probably not an issue. I went years messing with the hostname for the sake of tweaking the prompt, and never had a problem, but I only use CLI tools in my containers.