Closed cerebrate closed 4 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.
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.
Cool, I see this as a useful addition to wsl.conf anyway and it will be very straightforward to do. Thanks for the suggestion.
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?
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.
Distros all run in the same VM in the same Network namespace.
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.
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.
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.
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.
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. :) )
(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.)
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. 🏆
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.)
I would also be interested in a simple way for WSL2 to have a different hostname.
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
Does WSL1 also get this feature? I would assume any changes made to /etc/wsl.conf
would need to work with both.
Yes it also works with WSL1.
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
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.
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
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.