Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hostname changing causes unexpected issues. #1528

Open
pemensik opened this issue Aug 27, 2024 · 3 comments
Open

Hostname changing causes unexpected issues. #1528

pemensik opened this issue Aug 27, 2024 · 3 comments
Labels
1. Bug Something isn't working

Comments

@pemensik
Copy link

Describe the bug
Toolbox fails to resolve names together with systemd-resolved. Filled systemd issue systemd/systemd#33870, but systemd maintainers think hostname should not be changed. And that it is failure of toolbox to change system identification, but not fully.

Initially reported at bug https://bugzilla.redhat.com/show_bug.cgi?id=2291062

Is the changing of hostname good idea, when variable $HOSTNAME stays unmodified? Is there specific reason, why it is implemented the current way? Would not some shell variable work better maybe just overriding PS1 prompt?

Steps how to reproduce the behaviour

  1. Have Fedora 40
  2. Spawn Fedora 40 toolbox by toolbox enter.
  3. Have dns-suffix on your connection (lan for example).
  4. Try to resolve toolbox.lan, where toolbox is what $(hostname) command returns.

Expected behaviour
It should resolve fast and clean. It should not fail to take a long to resolve.

Actual behaviour
Under specific conditions, because NSS plugin resolve is ordered before myhostname plugin, it may take quite a long time. That is because unlike myhostname plugin, systemd-resolved.service does not understand that toolbox.$SUFFIX is its own hostname. Tries it to find on the network and may fail when doing that.

Screenshots
None, see https://bugzilla.redhat.com/show_bug.cgi?id=2291062

Output of toolbox --version (v0.0.90+)
0.0.99.5

Toolbx package info (rpm -q toolbox)
toolbox-0.0.99.5-11.fc40.x86_64

Output of podman version

# podman version
Client:       Podman Engine
Version:      5.2.1
API Version:  5.2.1
Go Version:   go1.22.5
Built:        Tue Aug 13 20:00:00 2024
OS/Arch:      linux/amd64

Podman package info (rpm -q podman)
podman-5.2.1-1.fc40.x86_64

Info about your OS
Fedora 40

Additional context

This happens because some black magic is specially applied on $HOSTNAME queries. But because toolbox uses different hostname, it does not recognize it as own name at systemd-resolved and resolves it like any other name. On certainly broken networks that may take exceptionally long time.

This happens on Fedora 40, where just toolbox enter is used and systemd-resolved is enabled by default.

# grep hosts /etc/nsswitch.conf 
hosts:      files resolve [!UNAVAIL=return] myhostname dns
@pemensik pemensik added the 1. Bug Something isn't working label Aug 27, 2024
@mcatanzaro
Copy link

Why does toolbox change the hostname?

@pemensik
Copy link
Author

I expect just to make easier identification of toolbox shell, that you are inside the toolbox. But that is just my guess, which might be wrong. Hostname is displayed by shell of any distribution by PS1 variable. But I guess the question might be more for local maintainers, who might not only guess.

@pemensik
Copy link
Author

There seems to be also issue with X11 forwarding, issue #1343. Which misbehaves because changed hostname.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1. Bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants