Toolbox: idea: include OS release in hostname

[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 :smile: )

@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 https://github.com/containers/toolbox/pull/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: https://github.com/containers/podman/issues/6192

I'm also kinda inclined towards adding a --hostname option to toolbox create as is proposed in https://github.com/containers/toolbox/pull/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.