Page MenuHomePhabricator

"set system name-server" generates invalid/incorrect resolv.conf
Closed, ResolvedPublicBUG

Description

vyos@VyOS-xxxx.xxxx.xxxx.xxxx# show system name-server
 name-server 2001:470:20::2
 name-server 74.82.42.42
[edit]
vyos@VyOS-xxxx.xxxx.xxxx.net# cat /etc/resolv.conf

### Autogenerated by host_name.py ###
nameserver '
nameserver 2
nameserver 0
nameserver 0
nameserver 1
nameserver :
nameserver 4
nameserver 7
nameserver 0
nameserver :
nameserver 2
nameserver 0
nameserver :
nameserver :
nameserver 2
nameserver '
nameserver
nameserver '
nameserver 7
nameserver 4
nameserver .
nameserver 8
nameserver 2
nameserver .
nameserver 4
nameserver 2
nameserver .
nameserver 4
nameserver 2
nameserver '

domain xxxx.xxxx.net
search xxxx.xxxx.net

Also, on bootup, the name servers are set from dhcp even though disable-dhcp-nameservers is set. After a commit, the broken resolv.conf is created.

Details

Difficulty level
Normal (likely a few hours)
Version
1.2.0-rolling+201906290337
Why the issue appeared?
Will be filled on close

Event Timeline

mb300sd created this task.Jun 29 2019, 8:49 PM
c-po added a subscriber: c-po.Jun 30 2019, 9:42 AM

Can't reproduce, but I experience a different issue - Nameservers are not propagated into resolv.conf

vyos@vyos# show system name-server
 name-server 172.16.254.30
vyos@vyos:~$ cat /etc/resolv.conf

### Autogenerated by host_name.py ###
nameserver 172.16.254.30

domain foo.com
search foo.com
vyos@vyos:~$ show version
Version:          VyOS 1.2.0-rolling+201906240337
vyos@vyos# set system name-server 2001:db8::1
vyos@vyos# commit
vyos@vyos# show system name-server
 name-server 172.16.254.30
 name-server 2001:db8::1
vyos@vyos# cat /etc/resolv.conf

### Autogenerated by host_name.py ###
nameserver 172.16.254.30

domain foo.com
search foo.com
c-po renamed this task from resolv.conf broken to "set system name-server" generates invalid/incorrect resolv.conf.Jun 30 2019, 9:43 AM
c-po triaged this task as Unbreak Now! priority.
c-po edited projects, added VyOS 1.3 Equuleus; removed VyOS 1.2 Crux.
c-po changed Difficulty level from Unknown (require assessment) to Normal (likely a few hours).

The difference might be because my IPv6 server is first, but I'm also experiencing the non-update when I try to add 1.1.1.1 to see if having an IPv4 server first helps.

UnicronNL claimed this task.Jul 1 2019, 8:22 AM

@c-po @mb300sd found the issue 'Nameservers are not propagated into resolv.conf' (no script in node def) , also the issue with the split ipv6 does not seem to be in host_name.py, will look a bit further for that.

UnicronNL added a comment.EditedJul 1 2019, 1:34 PM

@mb300sd what is the dhcp server you are using?
Could you also please share the content of the files:
/etc/resolv.conf.dhclient-new-eth0 (or other interface if you use an other)
/etc/resolv.conf.dhclient-old-eth0 (or other interface if you use an other)

mb300sd added a comment.EditedJul 1 2019, 5:03 PM

It's at&t's dhcp server, I have no idea what they run.

cat /etc/resolv.conf.dhclient-new-eth0.0
nameserver 68.94.156.11
nameserver 68.94.157.11

old does not exist.

show interfaces ethernet eth0
 description WAN_Base
 duplex auto
 eapol /config/auth/eapol/wpa_supplicant.conf
 hw-id d0:17:c2:ae:00:0b
 mac xx:xx:xx:xx:ED:D1
 smp-affinity 1
 speed auto
 traffic-policy {
     out PRIO_OUT
 }
 vif 0 {
     address dhcp
     description WAN
 }

