My DHCP client is sending DHCPREQUEST packets with OPTION: 12 ( 10) Host name set to the original hostname generated automatically during installation, and not to the current user-friendly hostname reset using Yast -> Network Settings.
This means that my local DNS server (router dnsmasq) has the wrong name for my PC and reverse lookups by other network devices (eg reporting previous logins) show and log the wrong name.
Yast has updated /etc/HOSTNAME and the hostname string in all files that I can scan with grep (recursively from the filesystem root as superuser). I can find no remaining instance of the old hostname. I have rebooted (several times).
My single network interface is managed by wicked; I believe that dhclient is not used.
So where is wicked getting the old hostname from? And how do I reset it?
Maybe I should report this as a bug, but I thought I’d ask here first. This issue seems similar to the recent thread ‘Leap 42.3: twee verschillende hostnamen?’ in the Dutch forum. Hopefully this forum will give larger exposure to the issue.
Maybe it should be added that it is almost impossible now to set the wanted network parameter hostname to an installation. The former “No automatic configuration” checkbox is gone. The result is IP addresses, hostname, router and all that set to the whim of the installer.
Of course one can change all that after installation (not that that is seen as a good solution by many :(), but when it now becomes impossible to set the hostname to ones liking there is a more serious problem IMHO.
It is possible for multiple hostname to be specified in Yast; Run the
following:
sudo /sbin/yast lan
Once in there look both under the 'Hostname/DNS tab, as well as under the
network interface cards (NIC) under Overview. Perhaps one of those has a
static hostname while the other is using another one.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
The information in this thread is not complete I am afraid. There is some more in the Dutch thread.
The Dutch OP states that changing the hostname using YaST (something that is advised here often) worked as intended in 42.2. But that it doesn’t in 42.3
Thus the case is that the “normal” way to do this is known, but in 42.3 it does not work anymore.
I promised to check this (I have a 42.2 system here and want to update it to 42.3, thus I hope I can recreate the problem and document it), but lacked the time until now.
BTW the Dutch OP solved this by reinstalling with a pulled out network cable. That seems to be the only way to switch the installer to ask for network parameters (including hostname) and thus to configure them to one’s needs.
This is mentioned in other threads here on the forum. A nasty and ugly way to get your system up and running, but the only one known now. >:)
‘yast lan’ gives me the same panel in a text-console GUI, as Yast[2] -> Network Settings which I mentioned above. All hostname fields were set correctly to the new hostname, including Yast -> Network Settings -> Global Options -> DHCP Client options -> Hostname to Send, for Wicked Service. But wicked still used the old hostname.
Hmmm…I’m not currently using wicked but I found a historic bug report where similar unwanted behaviour was mentioned for openSUSE 13.2. Comment #2 is pertinent - In /etc/wicked/extensions/hostname there is code that assumes rcsyslog command is present. I show what is contained in /etc/wicked/extenisons/hostname for openSUSE 42.3…
if test -s "$defaulthostname" ; then
def_hostname=`get_default_hostname`
curr_hostname=`get_current_hostname`
if test "X${def_hostname}" != "X" -a "X${curr_hostname}" != "X${def_hostname}" ; then
/bin/hostname "${def_hostname}" ; rc=$?
rcsyslog reload &>/dev/null
fi
fi
exit $rc
Now, of course on my system rcsyslog (syslog-service package) was missing…could that be the OP’s issue here perhaps? Apologies if on the wrong track.
However, at the point of the reported error, /bin/hostname would have
already been called and the hostname set from the Wicked extension. So it
looks like there’s a bit more happening here with respect to the interaction
between Wicked and YaST2/lan.
Now, if the interface for which this is occurring is configured via DHCP,
the restart of Wicked will request a new DHCP lease. Depending on DHCP
server configuration, the client requested hostname (/etc/hostname) may not
be returned in the response from the server, and thus a different, server
supplied hostname will be applied to the system by Wicked. /etc/hostname will
still contain the YaST2/lan version, while /bin/hostname will report what
Wicked actually set in response to the updated lease.
Are you using Btrfs for your filesystem for everything? Care to snapshot
the before/after your fix to see where the files that are changing reside,
and how they differ? That can b ea big task, but I’ve used snapshots a
few times to figure out these very kinds of “what really changed, blast
you?” types of questions.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
Seems like it. I don’t have syslog.service or rcsyslog installed either, but I wouldn’t expect to because Leap 42.3 uses systemd journal. I do have the same /etc/wicked/extensions/hostname script and I’m surprised to see the calls to rcsyslog in it. Clearly these won’t help.
My systemd journal entries show a systemd hostname service (org.freedesktop.hostname1’, and several systemd ‘set hostname’ commands. It is not clear to me whether these commands were issued by yast or by wicked.
systemd 25 and newer include systemd-hostnamed. This is a tiny daemon that can be used to control the host name and related machine meta data from user programs. It currently offers access to five variables:
The current host name (Example: dhcp-192-168-47-11)
The static (configured) host name (Example: lennarts-computer)
The pretty host name (Example: Lennart's Computer)
A suitable icon name for the local host (Example: computer-laptop)
A chassis type (Example: "tablet")
See systemd-hostnamed.service(8) for more information.
IMO the most likely issue is client-side… Not server-side.
It’s well known that sometimes the namecache can become corrupted or as you describe hold multiple hostnames mapped to the same address, for instance because you changed the hostname of a machine before the old name expired. I’ve run into this often in Development networks where hostnames might be changed that point to specific applications. Note that having multiple hostnames mapped to the same machine is legal and somewhat common so the issue isn’t that you’re resolving multiple hostnames but whether the hostnames are mapped correctly.
If you are doing local machine name testing instead of remote machine, you might also run into a less seen error when $HOST is not the same as $HOSTNAME.
To resolve,
You need only to purge the namecache, either by restarting the service (for systemd systems) or rebooting the machine.
systemctl restart nscd.service
That forces the machine to do lookups to rebuild the cache.
I agree this is a client side issue, but I don’t think namecache corruption is the cause here. I always reboot client machines when making network config changes, to ensure that changes stick (or to know that they haven’t if they don’t) and to minimise confusion on the network. Similarly with the DHCP serrver.
I also checked that $HOST = $HOSTNAME = updated value…
Yes, I’m using Btrfs for everything except a separately mounted /home volume (ext4).
I see in the remaining snapper snapshots (earlier ones have recycled/rotated), that files that changed were /etc/sysconfig/network/ifcfg-eth0 and /var/lib/wicked/lease-eth0-dhcp-ipv4.xml (I’m using only DHCP IP4)
Two things seem interesting:
/etc/sysconfig/network/ifcfg-eth0 includes ‘DHCLIENT_SET_DEFAULT_ROUTE=‘yes’’
Although default route is not an issue here, the config file is referring to dhclient which is inoperative in my wicked environment (as is rcsyslog, referred to in an earlier posting)
/var/lib/wicked/lease-eth0-dhcp-ipv4.xml contains a ‘hostname’ tag indicating the hostname (ifcfg-eth0 doesn’t)
None of my recursive grep searches of the /var folder found the old hostname, so I conclude that this file did not provide it.
As other have suggested, it seems that yast Network Settings, wicked and systemd are not reading from the same hymn sheet in every respect, so I think it likely we have a bug here. I’m not familiar enough with wicked to know how it handles the DHCP client - this is getting to the limit of my competence. So I shall report this issue as a bug/regression and see what others there make of it. If anyone here can add to my evidence, it will be helpful.
Hmmm. I probably would never have realized this change, if not for this thread, since my habit has always been to remove ethernet cable and install fresh from the DVD, set up network after installed and up at the desktop, then run updates.
But, the rare couple of times in the past that I did not disconnect the cable, I had no problem making the change in Yast->Network Settings even when using Network Manager. As said, though, this was the past and I do not know (yet) if that has changed.
However, I see hints of problems with this in the mailing lists and forums. If it has changed, it must be a bug. I cannot think of a good reason for the change to be deliberate.
Also, post a list of any Server applications you may be running on this machine like web servers, dB servers, etc
In addition to the above,
Pls post whatever means you’re running that is displaying the “wrong” or old hostname, ie the command or application and the result.
Also,
Are you running anything that implements NetBIOS Name resolution, like SAMBA3 or SAMBA4 with old SAMBA3 compatibility settings(which seems to be the inadvisable common recommendation in many openSUSE documentation) both on the problem machine and elsewhere in the LAN?
No web, DB server etc apps running on Leap 42.3 workstation. smbd & nmb not running. Samba client installed during Leap 42.3 clean install from DVD iso (downloaded directly from Suse website, internet connection was available during install). Xfce desktop.
You cannot identify any machine simply ss “host” or something like “the host” because the term “host” only refers generically to any machine on your network. This is related to organizing your posts between commands executed locally (same machine) or remotely (a different machine).
DHCP should never be related to name resolution. DHCP requests and responses are broadcasts, not directed transmissions, and is required to obtain an IP address before a nameserver can be contacted. Only in the very special case of implementing network security (eg LDAP or AD), then there is server to server integration, but is still not really relevant to client name resolution.
From what I <think> you posted, it appears that your <network name resolution> is affected and not your local name resolution.
If that is the case, then you need to first know how your network name resolution is implemented. Is there some reason why you are implementing dnsmasq and not a proper DNS server? Dnsmasq can be used for fairly simple setups like for name resolution on the same physical machine, but I wouldn’t recommend that for supporting a LAN (multiple physical machines).
