Use something other than hostname to indicate container name in command line prompt about distrobox HOT 18 CLOSED

Reopening this discussion!
In the end I think @castedo you were right all along 😁

I'd like to open a discussion on the future behavior of distrobox

Right now distrobox uses the container's name as hostname for the box

This leads to the upside of being easily recognizable
But on the other hand, it creates some issues with KDE and GNOME for exported apps (missing icons, freezes and such)

What I was thinking is to modify the default prompt (the one with the little box) to use $CONTAINER_ID (which is the container's name) and be recognizable that way. I know that some custom prompts already support that variable so that should be ok.
Then switch to use host's hostname for created boxes by default and keep it synced with the host

If using --unshare-netns or setting explicitly --hostname the user's preference will be preserved, no changes will occur

This would be a change for new boxes, old boxes will keep functioning as they are

I'm open to feedbak and workflows that might be affected by this, if I'm missing something and such

from distrobox.

perhaps there is some sense in setting the hostname to something longer, like container-name.thehost-hostname so that /etc/hostname

I like this idea, I'll fiddle with it these days and if all works well with backward compatibility, I'll include this
I was thinking to use container-name.container-id but probably container-name.host-hostname it's better
Will open a new issue referring this one if all goes well for the implementation 👍 thanks a lot 😄

For 2 I don't think it's in the scope of the tool as a service exposed in the container is also reachable from the host's hostname, which is what you expect from a pet container ,

from distrobox.

Hi @castedo interesting approach
What type of problems does using The hostname rise?
Generally speaking if we're talking about the network traffic, I'd say it's an intended behavior

from distrobox.

Anyway if we want to have an alternative to the hostnames, we need to find something that works across all distros

from distrobox.

What type of problems does using The hostname rise?

Any application that actually wants to programmatically get the real hostname or FQDN. For instance, a python application that does

import socket
socket.gethostname()
socket.getfqdn()

Because distrobox resets the hostname, the hostname and FQDN are no longer actual network reachable names on any network. In particular they aren't valid names on the network to which the container is actually connected. It's not hard to imagine applications where this is not the desired behavior. For instance, a web application that reports to the users how to connect to the machine via browser URL etc...

Generally speaking if we're talking about the network traffic, I'd say it's an intended behavior

If the container is supposed to have a new hostname and FQDN on the network then distrobox has a separate bug which is it makes no effort to actually register this new name on its network.

Anyway if we want to have an alternative to the hostnames, we need to find something that works across all distros

My impression is that distrobox is showing the container name only in distros that show the hostname in the command line prompt. If a distro that does not show hostname in the prompt, then distrobox is not showing the container name in the prompt. So it is already the case that distrobox does not have prompt setting that works across all distros. It is true that showing hostname in the prompt is very popular across many distros.

from distrobox.

Today I learned that podman and docker have a --cidfile option. So that together with -v can be used to set the container name inside the container, either /etc/debian_chroot or some other hopefully-eventually-standard location like perhaps /etc/osvirtalias. Then distros and users can use that file to customize the command prompt as desired. (This is what I'm planning to do castedo/cnest#6)

from distrobox.

Yea I see what you mean

If the container is supposed to have a new hostname and FQDN on the network then distrobox has a separate bug which is it makes no effort to actually register this new name on its network.

Probably I'd be a bit more inclined this way

My impression is that distrobox is showing the container name only in distros that show the hostname in the command line prompt. If a distro that does not show hostname in the prompt, then distrobox is not showing the container name in the prompt. So it is already the case that distrobox does not have prompt setting that works across all distros. It is true that showing hostname in the prompt is very popular across many distros.

yea because it's (almost) ubiquitous among all non-minimal distributions to show the hostname this way.

I'm more inclined to have something to register container's hostname outside, and maybe make the container hostname configurable at this point

from distrobox.

OK, sounds like you're going for "hostname" a bit in the spirit of web servers handling multiple different hostnames for different websites even though they all have the same IP address. If DNS was setup right, I could imagine some users might expect http://myhost:80 to be handled by a process on the host with hostname 'myhost' but then http://myhost-test:8080 to be handled by a process running in a container named myhost-test with hostname myhost-test even though they are sharing the network and have the same IP address.

So sounds like different users can have different expectations about the relationship between the host and whether a container sharing a network has the same hostname or not. I find myself thinking of my 'pet' containers that share the network with the host as more like chroots which are handling different roles but on the same host (same hostname). So when I ssh to my different computers and enter a 'pet' container, I still think of myself as ssh'd into the same hostname. In fact, I tend to have pet containers with the exact same name on different computers. So when I'm ssh'd into another machine and inside one of these containers, it's the hostname distinct from the container name that gives me a clue that I'm not on my localhost.

I guess that's a question to really ask yourself. If you name a container distrobox-fedora on computer with hostname laptop.home does that mean you would NOT name an equivalent container also distrobox-fedora on computer with hostname desktop.home? If DNS was setup properly where does ssh distrobox-fedora or http://distrobox-fedora/ go to?

I doubt the usual scenario here is for container names to be network names (and thus hostnames). I think the usual scenario is that container names are NOT network names but people like to see the container name appear in the command line prompt.

from distrobox.

A service on network in the container (be it python server, netcat, nginx etc etc) is available always from the host's hostname anyways

I find myself thinking of my 'pet' containers that share the network with the host as more like chroots which are handling different roles but on the same host (same hostname). So when I ssh to my different computers and enter a 'pet' container, I still think of myself as ssh'd into the same hostname. In fact, I tend to have pet containers with the exact same name on different computers. So when I'm ssh'd into another machine and inside one of these containers, it's the hostname distinct from the container name that gives me a clue that I'm not on my localhost.

That's just preference I think

I guess that's a question to really ask yourself. If you name a container distrobox-fedora on computer with hostname laptop.home does that mean you would NOT name an equivalent container also distrobox-fedora on computer with hostname desktop.home? If DNS was setup properly where does ssh distrobox-fedora or http://distrobox-fedora/ go to?

Well that's something to really define well before starting work on something like that 😄
Probably something like host's hostname + container-name as container's hostname

I doubt the usual scenario here is for container names to be network names (and thus hostnames). I think the usual scenario is that container names are NOT network names but people like to see the container name appear in the command line prompt.

It's not that we like it, it's that it is the most ubiquitous way to show it in the prompt without having to create custom prompts (as each user has it's own I guess)
And having at first glance the ability to know if you're in a container or in the host is really important I think

I agree we could include a --hostname flag so that anyone can customize it, and (for example in your case) you can set it to the host's name itself

Today I learned that podman and docker have a --cidfile option. So that together with -v can be used to set the container name inside the container, either /etc/debian_chroot or some other hopefully-eventually-standard location like perhaps /etc/osvirtalias. Then distros and users can use that file to customize the command prompt as desired. (This is what I'm planning to do castedo/cnest#6)

I'll investigate it, if it's a standard for both, I see no problem including this option by default 👍

from distrobox.

Didn't find anything similar to debian_chroot on other distros without fiddling with either rc files, profiles etc etc

Closing this for now, if there are updates feel free to reopen it or open a new one

from distrobox.

This reminds me, here are three observation that might be of interest.

1. When podman creates a container that is not sharing the network, by default it changes the hostname to the container ID (hexadecimal) and not the container name. This container ID is by default not a valid network destination name in DNS. I'm guessing this is because container names can contain periods and underscores which are not valid characters for the components of a FQDN. It's a bit odd to have \h and socket.getfqdn() etc... returning a component with invalid characters.

2. Looks like there is a way to enable local DNS so that containers names show up as real network destination names. I haven't used it yet or fully understand it yet, but here's more details: https://github.com/containers/dnsname/blob/main/README_PODMAN.md

3. the '\h' in the prompt is only the first part of a FQDN, which there is little reason to expect to be unique. So in my example earlier, of having two containers with the same name but on different physical computers (laptop and desktop), it's really only them having the same FQDN that is strange. Lots of computers have the same '\h' show up. It's the FQDN that is different.

In light of 3) perhaps there is some sense in setting the hostname to something longer, like container-name.thehost-hostname so that /etc/hostname has something slightly more sensible and socket.getfqdn() returns something suggestive of what actually is valid on the network, yet \h will still show only the container name.

from distrobox.

perhaps there is some sense in setting the hostname to something longer, like container-name.thehost-hostname so that /etc/hostname

I like this idea, I'll fiddle with it these days and if all works well with backward compatibility, I'll include this I was thinking to use container-name.container-id but probably container-name.host-hostname it's better Will open a new issue referring this one if all goes well for the implementation +1 thanks a lot

I've started going with this approach too for containers that do not share the network:
https://github.com/castedo/cnest/blob/3b5d92b428611c932d62d710a2312dbfed4457bd/config/profiles/isolated-docker-library#L8

I think I will also try this approach too for containers that do share the network. Although somehow it still feels wrong to me to use the same hostname when they share the network. But I probably just need to get used to this new approach and stop thinking it's wrong.

And I think I will stop using debian_chroot and osvirtalias too if this approach works well.

Thanks for helping us explore and find a smarter solution! 👍

from distrobox.

Thanks to you for the ideas and brainstorming 😄

from distrobox.

Right now distrobox uses the container's name as hostname for the box

Just the container name alone or 'container-name.thehost-hostname'?

from distrobox.

@89luca89 This is what I have been dogfooding for a long time now:

https://github.com/castedo/cnest/blob/beb989f00d5051975b35f98b4709ac255cc21cbd/bin/create-nest#L52-L54

So far it's been working fine for me. But I might just be lucky and not hitting the issue you are hitting.

from distrobox.

@89luca89 This is what I have been dogfooding for a long time now:

https://github.com/castedo/cnest/blob/beb989f00d5051975b35f98b4709ac255cc21cbd/bin/create-nest#L52-L54

So far it's been working fine for me. But I might just be lucky and not hitting the issue you are hitting.

This is also what distrobox is doing now (container_name.host_hostname) but this will give problems for graphical applications, as discussed in this gnome issue: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7531#note_2066704

The WM_CLIENT_MACHINE set on that window does not match your hostname, so the application is considered remote and will not be associated with a local .desktop file.

The only way to fix this is to actually have the same hostname between host and container it seems

from distrobox.

Oh bummer. Us doing 'container_name.host_hostname' is kind of a hack. I'm not surprised it has confused some software somewhere. I've managed to not hit this problem because over the years I've drifted towards only using containers for CLI environments. For the few GUI apps that I use, I rely on existing Flatpacks.

Overall your idea of tweaking the shell prompt to use a $CONTAINER_ID environment variable sounds like a more proper approach than the hack we've been doing.

FWIW, this is the the way I tweak the shell prompt now in case it has useful elements:

• re-usable non-user-specific container image is built to be used to create user-specific local containers
• the 'cnestify' script builds this image (https://github.com/castedo/cnest/blob/main/cnest/cnestify.py)
• one of the 'cnestfy' command line options is to copy files into the '/etc/profile.d/' of the re-usable image
• the default file are https://github.com/castedo/cnest/tree/main/cnest/data/profile.d
• https://github.com/castedo/cnest/tree/main/cnest/data/profile.d will mess with the prompt for whatever ends up being users in the future containers
• the logic in the prompt tweaking script keys off '/etc/nestsign' being present in the image, which is totally a path i made up, not standard at all!
• I think this prompt tweaking script is somewhat distro agnostic, maybe 😬

Some parts of this approach might be useful for your $CONTAINER_ID fix.

from distrobox.

I think it's a great idea to default to same hostname and adjust the shell prompt for disambiguation of context. I use vscode, qtcreator, and a few other gui apps that benefit from shared dev environment in container when using openSUSE Aeon.

I didn't realize this was something you were already doing with the prompt as it doesn't display on my tumbleweed container though. I had to modify the PS1 in .bashrc myself for it to show up. Any ideas where this might be getting overwritten in tumbleweed?

from distrobox.