The eapol line is my addition ( https://phabricator.vyos.net/T1466 )

@mb300sd is the ipv6 address provided via dhcp?

Also could you try the rolling for tomorrow? 20190702

mb300sd added a comment.EditedJul 1 2019, 6:09 PM

IPv6 is all static - he.net tunnels. Will try the rolling when it's up.

Updated to latest rolling, 1.2.0-rolling+201907020337

Fresh reboot, disable-dhcp-nameservers is still not working. The resolv.conf generated is valid now.

vyos@vyos:~$ cat /etc/resolv.conf

### Autogenerated by host_name.py ###
nameserver 68.94.156.11
nameserver 68.94.157.11

vyos@vyos:~$ configure
[edit]
vyos@vyos# commit
No configuration changes to commit
[edit]
vyos@vyos# set system name-server 1.1.1.1
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# cat /etc/resolv.conf

### Autogenerated by host_name.py ###
nameserver 2001:470:20::2
nameserver 74.82.42.42
nameserver 1.1.1.1

domain xxxx.xxxx.net
search xxxx.xxxx.net
[edit]
vyos@vyos# show system disable-dhcp-nameservers
Configuration under specified path is empty
[edit]
vyos@vyos# set system disable-dhcp-nameservers

  Configuration path: [system disable-dhcp-nameservers] already exists

[edit]
vyos@vyos#
pasik added a subscriber: pasik.Jul 2 2019, 3:26 PM
UnicronNL added a comment.EditedJul 2 2019, 4:08 PM

@mb300sd do you mean after a fresh boot you get:

vyos@vyos:~$ cat /etc/resolv.conf

### Autogenerated by host_name.py ###
nameserver 68.94.156.11
nameserver 68.94.157.11

and after you do

set system name-server 1.1.1.1

you get

### Autogenerated by host_name.py ###
nameserver 2001:470:20::2
nameserver 74.82.42.42
nameserver 1.1.1.1

domain xxxx.xxxx.net
search xxxx.xxxx.net

is that corect?

after adding the 1.1.1.1 i see disable-dhcp-nameservers working as

nameserver 68.94.156.11
nameserver 68.94.157.11

are gone.

but this does not happen on boot?

@mb300sd can you share your config maybe?

@mb300sd

I was able to reproduce your first issue...

I'll try to fix that first.

vyos@vyos:~$ cat /etc/resolv.conf

### Autogenerated by host_name.py ###
nameserver '
nameserver 8
nameserver .
nameserver 8
nameserver .
nameserver 8
nameserver .
nameserver 8
nameserver '
nameserver  
nameserver '
nameserver 8
nameserver .
nameserver 8
nameserver .
nameserver 4
nameserver .
nameserver 4
nameserver '


vyos@vyos:~$ echo " " | sudo tee  /etc/resolv.conf
 
vyos@vyos:~$ cat /etc/resolv.conf
 
vyos@vyos:~$ sudo /usr/libexec/vyos/conf_mode/host_name.py --dhclient
vyos@vyos:~$ cat /etc/resolv.conf

### Autogenerated by host_name.py ###
nameserver '
nameserver 8
nameserver .
nameserver 8
nameserver .
nameserver 8
nameserver .
nameserver 8
nameserver '
nameserver  
nameserver '
nameserver 8
nameserver .
nameserver 8
nameserver .
nameserver 4
nameserver .
nameserver 4
nameserver '


vyos@vyos:~$ conf
[edit]
vyos@vyos# sudo /usr/libexec/vyos/conf_mode/host_name.py
[edit]
vyos@vyos# exit
exit
vyos@vyos:~$ cat /etc/resolv.conf

### Autogenerated by host_name.py ###
nameserver 8.8.8.8
nameserver 8.8.4.4

vyos@vyos:~$ sudo /usr/libexec/vyos/conf_mode/host_name.py --dhclient
vyos@vyos:~$ cat /etc/resolv.conf

### Autogenerated by host_name.py ###
nameserver '
nameserver 8
nameserver .
nameserver 8
nameserver .
nameserver 8
nameserver .
nameserver 8
nameserver '
nameserver  
nameserver '
nameserver 8
nameserver .
nameserver 8
nameserver .
nameserver 4
nameserver .
nameserver 4
nameserver '

@UnicronNL yes. On boot it creates the resolv.conf with DHCP nameservers and missing the domain/search options. If I commit, it generates one with my configured servers and the domain/search options.

Config is massive, but this should be the relevant parts. It occurs on both of my routers that have DHCP addresses.

show interfaces ethernet eth0
 description WAN_Base
 duplex auto
 eapol /config/auth/eapol/wpa_supplicant.conf
 hw-id 00:25:90:e8:48:72
 mac xx:xx:xx:xx:2c:81
 smp-affinity auto
 speed auto
 traffic-policy {
     out PRIO_OUT
 }
 vif 0 {
     address dhcp
     description WAN
 }
show system
 config-management {
     commit-revisions 20
 }
 console {
     device ttyS0 {
         speed 9600
     }
 }
 disable-dhcp-nameservers
 domain-name xxxx.net
 host-name VyOS-xxxxx
 login {
     user vyos {
         authentication {
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
         }
         level admin
     }
 }
 name-server 2001:470:20::2
 name-server 74.82.42.42
 ntp {
     server 10.1.1.5 {
     }
 }
 syslog {
     global {
         facility all {
             level notice
         }
         facility protocols {
             level debug
         }
     }
 }

Not sure when the messed up one with all the lines happens, it wasn't right after commit, seemed to be after sitting for a few hours, but it was broken again when I tried to add system image just now.

Still using the dhcp servers on 1.2.0-rolling+201907022116. Will post back in a few hours if the one with a bunch of lines happens again.

vyos@vyos:~$ cat /etc/resolv.c
resolv.conf                      resolv.conf.dhclient-new-eth0.0
vyos@vyos:~$ cat /etc/resolv.conf

### Autogenerated by host_name.py ###
nameserver 68.94.156.11
nameserver 68.94.157.11
vyos@vyos:~$ config
[edit]
vyos@vyos# set system name-server 10.1.1.5
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# cat /etc/resolv.conf

### Autogenerated by host_name.py ###
nameserver 2001:470:20::2
nameserver 74.82.42.42
nameserver 10.1.1.5

domain xxxx.xxxx.net
search xxxx.xxxx.net
[edit]
vyos@vyos#
UnicronNL added a comment.EditedJul 2 2019, 9:02 PM

@mb300sd i just created this one https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201907022116-amd64.iso did you already test with it?

also do you wait for you config to be completely loaded before you check?

Yeah, that's the one I just installed.

Config should be completely loaded, it was about 5 minutes after the login prompt appeared. Will reboot again and leave it for a while to see if anything changes.

UnicronNL added a comment.EditedJul 3 2019, 9:08 AM

@mb300sd do you know how long it takes for the config to load for you? because the /etc/resolv.conf file is persistent. but on loading the config it should do the 'set system nameserver 2001:470:20::2' and overwrite the resolv.conf file.

can it be that in the console you have a message that config failed?
or can you wait for the whole config to load and after then check the resolv.conf?

if it does not hit your 'set system nameserver' part then there is maybe something wrong in the config.

please use what i wrote here with this image: https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201907031336-amd64.iso

UnicronNL reassigned this task from UnicronNL to zsdc.Jul 3 2019, 5:51 PM
UnicronNL claimed this task.
UnicronNL added a subscriber: zsdc.
UnicronNL added a subscriber: UnicronNL.

Had a long 4th of July weekend, but the issue appears to be resolved in 1.2.0-rolling+201907080337.

Noticed this today. Possibly another related bug, seems to have appeared the same time the previous ones were fixed. Hostname in bgp is showing up as 'debian', the hostname command, /etc/hostname, /etc/resolv.conf show the correct hostname.

Remote peer is running 1.2.0-rolling+201907020337, local is 1.2.0-rolling+201907080337

show ip bgp neighbors
BGP neighbor is ::10.255.2.0, remote AS 65001, local AS 65002, external link
Hostname: VyOS-xxxxx.xxxx.net
  BGP version 4, remote router ID 10.255.255.1, local router ID 10.255.255.2
  BGP state = Established, up for 11:32:54
  Last read 00:00:00, Last write 00:00:00
  Hold time is 4, keepalive interval is 1 seconds
  Configured hold time is 4, keepalive interval is 1 seconds
  Neighbor capabilities:
    4 Byte AS: advertised and received
    AddPath:
      IPv4 Unicast: RX advertised IPv4 Unicast and received
      IPv6 Unicast: RX advertised IPv6 Unicast and received
    Route refresh: advertised and received(old & new)
    Address Family IPv4 Unicast: advertised and received
    Address Family IPv6 Unicast: advertised and received
    Hostname Capability: advertised (name: debian,domain name: n/a) received (name: VyOS-xxxxx.xxxx.net,domain name: n/a)
zsdc closed this task as Resolved.Jul 18 2019, 3:37 PM

The problem, which leads to the malformed hostname in Hostname Capability was fixed in T1531. I am marking this as "Resolved", because the problem with DNS servers was resolved also, according to feedback.

@zsdc Hostname is still showing as 'debian' in 1.2.0-rolling+201907191807

Hostname Capability: advertised (name: debian,domain name: n/a) received (name: VyOS-xxxxx.xxxx.net,domain name: n/a)

I wonder if the bgp daemon is being started before the hostname is changed by the config script. Seems possible since we added a lock so it executes later.

zsdc added a comment.Aug 1 2019, 1:43 PM

@mb300sd. create please a new one task with detailed description for BGP, if there are still some problems with it.

c-po moved this task from Need Triage to Finished on the VyOS 1.3 Equuleus board.Aug 5 2019, 12:22 PM