Don't set entire FQDN hostname to just container name

[castedo]

Below is more or less the same issue I describe in 89luca89/distrobox#62

Describe the bug
The container created by toolbx is setting the hostname in the container to toolbox. For example /etc/hostname is a value that is not actually the DNS name of any host on any network. See man hostname for all the assumptions made about and effects of setting /etc/hostname.

Expected behaviour
The FQDN hostname in the container should contain the FQDN of the host be the same hostname as the host because they are sharing the network .

In light of the resolution of 89luca89/distrobox#62, I'm striking out the suggestions I made initially. A summary conclusion is below at #969 (comment).

On Debian there is a precedence for indicating the chroot in the command line prompt (chroot being a precursor to containers). To my knowledge there isn't an equivalent on Fedora based distros. Not knowing of an alternative I started using osvirtalias in cnest.

I describe the situation in more detail here:
https://github.com/castedo/cnest/tree/master/prompt

So I can suggest doing similarly and set osvirtalias and/or debian_chroot to be the name of the container, and let the distro and container configuration determine the command line prompts however they are supposed to. And do this without incorrectly repurposing the hostname for a purpose other than what hostname is supposed to mean.

If you come across an alternative to osvirtalias please let me know. I don't want to start a precedent that is non-standard, but I do want to start a precedent other than debian_chroot. If it catches on, Debian distros probably want to use a name without chroot in it anyway.

[castedo]

Here's an example of how any application that actually wants to programmatically get the real hostname or FQDN will not actually get the real hostname or FQDN when run inside a toolbox container. Python example:

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

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...

[castedo]

FYI update on what Luca (distrobox) and I (cnest) decided makes sense in 89luca89/distrobox#62

We both currently think that an approach that makes a lot of sense is to set the hostname of the container to container-name.host-hostname. This results in a \h in the command line prompt that is just container-name but an FQDN (e.g. result of socket.getfqdn()) which is suggestive of a network destination that actually will work (i.e. drop the first component of the FQDN). To me it makes sense that say ftp.srvr.foo.net might likely be the same computer as srvr.foo.net. If the first FQDN didn't resolve in DNS then it's natural to guess the second one might resolve.

It also has the nice property that FQDN hostname is different across different machines on the network even if they share the same container name. So two containers both named pet on a laptop and desktop might show the same \h in the command line prompt, but the hostname command and socket.getfqdn() will return different FQDNs.

[debarshiray]

FYI update on what Luca (distrobox) and I (cnest) decided makes sense in 89luca89/distrobox#62

I haven't spent too much time thinking about this, but this does sound like a sensible default to me.

One problem with setting the host name through podman create --host ..., like we do today, is that any attempt to change the hostname later doesn't persist across a container restart. This seems somewhat important because another big reason to want to change the container's host name is to uniquely identify them.

Of course, users can hack this up using their shell start-up scripts, but it will be good to come up with a less barbaric solution. :)

[castedo]

any attempt to change the hostname later doesn't persist across a container restart. This seems somewhat important because another big reason to want to change the container's host name is to uniquely identify them.

Yeah, I can see this as an issue if a default container name/hostname is automatically assigned. IIRC, this is what toolbox does.

That said, in my own workflow (using https://cnest.readthedocs.io), I never end up wanting to change nest container names after they are created. Nor would I want to. They have names like pub-12 and pub-13. cnest will automatically guess the latest number after the dash so I only need to type cnest pub for example to enter container pub-13 rather than pub-12. These nest containers are short-lived compared to the typical toolbox workflow I think.

I create nest container images from a Dockerfile using cnestify, so deleting an old container and starting a new clean container with all the software I specified in a Docker file for a nest image (e.g. the pub image) is something I do on a regular basis.

[debarshiray]

Often the desire for a better hostname is conflated with the desire for better ways to visually distinguish between Toolbx containers. This issue and comments like #771 (comment) and #98 (comment) show why they aren't the same thing.

Let's use this issue to improve the default hostname for Toolbx containers, and let's use #98 for better ways to visually distinguish between containers.

[jkemp814]

#98 (comment)