Make toolboxes use the container name as hostname. #771

runfalk · 2021-05-20T13:34:01Z

This allows the user to easily see which container they are currently in instead of the generic @toolbox.

I use multiple toolboxes, tied to the projects I'm working on. When I have many open at the same time it's hard for me to know which one I'm actually in since they all have the same hostname (toolbox). This changes things so that the container re-uses the container name as host name.

An alternative solution would be to prefix the prompt like Python virtualenvs do: (fedora-toolbox-34) user@toolbox:, but that's a bit trickier to get right.

runfalk · 2021-05-20T15:06:24Z

It looks something like this:

runfalk@hostname:~/dev/toolbox (main)$ ./builddir/src/toolbox create --distro fedora --release f34
Image required to create toolbox container.
Download registry.fedoraproject.org/fedora-toolbox:34 (500MB)? [y/N]: y
Created container: fedora-toolbox-34
Enter with: toolbox enter
runfalk@hostname:~/dev/toolbox (main)$ toolbox enter
runfalk@fedora-toolbox-34:~/dev/toolbox (main)$

HarryMichal

Found a mistake in changes of examples in README.

README.md

images/fedora/f32/README.md

images/fedora/f33/README.md

images/fedora/f34/README.md

This allows the user to easily see which container they are currently in instead of the generic @toolbox.

runfalk · 2021-05-24T18:58:59Z

Good spotting. Fixed!

HarryMichal · 2021-05-24T22:49:32Z

Thank you, @runfalk, for the patch! I'm not entirely sure about this change as it is not as minor as it would seem. I'd like to know what @debarshiray thinks about this. I'm inclined to accepting this but @debarshiray may have some more insight.

runfalk · 2021-05-25T21:06:16Z

I don't think this requires toolbox recreation (label 6). I tested this change with a pre-change toolbox and everything I tested worked just fine. This only changes new toolboxes. Is the hostname essential to anything in toolbox itself?

EDIT: I did a quick grep and the line I changed is the only occurance of hostname in the code (aside from the readmes and the hostname package that get installed).

HarryMichal · 2021-05-25T21:30:07Z

I used the label because the change does not affect existing containers. Those already have the hostname set. Therefore, containers have to be recreated with the version of Toolbox that has this patch.

runfalk · 2021-05-26T13:26:27Z

The point I wanted to make is that they don't have to be recreated, as they work perfectly fine even with the patched toolbox.

HarryMichal · 2021-07-22T09:18:49Z

I found myself thinking about this today and realized this may be incompatible with #784. It is a classic problem with containers: the configuration is baked in and can not be changed. In order to make this work across container renames, some other mechanism should exist.

mattweidner · 2021-12-14T22:05:52Z

Perhaps a compromise would be to add a toolbox create option (--hostname) that is passed through to podman to set the container hostname to an arbitrary string. If no --hostname option is provided, the default string "toolbox" could be used. The user could choose to set the hostname the same as the container name or something else, but there would be no implicit expectation for the hostname to change when the container is renamed. This would mirror the operation of podman, allow users to have a choice in their container's hostname, and potentially deconflict #784.

dabrain34 · 2021-12-16T12:48:03Z

would be good to have a prefix with toolbox always because you name your container without toolbox in the name, you might be confused too such as:

"--hostname", "toolbox-" + container,

cig0 · 2021-12-22T23:33:54Z

I'm happy to see I'm not the only one that would love to see this feature implemented :)

Today I quickly put together the following workaround:

C=(ansible aws gcp python)

for i in "${C[@]}";
    do
        toolbox create -c $i \
        && toolbox run -c $i sudo hostname $i \
        && toolbox run -c $i hostname \
        && echo -e "\n\n";
    done

Which provides some relief (!?) to me:

shoop · 2022-01-15T10:26:26Z

I have the opposite request, I don't understand why the hostname needs to be set. I fully support a mechanism to show which container is active, but I have issues with the hostname set to something different than the original host:

Configuration software like chezmoi expects to be able to distinguish on hostname.
Network software now suddenly needs to be able to resolve a not-really-existing hostname. Even the workaround proposed to use containername.hostname is fabricating a non-existing network name, really, as the toolbox itself does not have a separate network.

So I'd like to have the containername in /run/.toolboxenv and then have bash prompts etc be updated to use that, instead of messing around with what is in my view a system property.

buck-ross · 2022-01-24T07:53:28Z

@shoop I have an alternative proposition, but first, I'd like to take the time to address the concerns you've enumerated:

Configuration software like chezmoi expects to be able to distinguish on hostname

This is true, but many software products with this requirement tend to require only a distinct hostname, not necessarily a DNS resolvable one. As such, it can become problematic if multiple toolbox containers, running the same software package, are given the same hostname (I.E, the host's hostname), meanwhile it seems entirely unnecessary to place the burden on the toolbox devs to ensure that the hostname is always DNS resolvable.

Network software now suddenly needs to be able to resolve a not-really-existing hostname

What about this is sudden? All toolbox containers currently have the hostname toolbox, which is presumably never network-resolvable. What we really need is a way to give some containers the same hostname as the host (or other resolvable names), and others may have other hostnames, which may or may not be resolvable.

So I'd like to have the containername in /run/.toolboxenv

This is already provided in /run/.containerenv. No need to modify /run/.toolboxenv. I have my environment configured to extract the container's name as follows:

if test -z "$CONTAINER_NAME" && test -f /run/.containerenv; then
    cat /run/.containerenv | sed -e '/^name=/!d' -e 's/^name="//' -e 's/"$//' | export CONTAINER_NAME="$(cat)"
fi

buck-ross · 2022-01-24T07:55:33Z

I propose that instead of having the hostname always set to the container name, or always set to the host's hostname, we should instead give the user the option of setting the hostname to some (sane) value when invoking toolbox create with an optional flag, like --hostname. This was already proposed in #210, but was recently closed due to the author seemingly being unwilling to re-write their changes in Go.

I've already isolated the exact line which needs to be changed (create.go#L395), and have a plan to add this new flag on my own fork as soon as I get the chance. Assuming this idea is well received, I'll make my own PR in a few weeks, once I've had a chance to write the new feature & all associated test-cases.

debarshiray · 2022-11-17T13:27:01Z

The point I wanted to make is that they don't have to be
recreated, as they work perfectly fine even with the
patched toolbox.

What do you mean? As far as I can see, this pull request only changes the podman create ... invocation for creating new Toolbx containers. So how will it automatically update the hostnames of existing containers?

debarshiray · 2022-11-17T13:27:47Z

src/cmd/create.go

@@ -401,7 +401,7 @@ func createContainer(container, image, release string, showCommandToEnter bool)
 	createArgs = append(createArgs, xdgRuntimeDirEnv...)

 	createArgs = append(createArgs, []string{
-		"--hostname", "toolbox",
+		"--hostname", container,


I suspect that the rules for a valid hostname are different from the rules for a valid OCI container name.

debarshiray

To improve the default hostname of the containers, we should implement #969

When it comes to offering better ways to visually distinguish Toolbx containers from one another, see #98 for some ideas. eg., there's metadata in /run/.containerenv that can be used by users to customize their shell prompts without requiring changes in Toolbx itself.

debarshiray · 2022-11-17T13:34:06Z

I am going to have to close this pull request.

However, thanks for your interest in Toolbx and contributing to the discussion.

debarshiray · 2022-11-17T17:20:05Z

I'm happy to see I'm not the only one that would love to see this feature implemented :)

Today I quickly put together the following workaround:
C=(ansible aws gcp python)

for i in "${C[@]}";
    do
        toolbox create -c $i \
        && toolbox run -c $i sudo hostname $i \
        && toolbox run -c $i hostname \
        && echo -e "\n\n";
    done
Which provides some relief (!?) to me:

@mildred has another way to do this via a start-up script.

debarshiray · 2022-11-17T20:11:35Z

I am going to have to close this pull request.

However, thanks for your interest in Toolbx and contributing to the discussion.

You are also welcome to help implement #969

HarryMichal requested changes May 24, 2021

View reviewed changes

README.md Outdated Show resolved Hide resolved

images/fedora/f32/README.md Outdated Show resolved Hide resolved

images/fedora/f33/README.md Outdated Show resolved Hide resolved

images/fedora/f34/README.md Outdated Show resolved Hide resolved

Make toolboxes use the container name as hostname.

c8b01d4

This allows the user to easily see which container they are currently in instead of the generic @toolbox.

runfalk force-pushed the main branch from 1261d88 to c8b01d4 Compare May 24, 2021 18:58

runfalk requested a review from HarryMichal May 24, 2021 21:14

runfalk mentioned this pull request Jul 3, 2021

Use buildah for building images #773

Closed

erazemk mentioned this pull request Aug 11, 2021

Usability and Quality of Life #853

Closed

mvala mentioned this pull request Nov 15, 2021

Container name as env in toolbox or as hostname #926

Closed

Funky185540 mentioned this pull request Jan 22, 2022

profile.d: Add "istoolbx" alias #994

Closed

buck-ross mentioned this pull request Jan 28, 2022

Allow toolbox containers to be created with a custom hostname #1007

Closed

3 tasks

matthiasclasen mentioned this pull request Oct 3, 2022

Offer a better way to visually distinguish between containers #98

Open

debarshiray reviewed Nov 17, 2022

View reviewed changes

debarshiray closed this Nov 17, 2022

debarshiray mentioned this pull request Nov 17, 2022

Don't set entire FQDN hostname to just container name #969

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make toolboxes use the container name as hostname. #771

Make toolboxes use the container name as hostname. #771

runfalk commented May 20, 2021 •

edited

Loading

runfalk commented May 20, 2021

HarryMichal left a comment

runfalk commented May 24, 2021

HarryMichal commented May 24, 2021

runfalk commented May 25, 2021 •

edited

Loading

HarryMichal commented May 25, 2021

runfalk commented May 26, 2021

HarryMichal commented Jul 22, 2021

mattweidner commented Dec 14, 2021

dabrain34 commented Dec 16, 2021 •

edited

Loading

cig0 commented Dec 22, 2021 •

edited

Loading

shoop commented Jan 15, 2022

buck-ross commented Jan 24, 2022 •

edited

Loading

buck-ross commented Jan 24, 2022

debarshiray commented Nov 17, 2022

debarshiray Nov 17, 2022

debarshiray left a comment

debarshiray commented Nov 17, 2022

debarshiray commented Nov 17, 2022

debarshiray commented Nov 17, 2022

Make toolboxes use the container name as hostname. #771

Make toolboxes use the container name as hostname. #771

Conversation

runfalk commented May 20, 2021 • edited Loading

runfalk commented May 20, 2021

HarryMichal left a comment

Choose a reason for hiding this comment

runfalk commented May 24, 2021

HarryMichal commented May 24, 2021

runfalk commented May 25, 2021 • edited Loading

HarryMichal commented May 25, 2021

runfalk commented May 26, 2021

HarryMichal commented Jul 22, 2021

mattweidner commented Dec 14, 2021

dabrain34 commented Dec 16, 2021 • edited Loading

cig0 commented Dec 22, 2021 • edited Loading

shoop commented Jan 15, 2022

buck-ross commented Jan 24, 2022 • edited Loading

buck-ross commented Jan 24, 2022

debarshiray commented Nov 17, 2022

debarshiray Nov 17, 2022

Choose a reason for hiding this comment

debarshiray left a comment

Choose a reason for hiding this comment

debarshiray commented Nov 17, 2022

debarshiray commented Nov 17, 2022

debarshiray commented Nov 17, 2022

runfalk commented May 20, 2021 •

edited

Loading

runfalk commented May 25, 2021 •

edited

Loading

dabrain34 commented Dec 16, 2021 •

edited

Loading

cig0 commented Dec 22, 2021 •

edited

Loading

buck-ross commented Jan 24, 2022 •

edited

Loading