Page MenuHomeVyOS Platform

Hostname defaults to "debian" after applying rolling update
Closed, ResolvedPublicBUG

Description

After applying a rolling update the hostname is by default "debian". Another reboot is needed for the original hostname to re-appear.

$ hostname
debian

Details

Difficulty level
Unknown (require assessment)
Version
1.2.0-rolling+201807190337
Why the issue appeared?
Will be filled on close

Event Timeline

You get this when you upgrade from a previous rolling release, or from 1.1.8? If the former, which one?

Don't remember how it was from 1.1.8 to 1.2.0 but within 1.2.0 always.

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.

Hmm weird. Then I rather nuke the 1.2.0 installation and redo it completely.

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.

syncer triaged this task as Normal priority.Jul 20 2018, 12:31 PM

This is reproducible:

  1. Started fresh from 1.2.0-rolling+20180719033
  2. configure
  3. set system domain-name localdomain
  4. set system host-name somehostname
  5. commit
  6. save
  7. add system image https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201807211559-amd64.iso
  8. reboot

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

In T750#17132, @hagbard wrote:

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

Correct, I observed that as well. And 127.0.1.1 is rather wrong as well?

... 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?

This is reproducible:

  1. Started fresh from 1.2.0-rolling+20180719033
  2. configure
  3. set system domain-name localdomain
  4. set system host-name somehostname
  5. commit
  6. save
  7. add system image https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201807211559-amd64.iso
  8. reboot

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]

Tested it today again with 1.2.0-rolling+201808181101, no issues anymore.