It looks like the hostname is set in /etc/profile to uname -n, which means every instance I spin up thinks its hostname is "fedora." I don't want that. I want each hostname to set its hostname to whatever its DNS name is.
We used to set the hostname in /etc/hostname to localhost.localdomain, and that would be substituted to whatever the DNS hostname associated with the system's IP address was, but that doesn't seem to work any more.
What is the preferred way of having Fedora 35 server instances use the host's hostname from DNS? I notice that if I restart NetworkManager.service, then the reverse DNS hostname is set - hostname gives me host123.mydomain.com. I want to make it happen at boot. It's weird.
Thomas
Am 16.01.2022 um 21:31 schrieb Thomas Cameron thomas.cameron@camerontech.com:
... What is the preferred way of having Fedora 35 server instances use the host's hostname from DNS? I notice that if I restart NetworkManager.service, then the reverse DNS hostname is set - hostname gives me host123.mydomain.com. I want to make it happen at boot. It's weird.
Do you want to set the hostname at every boot?
Usually you set the static hostname once using "hostnamectl set-hostname <FQDN>“. „fedora“ is the transient hostname. DHCP client uses the static hostname to request an IP.
But maybe I didn't get what exactly you want to do.
On 1/16/22 15:00, Peter Boy wrote:
Do you want to set the hostname at every boot?
Usually you set the static hostname once using "hostnamectl set-hostname <FQDN>“. „fedora“ is the transient hostname. DHCP client uses the static hostname to request an IP.
But maybe I didn't get what exactly you want to do.
I have DNS set up such that every host that gets a dynamic address gets the hostname hostXXX.tc.camerontech.com, like this:
172.31.100.100 host100.tc.camerontech.com 172.31.100.101 host101.tc.camerontech.com 172.31.100.102 host102.tc.camerontech.com 172.31.100.103 host103.tc.camerontech.com
and so on. For RHEL 6, 7, 8, and 9 beta, along with the last MANY versions of Fedora, when a new virtual machine boots up using KVM virtualization, the system hostname is set to whatever the reverse IP address of the instance. So if the VM gets 172.31.100.150, the hostname is set to host150.tc.camerontech.com. It's worked this way for years and years.
All of a sudden with F35, no matter what the address of the VM is, its hostname is set to fedora. Just fedora. Not fedora.tc.camerontech.com.
I want F35 to have the same behavior as previous versions of Fedora and RHEL and Ubuntu and so on. I don't want to manually set /etc/hostname and monkey with hostnamectl because if the VM gets a new address, I don't want to have to go and change /etc/hostname or anything.
I've been poking around with /etc/NetworkManager/NetworkManager.conf - it seems like I should be able to set :
[main]
#plugins=keyfile,ifcfg-rh hostname-mode=default
but that doesn't work. When I first ssh into the VM, the hostname is set to "fedora" again. If I restart NetworkManager.service, THEN the hostname is changed to whatever the reverse DNS name is.
I have a few setup scripts which really need an accurate hostname value set, so this is really frustrating.
Make sense?
Thomas
On Sun, 2022-01-16 at 15:53 -0600, Thomas Cameron wrote:
All of a sudden with F35, no matter what the address of the VM is, its hostname is set to fedora. Just fedora. Not fedora.tc.camerontech.com.
I see your pain, that doesn't really work well when you have several Fedora PCs, does it? (I'm Spartacus, and I'm Spartacus, too.)
My quirky humour would have put into the install routine a "name your computer" question. And if you didn't, it'd randomly pick a name from a list to each computer (George, Fred, Jenny, etc) for you.
I want F35 to have the same behavior as previous versions of Fedora and RHEL and Ubuntu and so on. I don't want to manually set /etc/hostname and monkey with hostnamectl because if the VM gets a new address, I don't want to have to go and change /etc/hostname or anything.
I've been poking around with /etc/NetworkManager/NetworkManager.conf
What about customising the dhcp client config? So it accepts the hostname name supplied from your DHCP server, or derived from your reverse DNS lookup, and passes it to whatever is setting the hostname on Fedora these days.
Like you, that's what I expect to happen, *unless* the user specifies otherwise.
On 1/16/22 22:40, Tim via users wrote:
On Sun, 2022-01-16 at 15:53 -0600, Thomas Cameron wrote:
All of a sudden with F35, no matter what the address of the VM is, its hostname is set to fedora. Just fedora. Not fedora.tc.camerontech.com.
I see your pain, that doesn't really work well when you have several Fedora PCs, does it? (I'm Spartacus, and I'm Spartacus, too.)
My quirky humour would have put into the install routine a "name your computer" question. And if you didn't, it'd randomly pick a name from a list to each computer (George, Fred, Jenny, etc) for you.
I want F35 to have the same behavior as previous versions of Fedora and RHEL and Ubuntu and so on. I don't want to manually set /etc/hostname and monkey with hostnamectl because if the VM gets a new address, I don't want to have to go and change /etc/hostname or anything.
I've been poking around with /etc/NetworkManager/NetworkManager.conf
What about customising the dhcp client config? So it accepts the hostname name supplied from your DHCP server, or derived from your reverse DNS lookup, and passes it to whatever is setting the hostname on Fedora these days.
Like you, that's what I expect to happen, *unless* the user specifies otherwise.
That's the thing, I am not even sure what I'd do on the client side.
As a dirty hack, I created a file /etc/profile.d/hostname.sh:
MYIP=`hostname -I` MYHOSTNAME=`host $MYIP | awk '{ print $NF }' | sed "s/.$//"` echo $MYHOSTNAME > /etc/hostname hostnamectl hostname $MYHOSTNAME
That sets the hostname correctly but it's a *dirty* hack in that it requires someone to actually log in to run the trigger the profile.d stuff. I am trying to find where in the dhclient stuff I should work to have the hostname set correctly from dhcp/dns resolution. It's frustrating that with F34 and F35, the systemd-hostnamed.service is supposed to do this but I'm not seeing where to make it do what I want it to. I've played with the /etc/NetworkManager/NetworkManager.conf file setting the hostname-mode=default in [main] but it's not working.
Thomas
On Sun, 2022-01-16 at 23:25 -0600, Thomas Cameron wrote:
As a dirty hack, I created a file /etc/profile.d/hostname.sh: MYIP=`hostname -I` MYHOSTNAME=`host $MYIP | awk '{ print $NF }' | sed "s/.$//"` echo $MYHOSTNAME > /etc/hostname hostnamectl hostname $MYHOSTNAME That sets the hostname correctly but it's a dirty hack in that it requires someone to actually log in to run the trigger the profile.d stuff. I am trying to find where in the dhclient stuff I should work to have the hostname set correctly from dhcp/dns resolution. It's frustrating that with F34 and F35, the systemd-hostnamed.service is supposed to do this but I'm not seeing where to make it do what I want it to. I've played with the /etc/NetworkManager/NetworkManager.conf file setting the hostname- mode=default in [main] but it's not working.
Any useful clues from these pages: https://forum.manjaro.org/t/how-to-set-the-hostname-assigned-by-dhcp-server/... https://www.linuxsecrets.com/1675-configure-linux-to-broadcast-dhcp-client-h... https://askubuntu.com/questions/104918/how-to-get-the-hostname-from-a-dhcp-s... https://www.google.com/search?q=fedora+dhcp+client+accepting+hostname+from+s...
What we've been discussing is something I've often meant to get around to doing, myself. But I just persevere with manually adjusting a few things, here. I only have a small network, so it hasn't bugged me sufficiently, yet. And my brain is going on strike, at the moment (migraine brain fog). But the first link I supplied suggested simply delete /etc/hostname
On 1/17/22 05:40, Tim via users wrote:
On Sun, 2022-01-16 at 15:53 -0600, Thomas Cameron wrote:
All of a sudden with F35, no matter what the address of the VM is, its hostname is set to fedora. Just fedora. Not fedora.tc.camerontech.com.
I see your pain, that doesn't really work well when you have several Fedora PCs, does it? (I'm Spartacus, and I'm Spartacus, too.)
My quirky humour would have put into the install routine a "name your computer" question. And if you didn't, it'd randomly pick a name from a list to each computer (George, Fred, Jenny, etc) for you.
I want F35 to have the same behavior as previous versions of Fedora and RHEL and Ubuntu and so on. I don't want to manually set /etc/hostname and monkey with hostnamectl because if the VM gets a new address, I don't want to have to go and change /etc/hostname or anything.
I've been poking around with /etc/NetworkManager/NetworkManager.conf
What about customising the dhcp client config? So it accepts the hostname name supplied from your DHCP server, or derived from your reverse DNS lookup, and passes it to whatever is setting the hostname on Fedora these days.
Like you, that's what I expect to happen, *unless* the user specifies otherwise.
dhcp server of libvirt is dnsmasq. It would provide hostnames when it has matching dhcp-record with IP and name (and hwaddr). With libvirt, that would be set by <ip><dhcp><host name='whatever'> in network configuration xml. I think it should use also /etc/hosts of the host. But dnsmasq can assign lease just by name if hwaddr is not present in static leases. But that requires static hostname on Fedora side to be sent to the server.
How does virsh net-dumpxml <network> look like?
On 1/18/22 04:10, Petr Menšík wrote:
dhcp server of libvirt is dnsmasq. It would provide hostnames when it has matching dhcp-record with IP and name (and hwaddr). With libvirt, that would be set by <ip><dhcp><host name='whatever'> in network configuration xml. I think it should use also /etc/hosts of the host. But dnsmasq can assign lease just by name if hwaddr is not present in static leases. But that requires static hostname on Fedora side to be sent to the server.
How does virsh net-dumpxml <network> look like?
In this case, I am connecting via bridged network, so the VM is not getting its name from dnsmasq but from the dhcpd on a RHEL 8 server.
[root@case ~]# virsh net-dumpxml default <network> <name>default</name> <uuid>0082d9c5-2879-47e6-9c1b-cdf6ff060630</uuid> <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> <bridge name='virbr0' stp='on' delay='0'/> <mac address='52:54:00:b6:9b:91'/> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254'/> </dhcp> </ip> </network>
On Mon, 2022-01-17 at 08:42 +0100, Peter Boy wrote:
The default configuration rather follows the opposite principle. The hostname should be well defined and independent of changing IP addresses.
I sort-of go along with that. If you've set a hostname, there's sense in it not getting changed. On the other hand, if you use a DHCP server to centrally manage the allocation of addresses, you might also want it (or your DNS server) to control hostnames. I do. Some devices on my network obey naming instructions from the DHCP &/or DNS servers, others ignore it.
On 1/17/22 11:27, Tim via users wrote:
On Mon, 2022-01-17 at 08:42 +0100, Peter Boy wrote:
The default configuration rather follows the opposite principle. The hostname should be well defined and independent of changing IP addresses.
I sort-of go along with that. If you've set a hostname, there's sense in it not getting changed. On the other hand, if you use a DHCP server to centrally manage the allocation of addresses, you might also want it (or your DNS server) to control hostnames. I do. Some devices on my network obey naming instructions from the DHCP &/or DNS servers, others ignore it.
I think it might make more sense to correctly detect hostname during installation. If you define hostname on installation from network, it should be kept. I expect it should keep the same hostname during reboots. I think only diskless terminals may want always obtaining hostname on every boot. Anything storing state on local disk should want to keep its name.
I think more tight integration with libvirt names would be useful. I admit I know little of that. I usually define name AFTER installation for my VMs, which would not work with what I propose. I would like easy way to set hostname from libvirt during installation. I don't need always fixed IP, but I want fixed DNS name for given VM. I expect that is common requirement.
dnsmasq from libvirt would provide hostname to machine in case it has static lease for given DUID/hwaddr. Is there tool to create static lease from machine name on VM creation? For example libvirt can detect name of distribution from ISO image. It would be nice if it could propagate it forward.
I am afraid I did not help much.
Regards, Petr
On 1/17/22 15:30, Petr Menšík wrote:
I think it might make more sense to correctly detect hostname during installation. If you define hostname on installation from network, it should be kept. I expect it should keep the same hostname during reboots. I think only diskless terminals may want always obtaining hostname on every boot. Anything storing state on local disk should want to keep its name.
That's fine if you're creating relatively bespoke VMs. But if I want to spin up a dozen disposable systems, I kinda want them to just take on the hostname that I've already set up in DNS, execute the install routines based on their hostname, and then go away when I'm done with them.
I think more tight integration with libvirt names would be useful. I admit I know little of that. I usually define name AFTER installation for my VMs, which would not work with what I propose. I would like easy way to set hostname from libvirt during installation. I don't need always fixed IP, but I want fixed DNS name for given VM. I expect that is common requirement.
Why would we reinvent the naming wheel? We have had a method for assigning hostnames for decades using gethostbyaddr(). Why has this changed with F35 all of a sudden?
Thomas
On 1/20/22 19:17, Thomas Cameron wrote:
On 1/17/22 15:30, Petr Menšík wrote:
I think it might make more sense to correctly detect hostname during installation. If you define hostname on installation from network, it should be kept. I expect it should keep the same hostname during reboots. I think only diskless terminals may want always obtaining hostname on every boot. Anything storing state on local disk should want to keep its name.
That's fine if you're creating relatively bespoke VMs. But if I want to spin up a dozen disposable systems, I kinda want them to just take on the hostname that I've already set up in DNS, execute the install routines based on their hostname, and then go away when I'm done with them.
I think more tight integration with libvirt names would be useful. I admit I know little of that. I usually define name AFTER installation for my VMs, which would not work with what I propose. I would like easy way to set hostname from libvirt during installation. I don't need always fixed IP, but I want fixed DNS name for given VM. I expect that is common requirement.
Why would we reinvent the naming wheel? We have had a method for assigning hostnames for decades using gethostbyaddr(). Why has this changed with F35 all of a sudden?
OK, so this is weird. I just kickstarted a F35 VM. When it booted up, its hostname was host156.tc.camerontech.com, as I expected it to be.
The /etc/hostname file is blank - it just has a single empty line.
After I rebooted that VM, its hostname is set to fedora:
[root@fedora ~]# hostnamectl Static hostname: n/a Transient hostname: fedora Icon name: computer-vm Chassis: vm Machine ID: f3c5fe2142c5461eafea7dc985903a1f Boot ID: 64e3a58e839744d8b5fad1f189e739a9 Virtualization: kvm Operating System: Fedora Linux 35 (Thirty Five) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.15-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: QEMU Hardware Model: Standard PC _Q35 + ICH9, 2009_
[root@fedora ~]# hostname fedora
So it seems that the expected behavior happens after installation, but then it is somehow changed when the first user logs in.
This is bizarre.
Thomas
On Thu, 2022-01-20 at 19:45 -0600, Thomas Cameron wrote:
OK, so this is weird. I just kickstarted a F35 VM. When it booted up, its hostname was host156.tc.camerontech.com, as I expected it to be.
The /etc/hostname file is blank - it just has a single empty line.
After I rebooted that VM, its hostname is set to fedora
It wouldn't be quite so bad if it set its hostname to the one it discovered (even though you'd rather it keep on discovering it), but changing a hostname is intolerable.
Have you tried making the hostname file immutable?
On 1/20/22 20:30, Tim via users wrote:
On Thu, 2022-01-20 at 19:45 -0600, Thomas Cameron wrote:
OK, so this is weird. I just kickstarted a F35 VM. When it booted up, its hostname was host156.tc.camerontech.com, as I expected it to be.
The /etc/hostname file is blank - it just has a single empty line.
After I rebooted that VM, its hostname is set to fedora
It wouldn't be quite so bad if it set its hostname to the one it discovered (even though you'd rather it keep on discovering it), but changing a hostname is intolerable.
Have you tried making the hostname file immutable?
Thing is, the /etc/hostname file is blank! This is bizarre. I've just tested with F33, F34, and F35. With F33, the hostname is set to localhost. With F34 and F35, it's set to fedora. With RHEL 8.5, it's set to the reverse DNS assigned hostname. With RHEL 9 beta, it's the reverse DNS assigned hostname.
This is weirder and weirder.
Thomas
One key difference might be enabled systemd-resolved by default in Fedora 34, but it is not in RHEL9. I think it should not be related directly. But could it?
What does hostnamectl report after installation? What it thinks the hostname is? Would the behaviour change if you disable systemd-resolved and reboot?
On 1/21/22 03:35, Thomas Cameron wrote:
On 1/20/22 20:30, Tim via users wrote:
On Thu, 2022-01-20 at 19:45 -0600, Thomas Cameron wrote:
OK, so this is weird. I just kickstarted a F35 VM. When it booted up, its hostname was host156.tc.camerontech.com, as I expected it to be.
The /etc/hostname file is blank - it just has a single empty line.
After I rebooted that VM, its hostname is set to fedora
It wouldn't be quite so bad if it set its hostname to the one it discovered (even though you'd rather it keep on discovering it), but changing a hostname is intolerable.
Have you tried making the hostname file immutable?
Thing is, the /etc/hostname file is blank! This is bizarre. I've just tested with F33, F34, and F35. With F33, the hostname is set to localhost. With F34 and F35, it's set to fedora. With RHEL 8.5, it's set to the reverse DNS assigned hostname. With RHEL 9 beta, it's the reverse DNS assigned hostname.
This is weirder and weirder.
Thomas
On 1/24/22 09:50, Petr Menšík wrote:
One key difference might be enabled systemd-resolved by default in Fedora 34, but it is not in RHEL9. I think it should not be related directly. But could it?
What does hostnamectl report after installation? What it thinks the hostname is? Would the behaviour change if you disable systemd-resolved and reboot?
I just did a fresh kickstart of F35 Server. I didn't do anything to set the hostname during installation.
At first boot, I could see that the hostname was set to the reverse DNS-provided hostname "hostxxx.tc.camerontech.com" - this is normal and expected.
When I log in via ssh or on the KVM console, the hostname is hostxxx.tc.camerontech.com UNITL I REBOOT.
Once I reboot, the hostname is set up "fedora" with no FQDN. I am assuming it's somehow being set because of the lines in /etc/profile where the hostname is set, but I'm not sure.
I looked at the hostname-mode option of NetworkManger.conf, but I've tried various settings and it doesn't seem to work. From the man page:
hostname-mode Set the management mode of the hostname. This parameter will affect only the transient hostname. If a valid static hostname is set, NetworkManager will skip the update of the hostname despite the value of this option. An hostname empty or equal to 'localhost', 'localhost6', 'localhost.localdomain' or 'localhost6.localdomain' is considered invalid.
default: NetworkManager will update the hostname with the one provided via DHCP or reverse DNS lookup of the IP address on the connection with the default route or on any connection with the property hostname.only-from-default set to 'false'. Connections are considered in order of increasing value of the hostname.priority property. In case multiple connections have the same priority, connections activated earlier are considered first. If no hostname can be determined in such way, the hostname will be updated to the last one set outside NetworkManager or to 'localhost.localdomain'.
dhcp: this is similar to 'default', with the difference that after trying to get the DHCP hostname, reverse DNS lookup is not done. Note that selecting this option is equivalent to setting the property 'hostname.from-dns-lookup' to 'false' globally for all connections in NetworkManager.conf.
none: NetworkManager will not manage the transient hostname and will never set it.
I've set the hostname-mode to "default" in the NetworkManager.conf file and rebooted but it doesn't make any difference.
Here are screenshots: https://imgur.com/a/gRzswnI
Thomas
Am 25.01.2022 um 18:46 schrieb Thomas Cameron thomas.cameron@camerontech.com:
I just did a fresh kickstart of F35 Server. I didn't do anything to set the hostname during installation.
At first boot, I could see that the hostname was set to the reverse DNS-provided hostname "hostxxx.tc.camerontech.com" - this is normal and expected.
When I log in via ssh or on the KVM console, the hostname is hostxxx.tc.camerontech.com UNITL I REBOOT.
Once I reboot, the hostname is set up "fedora" with no FQDN. I am assuming it's somehow being set because of the lines in /etc/profile where the hostname is set, but I'm not sure.
Disabling systemd-resolved might not be the best idea. That makes you a good candidate for surprise follow-up problems elsewhere.
I’m wondering, if something is wrong with your DHCP / DNS service.
systemd-resolved „knows“ there kind of hostnames:
If you don’t touch the hostname during installation, you get a „transient hostname“ with fallback „fedora“, if the system get’s no hostname from DHCP, or a similar service. The transient hostname is evaluated at each boot time. If your DHCP service provides a hostname, it is used. Otherwise - just as a fallback - fedora is used.
As soon as you define a „static hostname“, that hostname is fixed and will not be changed in the future (unless you change it explicitly), regardless what your DHCP server might deliver. If I remember correctly, the static hostname is synchronised with the classic /etc/hostname. Or maybe, it is a one-time action.
And that is exactly the way, F35 works. I just tested the setup. (Usually I go the other path and define a static hostname in the installation process and the DHCP server picks that hostname and creates an DNS entry).
(For details see https://www.freedesktop.org/software/systemd/man/hostnamectl.html)
Best Peter
On 1/26/22 14:17, Peter Boy wrote:
Am 25.01.2022 um 18:46 schrieb Thomas Cameron thomas.cameron@camerontech.com:
I just did a fresh kickstart of F35 Server. I didn't do anything to set the hostname during installation.
At first boot, I could see that the hostname was set to the reverse DNS-provided hostname "hostxxx.tc.camerontech.com" - this is normal and expected.
When I log in via ssh or on the KVM console, the hostname is hostxxx.tc.camerontech.com UNITL I REBOOT.
Once I reboot, the hostname is set up "fedora" with no FQDN. I am assuming it's somehow being set because of the lines in /etc/profile where the hostname is set, but I'm not sure.
Disabling systemd-resolved might not be the best idea. That makes you a good candidate for surprise follow-up problems elsewhere.
I’m wondering, if something is wrong with your DHCP / DNS service.
I think I figured out what he's doing and I'm kind of surprised that it works at all. He's expecting the system to use its IP address to lookup its hostname. That seems wrong. Maybe what is working is that the installer does that lookup and sets the hostname during the install. But that setting has become transient for some reason (which I think I've noticed, but didn't investigate). The DCHP server is the one that's supposed to be supplying the hostname.
Am 26.01.2022 um 23:48 schrieb Samuel Sieb samuel@sieb.net:
The DCHP server is the one that's supposed to be supplying the hostname.
Yes, indeed. In my test setup here, I use dnsmasq (as libvirt plugin) and find in /var/lib/libvirt/dnsmasq/virbr0.macs entries like: { "domain": "vm1", "macs": [ "52:54:00:37:f5:03" ] }
And optionally I can define vor each name an IP address (either in virsh net-edit default or in default.addhost) that the DHCP picks up.
And in virbr0.status more detailed what is answered to the DHCP request: { "ip-address": "192.168.122.207", "mac-address": "52:54:00:e9:43:0c", "hostname": "vm2", "client-id": "01:52:54:00:e9:43:0c", "expiry-time": 1643242158 }
But as soon as you make the hostname static on the client, you can configure in dnsmasq as hostname what you like, the client does not change the hostname.
So, Thomas should check with dhclient -v (out of my head, maybe some more parameters, there is also a dry-run, that doesn’t change configuration) what his DHCP delivers.
And in any case better keep away from messing around with /etc/hostname.
Best Peter
On Wed, 2022-01-26 at 14:48 -0800, Samuel Sieb wrote:
I think I figured out what he's doing and I'm kind of surprised that it works at all. He's expecting the system to use its IP address to lookup its hostname. That seems wrong. Maybe what is working is that the installer does that lookup and sets the hostname during the install. But that setting has become transient for some reason (which I think I've noticed, but didn't investigate). The DCHP server is the one that's supposed to be supplying the hostname.
I don't see why that's wrong, there were plenty of things that discover their hostname by doing a reverse look-up of their IP. And he demonstrated several releases that worked exactly that way.
The inverse of that was there were plenty of things that would foul up if the reverse lookup of their IP didn't work, or came up with different answers than expected.
I remember coming across this in the past when setting up HTTP servers, mail servers, etc. Apache springs to mind, in particular, it would work out its hostname via reverse IP lookups if you don't manually set it in the Apache configuration (it doesn't find out its hostname from the host's hostname).
* DHCP can accept a hostname from a client, but it doesn't have to. * DHCP can give a hostname to a client, but it doesn't have to, and the client doesn't have to accept it. * A host can find out its hostname from its IP address. I recall having to specify how many dots to count to separate hostname from domain name (e.g. if you were fred.bargle.flargle.net.au, your domain name could bargle.flargle.net.au or flargle.net.au, and therefore there were two possibilities of what your hostname might be).
A particular advantage of having the host and domain names being worked out from polling your DNS server is that the details will be consistent with what everything else thinks you are.
On 1/26/22 21:59, Tim via users wrote:
On Wed, 2022-01-26 at 14:48 -0800, Samuel Sieb wrote:
I think I figured out what he's doing and I'm kind of surprised that it works at all. He's expecting the system to use its IP address to lookup its hostname. That seems wrong. Maybe what is working is that the installer does that lookup and sets the hostname during the install. But that setting has become transient for some reason (which I think I've noticed, but didn't investigate). The DCHP server is the one that's supposed to be supplying the hostname.
I don't see why that's wrong, there were plenty of things that discover their hostname by doing a reverse look-up of their IP. And he demonstrated several releases that worked exactly that way.
What are these plenty of things? This is the first that I know of. And the question still remains. Is the OS looking up the hostname at runtime or was it always the installer setting it at install time?
Tim:
I don't see why that's wrong, there were plenty of things that discover their hostname by doing a reverse look-up of their IP. And he demonstrated several releases that worked exactly that way.
Samuel Sieb:
What are these plenty of things? This is the first that I know of. And the question still remains. Is the OS looking up the hostname at runtime or was it always the installer setting it at install time?
He listed several, and even showed a demo.
I listed one Apache, and I seem to recall Jabber and Dovecot did the same thing (they don't ask your OS what it's host and domain name are, it checks via DNS lookups).
On 1/26/22 23:45, Tim via users wrote:
Tim:
I don't see why that's wrong, there were plenty of things that discover their hostname by doing a reverse look-up of their IP. And he demonstrated several releases that worked exactly that way.
Samuel Sieb:
What are these plenty of things? This is the first that I know of. And the question still remains. Is the OS looking up the hostname at runtime or was it always the installer setting it at install time?
He listed several, and even showed a demo.
I listed one Apache, and I seem to recall Jabber and Dovecot did the same thing (they don't ask your OS what it's host and domain name are, it checks via DNS lookups).
That's a horrible idea! And it would fail most of the time.
On 1/27/22 01:21, Samuel Sieb wrote:
What are these plenty of things? This is the first that I know of. And the question still remains. Is the OS looking up the hostname at runtime or was it always the installer setting it at install time?
Historically it's looked up its hostname at boot time. Older versions of Linux used various mechanisms via e.g. /etc/sysconfig/network-scripts/network-functions and /etc/sysconfig/network-scripts/ifup-eth. The new setup seems to only use reverse DNS the first time the system boots, then set it to "fedora."
Thomas
Am 27.01.2022 um 06:59 schrieb Tim via users users@lists.fedoraproject.org:
….
- DHCP can accept a hostname from a client, but it doesn't have to.
- DHCP can give a hostname to a client, but it doesn't have to, and
the client doesn't have to accept it.
- A host can find out its hostname from its IP address. I recall
having to specify how many dots to count to separate hostname from domain name (e.g. if you were fred.bargle.flargle.net.au, your domain name could bargle.flargle.net.au or flargle.net.au, and therefore there were two possibilities of what your hostname might be).
A particular advantage of having the host and domain names being worked out from polling your DNS server is that the details will be consistent with what everything else thinks you are.
A particular disadvantage is that a reverse lookup does not have to be unambiguous. On the contrary, it is very common that several hosts share one IP. So, in many cases it will provide you with a list of hostnames. Which one to choose?
A DHCP provided hostname is unambiguous (or empty).
For the Apache example: If Apache finds a unique hostname, it will be used. A warning is issued if inconsistencies occur (e.g. between hostname and DNS check). No problem for Apache, in case of doubt the request is delivered to the default server. A valid solution.
On 1/26/22 16:48, Samuel Sieb wrote:
I think I figured out what he's doing and I'm kind of surprised that it works at all. He's expecting the system to use its IP address to lookup its hostname. That seems wrong. Maybe what is working is that the installer does that lookup and sets the hostname during the install. But that setting has become transient for some reason (which I think I've noticed, but didn't investigate). The DCHP server is the one that's supposed to be supplying the hostname.
Linux has used the reverse DNS name for name resolution for EVER. Again, see https://youtu.be/pAVNwwrHwkw to see that every version of RHEL has used reverse DNS since RHEL 4. I also tested against older versions of Fedora, and it has ALWAYS used reverse DNS for hostname resolution.
In older versions of RHEL and pre-Fedora 33, the hostname was set via the contents of e.g. /etc/sysconfig/network-scripts/network-functions and /etc/rc.d/rc.sysinit.
Thomas
On 1/26/22 16:17, Peter Boy wrote:
Disabling systemd-resolved might not be the best idea. That makes you a good candidate for surprise follow-up problems elsewhere.
I’m wondering, if something is wrong with your DHCP / DNS service.
I mean, I guess it could be, but I've used ISC dhcpd and named for literally decades and I've never run into problems until now. It Just Works(TM) with RHEL 4-9, and versions of Fedora previous to 33.
systemd-resolved „knows“ there kind of hostnames:
If you don’t touch the hostname during installation, you get a „transient hostname“ with fallback „fedora“, if the system get’s no hostname from DHCP, or a similar service. The transient hostname is evaluated at each boot time. If your DHCP service provides a hostname, it is used. Otherwise - just as a fallback - fedora is used.
It *does* get the hostname from DNS until the system reboots the first time. Then it seems to be set to "fedora."
As soon as you define a „static hostname“, that hostname is fixed and will not be changed in the future (unless you change it explicitly), regardless what your DHCP server might deliver. If I remember correctly, the static hostname is synchronised with the classic /etc/hostname. Or maybe, it is a one-time action.
I don't set any hostname via dhcp, I shouldn't have to. Literally every Linux version I've worked with except for F34 and F35 use the reverse DNS information.
And that is exactly the way, F35 works. I just tested the setup. (Usually I go the other path and define a static hostname in the installation process and the DHCP server picks that hostname and creates an DNS entry).
(For details seehttps://www.freedesktop.org/software/systemd/man/hostnamectl.html)
I get how it's SUPPOSED to work. I know how it's worked with Linux since I started working with it back in 1995. My point is, it IS NOT WORKING THAT WAY.
Watch this video to show how it actually works vs. how it's supposed to work: https://youtu.be/Vl6xUkzoIss
Thomas
On 1/24/22 09:50, Petr Menšík wrote:
One key difference might be enabled systemd-resolved by default in Fedora 34, but it is not in RHEL9. I think it should not be related directly. But could it?
What does hostnamectl report after installation? What it thinks the hostname is? Would the behaviour change if you disable systemd-resolved and reboot?
I forgot to mention - disabling systemd-resolved does not make the system get the reverse DNS assigned hostname. It's just set to "fedora."
Thomas
On 1/25/22 11:48, Thomas Cameron wrote:
I forgot to mention - disabling systemd-resolved does not make the system get the reverse DNS assigned hostname. It's just set to "fedora."
Actually, I was incorrect! It said "fedora" as the hostname until I logged in at the console. Then the hostname was set correctly. I rebooted a couple of times and the hostname seems to be set correctly now.
I added the screenshot to https://imgur.com/a/gRzswnI
This may be the resolution, is to just disable systemd-resolved. I hate to do it, though. I still don't understand why the hostname isn't being set correctly.
Thomas
On Tue, Jan 25, 2022 at 11:55:03AM -0600, Thomas Cameron wrote:
This may be the resolution, is to just disable systemd-resolved. I hate to do it, though. I still don't understand why the hostname isn't being set correctly.
Can you file a bug for this please? Thanks.
On 1/26/22 11:32, Matthew Miller wrote:
On Tue, Jan 25, 2022 at 11:55:03AM -0600, Thomas Cameron wrote:
This may be the resolution, is to just disable systemd-resolved. I hate to do it, though. I still don't understand why the hostname isn't being set correctly.
Can you file a bug for this please? Thanks.
Sure. Although I am not sure what I am supposed to file it against. I don't understand why getting a hostname from an IP address has stopped working, and I'm not sure if this is a systemd-resolved issue, or network scripts, or what.
Thomas
On 1/26/22 11:32, Matthew Miller wrote:
On Tue, Jan 25, 2022 at 11:55:03AM -0600, Thomas Cameron wrote:
This may be the resolution, is to just disable systemd-resolved. I hate to do it, though. I still don't understand why the hostname isn't being set correctly.
Can you file a bug for this please? Thanks.
https://bugzilla.redhat.com/show_bug.cgi?id=2047512
Thomas
On 1/17/22 04:27, Tim via users wrote:
I sort-of go along with that. If you've set a hostname, there's sense in it not getting changed. On the other hand, if you use a DHCP server to centrally manage the allocation of addresses, you might also want it (or your DNS server) to control hostnames. I do. Some devices on my network obey naming instructions from the DHCP &/or DNS servers, others ignore it.
Historically, pretty much every Linux distro I've used over the years has set its hostname from reverse IP lookup. It's been this way for ages. I am a little frustrated that this behavior has changed with F35.
Thomas
On 1/17/22 01:42, Peter Boy wrote:
I was already afraid that I had overlooked something essential. :-)
The default configuration rather follows the opposite principle. The hostname should be well defined and independent of changing IP addresses. I guess the only way will be to determine the hostname via script and call networkctl with it. Unfortunately rclocal is lost. You use KVM on Fedora Server that includes libvirt. It provides hooks which you can use to automatically execute scripts when libvirt finishes initialisation. See https://libvirt.org/hooks.html. As an example I use that to fix some issues with systems-resolved and libvirt (https://docs.stg.fedoraproject.org/en-US/fedora-server/virtualization-instal...)
You can also use it to trigger /etc/profile.d/hostname.sh without login. Systemd also provides a replacement for rc.local, but last time I checked it, it was quite tricky.
Well, I did create an /etc/profile.d/hostname.sh script, and it works, but it requires someone to login from the console or ssh. It's hackish and I don't like it.
Thomas
Peter Boy writes:
Usually you set the static hostname once using "hostnamectl set-hostname <FQDN>“. „fedora“ is the transient hostname. DHCP client uses the static hostname to request an IP.
But maybe I didn't get what exactly you want to do.
dhcpd's configuration file uses MAC addresses to assign reserved IP addresses to specific DHCP clients. It doesn't matter what hostname the client sends.
I suppose that the DHCP server might keep track of hostnames and for MAC addresses that don't have fixed IP addresses it might use the client's hostname to keep leasing out the same IP address, if possible. But the same can be done with MAC address entirely, instead of hostnames, too.
Am 17.01.2022 um 16:22 schrieb Sam Varshavchik mrsam@courier-mta.com:
Peter Boy writes:
Usually you set the static hostname once using "hostnamectl set-hostname <FQDN>“. „fedora“ is the transient hostname. DHCP client uses the static hostname to request an IP.
But maybe I didn't get what exactly you want to do.
dhcpd's configuration file uses MAC addresses to assign reserved IP addresses to specific DHCP clients. It doesn't matter what hostname the client sends.
Yes, my wording was way too short. It uses the static hostname to enter the IP generated for the MAC address along with the hostname into the DNS part (in dnsmasq, which is used in Fedora KVM/libwirt) that is used to retrieve the hostname.
But Thomas uses a static host table, so the DNS delivered hostname is independent from any MAC address and any transient or static hostname of the client.
I suppose that the DHCP server might keep track of hostnames and for MAC addresses that don't have fixed IP addresses it might use the client's hostname to keep leasing out the same IP address, if possible. But the same can be done with MAC address entirely, instead of hostnames, too.
At least dnsmasq does not, but relies on the MAC address alone.
Peter
Peter Boy writes:
Am 17.01.2022 um 16:22 schrieb Sam Varshavchik mrsam@courier-mta.com:
Peter Boy writes:
Usually you set the static hostname once using "hostnamectl set-hostname
<FQDN>“. „fedora“ is the transient hostname. DHCP client uses the static hostname to request an IP.
But maybe I didn't get what exactly you want to do.
dhcpd's configuration file uses MAC addresses to assign reserved IP
addresses to specific DHCP clients. It doesn't matter what hostname the client sends.
Yes, my wording was way too short. It uses the static hostname to enter the IP generated for the MAC address along with the hostname into the DNS part (in dnsmasq, which is used in Fedora KVM/libwirt) that is used to retrieve the hostname.
Ok, so this is basically trusted DDNS stacked on top of DHCP.
But Thomas uses a static host table, so the DNS delivered hostname is independent from any MAC address and any transient or static hostname of the client.
It should be possible to hack up a script that gets run when an IP address is assigned that does a reverse IP lookup and sets the hostname. However that should be done in a manner that does not permanently save the hostname so that it gets reverted to a static stub name on the next reboot.
On 1/17/22 14:29, Sam Varshavchik wrote:
It should be possible to hack up a script that gets run when an IP address is assigned that does a reverse IP lookup and sets the hostname. However that should be done in a manner that does not permanently save the hostname so that it gets reverted to a static stub name on the next reboot.
But this is the behavior Linux has used for years and years. If you set your hostname to localhost.localdomain, say via a kickstart script or a golden image you use to spin up dozens of instances, previous versions of Fedora would find the hostname via DNS and assign it at boot.
Why has this changed?
Thomas
On Thu, 20 Jan 2022 19:20:22 -0600 Thomas Cameron wrote:
But this is the behavior Linux has used for years and years. If you set your hostname to localhost.localdomain, say via a kickstart script or a golden image you use to spin up dozens of instances, previous versions of Fedora would find the hostname via DNS and assign it at boot.
I never once had that happen. And I installed hundreds of virtual machines with different releases for different distros for testing at work.
What I have had happen is if I installed the name in DNS prior to installing the VM, and if I installed a fixed MAC->IP mapping in the DHCP server, then installed the VM using the expected MAC for the virtual interface, the machine at install time would find the name and use it instead of localhost.localdomain.
In practice though, I found it much simpler (though not all that simple given the 47,321 pages of named docs) to set up dynamic DNS along with the DHCP server, then specify the hostname of the virtual machine at install and let the DHCP/DNS combo install that name in the DNS server for the virtual machine subnet at boot. Especially once I got more than 256 virtual machines, and they had to share IP addrs on the subnet (couldn't have more than 10 or so actually running at once).
On 1/20/22 19:40, Tom Horsley wrote:
I never once had that happen. And I installed hundreds of virtual machines with different releases for different distros for testing at work.
It has worked this way for YEARS. Is your environment set up with working forward and reverse DNS?
I just tested it again with F35 and it got the correct hostname from reverse DNS *unitl* the first time someone logs in. Then it sets the hostname to "fedora" based on the lines in /etc/profile:
HOSTNAME=$(/usr/bin/hostnamectl --transient 2>/dev/null) || \ HOSTNAME=$(/usr/bin/hostname 2>/dev/null) || \ HOSTNAME=$(/usr/bin/uname -n) export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE HISTCONTROL
On 1/20/22 19:43, Thomas Cameron wrote:
On 1/20/22 19:40, Tom Horsley wrote:
I never once had that happen. And I installed hundreds of virtual machines with different releases for different distros for testing at work.
It has worked this way for YEARS. Is your environment set up with working forward and reverse DNS?
I just tested it again with F35 and it got the correct hostname from reverse DNS *unitl* the first time someone logs in. Then it sets the hostname to "fedora" based on the lines in /etc/profile:
HOSTNAME=$(/usr/bin/hostnamectl --transient 2>/dev/null) || \ HOSTNAME=$(/usr/bin/hostname 2>/dev/null) || \ HOSTNAME=$(/usr/bin/uname -n) export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE HISTCONTROL
I made a quick video of the difference between F35 and RHEL 8.5.
Skip to about the 1:30 mark to see the difference between F35 and RHEL 8.5. I've seen the hostname assigned by reverse DNS with every version of RHEL since at least RHEL 4. In fact, I don't recall it working otherwise ever.
Thomas
On 1/20/22 20:10, Thomas Cameron wrote:
I made a quick video of the difference between F35 and RHEL 8.5.
Skip to about the 1:30 mark to see the difference between F35 and RHEL 8.5. I've seen the hostname assigned by reverse DNS with every version of RHEL since at least RHEL 4. In fact, I don't recall it working otherwise ever.
I just tested to make sure. Every version of RHEL from 4 through 9 beta has worked as I expected - the hostname is set based on the reverse DNS for the IP address assigned to the instance, so hostxxx.tc.camerontech.com.
I tested a couple of older versions of Fedora and found that older versions like F28 work like I expect (hostxxx.tc.camerontech.com), but 33 sets the hostname to localhost.localdomain, and 34 and 35 set the hostname to just "fedora" with no domain or extension.
I looked at the man page for NetworkManager.conf and it looks like hostname-mode in the [main] section *should* do what I want:
default: NetworkManager will update the hostname with the one provided via DHCP or reverse DNS lookup of the IP address on the connection with the default route or on any connection with the property hostname.only-from-default set to 'false'. Connections are considered in order of increasing value of the hostname.priority property. In case multiple connections have the same priority, connections activated earlier are considered first. If no hostname can be determined in such way, the hostname will be updated to the last one set outside NetworkManager or to 'localhost.localdomain'.
But I've tried and it doesn't seem to make any difference.
Thomas
Man 5 hostname says different thing. I would guess as many things changes after long time, systemd would be responsible somehow.
From what they describe your machine has to obtain hostname from DHCP lease. If it does not, it fall back to transient name "fedora". Nothing there is mentioned about reverse DNS query.
I think you could fix it by systemd unit started After=network-online.target. hostname -A might be useful for obtaining hostname from address. Do not expect it to return just single name. First name might be obtained by:
HOSTNAME=$(hostname -A | cut -d' ' -f1)
hostnamectl set-hostname --transient $HOSTNAME
Then use systemctl edit --full --force hostname-fixup.service
# Use such content for example. [Service] Type=oneshot ExecStart=/usr/local/sbin/dynamic-hostname.sh
[Install] WantedBy=multi.target
On 1/21/22 05:16, Thomas Cameron wrote:
On 1/20/22 20:10, Thomas Cameron wrote:
I made a quick video of the difference between F35 and RHEL 8.5.
Skip to about the 1:30 mark to see the difference between F35 and RHEL 8.5. I've seen the hostname assigned by reverse DNS with every version of RHEL since at least RHEL 4. In fact, I don't recall it working otherwise ever.
I just tested to make sure. Every version of RHEL from 4 through 9 beta has worked as I expected - the hostname is set based on the reverse DNS for the IP address assigned to the instance, so hostxxx.tc.camerontech.com.
I tested a couple of older versions of Fedora and found that older versions like F28 work like I expect (hostxxx.tc.camerontech.com), but 33 sets the hostname to localhost.localdomain, and 34 and 35 set the hostname to just "fedora" with no domain or extension.
I looked at the man page for NetworkManager.conf and it looks like hostname-mode in the [main] section *should* do what I want:
default: NetworkManager will update the hostname with the one provided via DHCP or reverse DNS lookup of the IP address on the connection with the default route or on any connection with the property hostname.only-from-default set to 'false'. Connections are considered in order of increasing value of the hostname.priority property. In case multiple connections have the same priority, connections activated earlier are considered first. If no hostname can be determined in such way, the hostname will be updated to the last one set outside NetworkManager or to 'localhost.localdomain'.
But I've tried and it doesn't seem to make any difference.
Thomas _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-
Matthew Miller -
Peter Boy -
Petr Menšík -
Sam Varshavchik -
Samuel Sieb -
Thomas Cameron -
Tim -
Tom Horsley