After applying a rolling update the hostname is by default "debian". Another reboot is needed for the original hostname to re-appear.
$ hostname debian
After applying a rolling update the hostname is by default "debian". Another reboot is needed for the original hostname to re-appear.
$ hostname debian
You get this when you upgrade from a previous rolling release, or from 1.1.8? If the former, which one?
Could you try updating some test machine from 1.1.8?
I'm not having any issues on my test machines with 1.2.0, so it seems quite odd.
There was one or two 1.2.0 images that did have a hostname problem due to a problem in the new implementation of the system host-name command, but I fixed it. I wonder if your problem might be carried over from one of those images.
I started with vyos-1.2.0-rolling+201807050337-amd64.iso and it only occurs after the first reboot after a new image installation. The next reboot fixes it.
Gonna start fresh now to see if it occurs again.
This is reproducible:
hostname "debian" displayed in bash and with
$ hostname debian
immediately after the first reboot after the update has been applied. After the next reboot it is good again until next update.
Something might already go wrong when setting the hostname:
vyos@vyos# set system domain-name localdomain [edit] vyos@vyos# set system host-name somehostname [edit] vyos@vyos# commit [ system host-name somehostname ] sudo: unable to resolve host vyos sudo: unable to resolve host vyos sudo: unable to resolve host vyos [edit] vyos@vyos# save sudo: unable to resolve host vyos Saving configuration to '/config/config.boot'... Done [edit]
additionally in /etc/hosts each change adds the localhost line instead of replacing it.
127.0.1.1 vyos-hostnametest.localdomain # VyOS entry
127.0.1.1 vyos-hostnametest.localdomain # VyOS entry
127.0.1.1 vyos-hostnametest.localdomain # VyOS entry
... and that is why you don't like systemd. hostnamectl is bailing out, why? No idea yet.
libnss-myhostname may fix that already, it modifies nsswitch.conf and myhostname is always being resolved regardless if its in /etc/hosts or not.
I'm still looking why it is not setting the hostname, but does when you reboot. The config is executed, I checked that.
bingo!
cat /etc/hosts
127.0.0.1 localhost debian <----
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.1.1 vyos-hostnametest.localdomain # VyOS entry
127.0.1.1 vyos-hostnametest.localdomain # VyOS entry
127.0.1.1 vyos-hostnametest.localdomain # VyOS entry
127.0.1.1 vyos-hostnametest.localdomain # VyOS entry
That's why you see debian as hostname, after a reboot the script applies it correctly, after a fresh install or update like you did, if fails.
On a side note:
I also observed that when DNS forwarding is active the whole /etc/hosts is exposed to other clients via DNS. That makes no sense for everything 127.0.0.1.
Ideally the localdomain/dhcp hostname mappings would be tracked in a separate file that then could be exposed via DNS.
i will propose three files
system - for system things
user - for static hosts mappings
DHCP - for DHCP generated entries
I think it's possible to include several files in pdns
Wouldn't it be easier by just excluding 127.0.0.0/8 and ::/1?
I haven't checked, but how is it handled with IPv6 anyway? Like the link local adresses.
I see if I can find out, why it takes a reboot for the host_name.py script to function properly, I found in my tests yesterday it is always executed. hostnamectl sets /etc/hostname to "hostname.domain", shouldn't be done that way anyway.
It seems to be the culprit, but more testing is required, I won't have much time today.
@binaryanomaly
Hi, is that still an issue? I tried to reproduce it today and used all of the August rolling images, but can't reproduce it anymore.
@hagbard I don't have a running vyos instance where I could verify immediately. But if it's not reproduceable anymore by following the steps I described then I'd assume it's fixed?