Open mkuivi opened 1 year ago
Is this breaking something for you? We recently updated the hostname logic to obey Linux rules.
Is this breaking something for you? We recently updated the hostname logic to obey Linux rules.
Yes, I do development and have a lot of apache hosts setup on the on my WSL Ubuntu which depend on the hostname. Now, none of them is working. Everything is breaking. Now, I have to manually force the hostname on the ubuntu to be what I want before some of the applications will work.
If you changing this to follow Linux rules, then how do some of us that depend on this hostname get the same result? Do you have a new setting that can be used to produce the same as before?
If not, need suggestion how to deal with it. Thanks
@mkuivi I think just "hostname" should produce the host part of the FQDN, and "hostname -f" should produce the FQDN.
@mkuivi I think just "hostname" should produce the host part of the FQDN, and "hostname -f" should produce the FQDN.
That is not the issue. For example if you setup your hostname in the /etc/wsl.conf as
[network] hostname=my.host.name.com
and you try access hostname on the command prompt, it will give you my.hostnamecom instead of my.host.name.com
It keeps the first dots and removes the rest of the dots from the hostname
@mkuivi I configured it now like this:
/etc/wsl.conf:
[network]
hostname=hostname-aki
generateHosts=false
/etc/hostname:
hostname-aki
cat /etc/hosts | grep aki # i removed the 127.0.1.1 line. no idea what's that for
127.0.0.1 hostname-aki.non.existing.domain.lan hostname-aki localhost
Reboot (wsl --shutdown) and test (bash):
hostname
hostname-aki
hostname -f
hostname-aki.non.existing.domain.lan
I tested and xorg apps still work.
Yes, I do development and have a lot of apache hosts setup on the on my WSL Ubuntu which depend on the hostname. Now, none of them is working. Everything is breaking.
Aren't you setting the virtual host ServerName?
If you omit the ServerName directive from any name-based virtual host, the server will default to a fully qualified domain name (FQDN) derived from the system hostname. This implicitly set server name can lead to counter-intuitive virtual host matching and is discouraged.
I'm seeing the same thing:
[network]
hostname=host.domain.name.tld
$ dmesg | grep hostname
[ 2.268650] WSL (1) WARNING: hostname set to host.domain.name.tld in /etc/wsl.conf
and yet:
$ hostname -f
host.domaainnametld
this is a regression. please fix asap.
$ man 1 hostname
...
The recommended method of setting the FQDN
is to make the hostname be an alias for the
fully qualified name using /etc/hosts, DNS,
or NIS. For example, if the hostname was
"ursula", one might have a line in
/etc/hosts which reads
127.0.1.1 ursula.example.com ursula
...
By following this config, both hostname and hostname -f return the expected values.
Edit: together with WSL config from https://github.com/microsoft/WSL/issues/9897#issuecomment-1499095770
@aki-k this doesn't work. I need hostname
to return the fqdn.
wsl is broken.
it worked fine before.
this is a REGRESSION.
further evidence of brokenness:
$ sysctl kernel.hostname
kernel.hostname = host.domaainnametld
$ sysctl kernel.domainname
kernel.domainname =
go on. tell me kernel.domainname
exists for no reason.
$ sysctl kernel.domainname kernel.domainname = go on. tell me
kernel.domainname
exists for no reason.
I don't know about that sysfs entry, but on my host that I configured like above, I see this:
$ dnsdomainname
redacted.fi
I haven't configured redacted.fi anywhere else than to /etc/hosts on that localhost line that now has:
127.0.0.1 hostname.redacted.fi hostname localhost
let me guess, you're using a debian-derived distro?
It's Fedora 36
ugh. it seems systemd has truly infected everything.
I have the same problem... I need to set the hostname that includes my organization domain for some names resolutions to work. It was working fine a few days ago so in my wsl.conf i set hostname = "myname.orgname.com" but hostoname displays myname.orgnamecom
The last dot is removed.
@frabul Configure it like this: https://github.com/microsoft/WSL/issues/9897#issuecomment-1499095770 so all three commands hostname, hostname -f and dnsdomainname work properly.
Edit: the added benefit from this is that pinging hostname-aki. (with a dot at end) pings the Windows host side "Ethernet adapter vEthernet (WSL)" (it can be because my Windows hostname is also hostname-aki).
Is this breaking something for you? We recently updated the hostname logic to obey Linux rules.
When the second dot is dropped on my system (i.e., subdomain.domain.tld becomes subdomain.domaintld) sudo gives an error message:
sudo: unable to resolve host subdomain.domaintld: Name or service not known
I've got various Ubuntu and RaspberryPiOS boxes all over the place and none of them do this, just WSL 2 under Windows 11.
I tried putting two dots in /etc/wsl.conf: subdomain.domain..tld, but that had no effect. Every time I restart WSL 2, the contents of /etc/hostname become subdomain.domaintld, even after removing all write privileges from that file.
Please fix this regression.
Arbitrarily stripping the dots out of what the user explicitly supplied in their manually written configuration file makes no sense whatsoever.
Unfortunately, there is a lack of standardization between Linux distributions about whether to set the kernel hostname to the short or fully-qualified domain name. Some distros lean one way, some the other. So sometimes you encounter software expecting the kernel hostname to be a FQDN. Right now, WSL is performing a bizarre textual transformation on what the user specifies - just trust the user editing wsl.conf to know their own requirements.
@maxb Configure it like this: https://github.com/microsoft/WSL/issues/9897#issuecomment-1499095770 so all three commands hostname, hostname -f and dnsdomainname work properly.
Use the short hostname in /etc/wsl.conf
@aki-k No, that fails to achieve what I need. As I said:
Unfortunately, there is a lack of standardization between Linux distributions about whether to set the kernel hostname to the short or fully-qualified domain name. Some distros lean one way, some the other. So sometimes you encounter software expecting the kernel hostname to be a FQDN.
i.e. I am aiming for the kernel hostname itself to be set to a FQDN
I just want WSL to do what I told it to do, without textual mangling.
@maxb You have some process/service that requires that?
Yes
@maxb What process/service you're running requires you to have the FQDN in /proc/sys/kernel/hostname ?
Some proprietary software that expects that because it was written for Linux distros such as Red Hat where that is the standard out of the box configuration.
@maxb What's the error from the software that you get if the FQDN is not in /proc/sys/kernel/hostname ?
No specific error. Complex malfunctions because the result of reading the kernel hostname does not map to an expected Kerberos domain.
However this is NOT THE POINT. The issue is not the specific software I happen to be using right now. The issue is that WSL is performing illogical undocumented textual transformations upon user input in configuration files, and should cease doing that.
@maxb I can only describe what the man page for this says:
$ man 1 hostname
The recommended method of setting the FQDN is to make the hostname be an alias for
the fully qualified name using /etc/hosts, DNS, or NIS. For example, if the host‐
name was "ursula", one might have a line in /etc/hosts which reads
127.0.1.1 ursula.example.com ursula
The DNS domain name is the part after the first dot.
The man page in that means the hostname (ursula) is the part before the DNS domain name (example.com). And then the FQDN is ursula.example.com.
The recommended method in the particular man page you have chosen to quote is quite irrelevant.
Major distributions do it both ways, and regardless, WSL should not be arbitrarily mangling input strings.
@maxb Well I think this is the first time I hear someone say a man page is irrelevant.
man pages are not standard across distributions. You are trying to use a version that suits your personal preferences to justify something I have already explained differs between major distributions.
@maxb What does your distro's "man 1 hostname" say about it?
Huh... it turns out the man page on CentOS fails to document the common practice on CentOS.
Anyway, have a read of https://serverfault.com/questions/331936/setting-the-hostname-fqdn-or-short-name which shows widespread difference of opinion on this point.
However, again, this really is not getting to the core of the issue here:
There are plenty of people who think the kernel hostname should be the short name. There are plenty of people who think the kernel hostname should be the FQDN.
WSL should avoid choosing a side in this difference of opinion, in order to be useful to people in both camps, and should definitely not arbitrarily delete dots from what the user specified:
If the user specifies ursula.example.com
, then making up the hostname ursula.examplecom
is definitely wrong, because the examplecom
DNS label is a nonsense invention.
Rocky Linux 9 (RHEL 9) "man 1 hostname" includes the same text I pasted above:
The recommended method of setting the FQDN is to make the hostname
be an alias for the fully qualified name using /etc/hosts, DNS, or NIS.
For example, if the hostname was "ursula", one might have a line in /etc/hosts which reads
127.0.1.1 ursula.example.com ursula
Technically: The FQDN is the name getaddrinfo(3) returns for the host name returned
by gethostname(2). The DNS domain name is the part after the first dot.
https://github.com/microsoft/WSL/issues/9897#issuecomment-1499095770 is a workaround.
i would expect setting a fqdn hostname in /etc/wsl.conf
would result in the proper hosts file to be generated on startup. as it is, you are forced to manage the hosts file yourself in order to fix improper hostname parsing.
Similar problem. Why hasn't this been fixed yet? Why is it done so that the point is deleted?
@KoRn0509 Use the short hostname in /etc/wsl.conf.
/etc/wsl.conf:
[network]
hostname=hostname-aki
generateHosts=false
/etc/hostname:
hostname-aki
/etc/hosts:
127.0.1.1 hostname-aki.non.existing.domain.lan hostname-aki
Reboot (wsl --shutdown) and test:
$ hostname
hostname-aki
$ hostname -f
hostname-aki.non.existing.domain.lan
$ dnsdomainname
non.existing.domain.lan
@aki-k This does not work. I want to set up the iRedmail mail server for testing. To install it, you need to set the FQDN mail.mydomain.com How can i do this?
@KoRn0509 Did you try using the FQDN with iRedmail after configuring the hostname like I described above?
@KoRn0509 Use the short hostname in /etc/wsl.conf.
/etc/wsl.conf:
[network] hostname=hostname-aki generateHosts=false
/etc/hostname:
hostname-aki
/etc/hosts:
127.0.1.1 hostname-aki.non.existing.domain.lan hostname-aki
Reboot (wsl --shutdown) and test:
$ hostname hostname-aki $ hostname -f hostname-aki.non.existing.domain.lan $ dnsdomainname non.existing.domain.lan
This does indeed work for me and has survived across multiple reboots. I don't know why it's different in WSL compared to Ubuntu and Raspberry Pi OS, but thank you for providing what most of us likely will refer to as a workaround.
@atrocity2001 I'm not sure why you think this method is only for WSL 2?
$ man hostname
The recommended method of setting the FQDN is to make the hostname be an alias for the fully qualified name using /etc/hosts, DNS, or NIS. For example, if the hostname was "ursula", one might have a line in /etc/hosts which reads
127.0.1.1 ursula.example.com ursula
@atrocity2001 I'm not sure why you think this method is only for WSL 2?
$ man hostname
The recommended method of setting the FQDN is to make the hostname be an alias for the fully qualified name using /etc/hosts, DNS, or NIS. For example, if the hostname was "ursula", one might have a line in /etc/hosts which reads
127.0.1.1 ursula.example.com ursula
I've simply never had to do that on any Ubuntu or Raspberry Pi OS I've run. And I've run Ubuntu for years. So it may technically be correct, but what's confusing to me and others in this thread is that WSL2, allegedly running Ubuntu, strictly enforces that convention while vanilla Ubuntu does not.
And I also assume it's a change, because I certainly didn't know enough to set up my own host/hostname file 15+ years ago, so I just modified what was already there by default. As others here have indicated, WSL2 itself didn't used to demand that, though I have only started using it recently and can't speak to that from personal experience.
I agree with the OP.
The reason hostname is set to the FQDN is to ensure a device is reported correctly to external systems. A hostname can be duplicated across domains on separate devices or on the same device where its multihomed.
There are many products that run both locally and externally that rely on the hostname reported by the OS to be an FQDN, to prevent ambiguity and confusion. This includes Red Hat Satellite, which presents devices based on the output of 'hostname'. If the 1000's of devices reported the short hostname, how would I differentiate between host1.customer1.com and host1.customer2.com?
The standard practice is to set the hostname to the FQDN so that the lowest common denominator method, across all Linux distros and versions can be used to discover a clients hostname reliably and consistently.
The kernel reporting a short name cannot be guaranteed as unique to an environment and then relies on a default domain, so what happens when the same hostname exists across multiple domains? How do systems that only know the host as "ursula" differentiate between "ursula.default-domain.com" and "ursula.corporate-domain.com" or ursula.customer1.com and ursula.customer2.com etc.
But if WSL is only for the home hobbyist, fine.
@sedstr
The reason hostname is set to the FQDN is to ensure a device is reported correctly to external systems.
This is false.
Please show the output from these three commands:
hostname hostname -f dnsdomainname
This is not a theocratic discussion. My statements are valid and true. The hostname commands output is the result of the administrator's decision, it's as simple as that.
Every Linux and Unix OS has honored setting the hostname to the FQDN. WSL also honored this in previous iterations but has changed. This thread is a discussion about why the historical behavior should be maintained, not what is true, false, right or wrong.
I would much rather WSL produce predictable and consistent results, and considering this behavior was introduced after working as expected since the first release, a reasonable outcome would be to revert the change or add an equivalent option to the wsl.conf to ensure that hostnames are reported as the desires. Not based on what seems to be a zealous demand for compliance.
@sedstr So you're embarrassed to show the output of those commands because it would show your system is not configured right.
@aki-k - you seem to be having difficulty comprehending. I'm simply stating facts while you seem to be preaching like this is some kind of religion. You need to pull your head in and grow up.
@sedstr It's not a shame to admit you don't know everything. We all learn something every day. It only becomes a problem if your refuse to accept information from somebody who knows more than you.
Windows Version
10.0.19043.2364
WSL Version
1.1.6
Are you using WSL 1 or WSL 2?
Kernel Version
5.15.79.1
Distro Version
Ubuntu-20.04
Other Software
No response
Repro Steps
WSL2 started changing my hostname defined in /etc/wsl.conf file.
[network] hostname=name.someName.OtherSection.Domain
now results in the dots in the hostname removed:
$ hostname name.someNameOtherSectionDomain
This started about a months now. I searched the web but no luck.
Any help on how to get the hostname working correctly as defined in the wsl.conf file will be great.
Expected Behavior
hostname should display the name defined in the /etc/wsl.conf file
Actual Behavior
wsl removes dots from the hostname defined in the /ect/wsl.conf file
Diagnostic Logs
No response