microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.46k stars 822 forks source link

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

Closed cerebrate closed 4 years ago

cerebrate commented 5 years ago

Please fill out the below information:

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

cerebrate commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

(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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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

Biswa96 commented 4 years ago

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 commented 4 years ago

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

Biswa96 commented 4 years ago

Yes it also works with WSL1.

stevebovy commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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