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

Option to prevent automatic update of /etc/hostname #4305

Closed
cerebrate opened this issue Jul 15, 2019 · 21 comments
Closed

Option to prevent automatic update of /etc/hostname #4305

cerebrate opened this issue Jul 15, 2019 · 21 comments
Labels

Comments

@cerebrate
Copy link

Please fill out the below information:

  • Your Windows build number: 18936

As a feature request, could we have an additional option in wsl.conf, similar to the existing

generateHosts = false

to prevent WSL from overwriting the /etc/hostname file with the Windows hostname on startup?

Background:

Since the WSL 2 lightweight VM uses a separate network interface and hence IP address from the Windows host, that they share a hostname creates various unexpected interactions when trying to communicate between them.

I work around this with a small systemd service which renames the host with a '-wsl' suffix and updates the nameserver when it starts up (see https://github.com/cerebrate/wsl-ip ), but renaming the WSL host on every startup is a rather an ugly kluge and doesn't help people who aren't using baroque systemd-enabling techniques.

@benhillis
Copy link
Member

Seems like a reasonable request, however more is involved with the hostname than just the /etc/hostname file. We also call sethostname to update the kernel state. What might make more sense is the ability to override the host name with a string. @cerebrate - Does that sound ok to you? Do you have any issues with still setting the domainname setdomainname and also in /etc/hosts.

@cerebrate
Copy link
Author

Ah, yeah, init would have to do that, wouldn't it?

Overriding it with a string in wsl.conf would be a much better option for me, then, yes. That'd clear all this up nicely.

@benhillis
Copy link
Member

Cool, I see this as a useful addition to wsl.conf anyway and it will be very straightforward to do. Thanks for the suggestion.

@benhillis
Copy link
Member

Thinking about this a bit more, it probably makes sense for this to be in a config file with other options that modify VM-level settings. A config file like this exists, but the functionality is not present in the Insider build (yet).

Either that, or each distro should be launched in a UTS namespace. What are your throughts @cerebrate?

@cerebrate
Copy link
Author

cerebrate commented Jul 15, 2019

Hm. Well, I think the setting probably needs to be per-distro (I'm presuming the VM-level config file wouldn't be?). With multiple distros running in multiple VM instances, they're going to have discrete IP addresses, etc., and I'd expect multiple-distro users to want to distinguish them from each other hostname-wise for essentially the same reasons.

@benhillis
Copy link
Member

Distros all run in the same VM in the same Network namespace.

@cerebrate
Copy link
Author

Oops. (I confess virtually all of my use has been one distro at a time, so I haven't looked into that as thoroughly as I might have.)

That being the case, I have no problem with it being with the other VM-level settings.

@therealkenc
Copy link
Collaborator

therealkenc commented Jul 16, 2019

A config file like this exists, but the functionality is not present in the Insider build (yet).

Other stuff too. Ref #4232, which I realized right after I posted over there few weeks back that sysctl.conf(5) is problematic, nevermind hostname(5).

Either that, or each distro should be launched in a UTS namespace. What are your throughts @cerebrate?

A UTS namespace and a NET namespace with veth(4) and SimpleBridge. Probably also the new 4.6 cgroup namespace too if each systemd wants to believe it is the boot init, contrast a container systemd as with systemd-nspawn, LXC, Docker, and the rest which adhere to systemd's Container Interface.

Long story short, if this could be done with a one liner they wouldn't hold conventions on the topic.

To the specific ask:

but renaming the WSL host on every startup is a rather an ugly kluge

The standard approach taken by systemd-nspawn etc is to bind mount over /etc/hostname, not rename it. It isn't a kludge. It's a necessity, because the hostname is established before systemd starts not after, and it is systemd's responsibility to call sethostname(2). That's the purpose of this line in wsltub from last spring.

@benhillis
Copy link
Member

I'm still on the fence if we want a separate network namespace. Our eventual goal is to be more similar to the WSL 1 model where the IP address is the same as Windows.

@therealkenc
Copy link
Collaborator

Right; I think I mushed together some context above. Perfectly okay if 'WSL' (ambiguity quotes) wants to lean toward a one-user-one-distro-one-network kind of model, dare I say like Cygwin, that is running as a equal peer beside Windows.

The answer I gave about NET namespace with veth and the works was in the context of folks wanting to run systemd, with it's whole suite of daemons, let's say smbd or sshd, or let's go crazy dhcpd, that cannot by definition play nice with Windows trying to do the same thing in the same namespace. Or consider killer app BitTorrent Skype, which has to punch NAT holes.

If you've got the same localhost then the whole question in this thread collapses because you wouldn't need to muck /etc/hostname (the UTS namespace) in the first place. Nothing wrong with that either (simple=good). I was answering in the context of the question.

@cerebrate
Copy link
Author

Speaking only for myself on the general questions:

My concern with systemd, etc., has very little to do with those assorted network daemons, and a lot more to do with the increasing number of tools (snappy being the most immediately obvious) that have taken hard dependencies on systemd, and to a lesser extent with those which require hacky workarounds if it's not there, and to an even lesser extent with not having to fill my .profile with a bunch of manually maintained service-starting clauses.

So for myself, while I appreciate the elegance of sharing the same network namespace as the Windows host, I'd trade that away in a second for those three things, especially the first, but by no means ignoring the reduction in admin overhead from the second and third.

(If I were to construct a hypothetical WSL architecture just for me and my preferences, I'd launch each distro in its own UTS, network, cgroup, pid, etc., namespace with its native init as pid 1, as the easiest way to get to where I want to be, but I do realize that y'all have to cater to the preferences of everyone else, too. :) )

@cerebrate
Copy link
Author

(I should also probably have been more clear: while doing the bind mount, etc., is fine for genie/systemd users, especially since it conveniently affects processes running outside the bottle also when a UTS namespace isn't used, I was thinking of the manual renaming is an ugly kluge for those who aren't going that route.)

@therealkenc
Copy link
Collaborator

therealkenc commented Jul 17, 2019

My concern with systemd, etc., has very little to do with those assorted network daemons

Fair enough. But you could, in the hypothetical, kinda care, at least a little. See 'cause a functioning suite of those esoteric networking daemons would obviate the need for updatewslip, which you cared about enough to create. I mean, how else are your Genie users gonna get a zeroconf debian.wsl.local name, and also deal with those users firing up their VPN tunnel, which swaps their upstream DNS (long after after your updatewslip script has run), in order to download Game of Thrones a Linux .iso image with bittorrent? Amirite?

Which is supposed to be a deliberately comedic scenario. Except for the fact there's an open github ticket for every step in that last sentence.

[Reminds me. Those dots in the Store distro names (f.e. Ubuntu-18.04) need to go.]

Point taken though. If snapd is your itch, it is yours to scratch. Beauty of putting code where your mouth is. 🏆

@cerebrate
Copy link
Author

cerebrate commented Jul 28, 2019

As a side-note, in the course of futzing around with trying to find a workaround for the network issues mentioned in #4342 , I can now confirm that systemd-networkd and systemd-resolved do indeed work under WSL 2.

(The former isn't any use for network configuration unless you hack your WSL virtual switch to be an external/bridged network instead of the WSL NAT, and the latter requires DNS configuration in /etc/systemd/resolved.conf because - without the former hacking - it won't get any from the former, but nonetheless, they do function.)

@BatmanAoD
Copy link

I would also be interested in a simple way for WSL2 to have a different hostname.

@Biswa96
Copy link

Biswa96 commented Aug 26, 2020

Build 20180 or greater has this feature. Add the following two lines in that /etc/wsl.conf file.

[network]
hostname = HelloWorld

This option is distro specific. So one need to add the file for each distro. init binary uses sethostname(2) before initializing an instance. You can do this to find if your init binary has this feature.

$ readelf -p 1 /init | grep -i "network\."
  [   e18]  network.generateResolvConf
  [  654e]  network.hostname
  [  69ca]  network.generateHosts

@WSLUser
Copy link

WSLUser commented Aug 26, 2020

Does WSL1 also get this feature? I would assume any changes made to /etc/wsl.conf would need to work with both.

@Biswa96
Copy link

Biswa96 commented Aug 26, 2020

Yes it also works with WSL1.

@stevebovy
Copy link

stevebovy commented Sep 7, 2020

Thanks for the feature ! And thanks to everyone for the interesting read in this thread.

Does this mean I can use the following to successfully access my windows VcXsrv ??

export DISPLAY=$HOSTNAME:0

Instead Of A FULLY QUALIFIED HOST-DOMAIN NAME Like This ::: DISPLAY=$HOSTNAME.$WIN-DOMAIN:0

@Biswa96
Copy link

Biswa96 commented Sep 7, 2020

Yes $HOSTNAME is set to according to the value provided in hostname field as I said above. Make sure you are using latest Windows insider build.

@mforkel
Copy link

mforkel commented Sep 27, 2020

Build 20180 or greater has this feature

Setting the host name in /etc/wsl.conf works for me in Windows 10 Version 1909 Build 18363.1082.

$ readelf -p 1 /init | grep -i "network\."
  [   cbb]  network.generateResolvConf
  [  60a3]  network.hostname
  [  6479]  network.generateHosts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants