View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0016948CentOS-8Cloud-Imagespublic2020-01-17 16:552021-11-07 19:23
Reporteruwktower Assigned To 
PrioritynormalSeverityminorReproducibilitysometimes
Status newResolutionopen 
Summary0016948: CentOS 8 cloud images have static 192.168.122.1 nameserver in /etc/resolv.conf
DescriptionThe CentOS 8 cloud images have the line "nameserver 192.168.122.1" statically defined in /etc/resolv.conf:

$ sudo losetup -f -P CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.raw /mnt/test
$ losetup -l | grep CentOS
/dev/loop4 0 0 0 0 /data/tmp/CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.raw 0 512
$ sudo mount -o ro /dev/loop4p1 /mnt/test
$ cat /mnt/test/etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.122.1

In certain environments, this line will stick around, even if it is invalid for the environment. This causes DNS lookup timeouts:

$ ssh centos@192.168.10.12
Warning: Permanently added '192.168.10.12' (ECDSA) to the list of known hosts.
Activate the web console with: systemctl enable --now cockpit.socket

[centos@c8test1 ~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc fq_codel state UP group default qlen 1000
    link/ether fa:16:3e:d4:12:12 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.12/24 brd 192.168.10.255 scope global dynamic noprefixroute eth0
       valid_lft 86384sec preferred_lft 86384sec
    inet6 fe80::f816:3eff:fed4:1212/64 scope link
       valid_lft forever preferred_lft forever
[centos@c8test1 ~]$ cat /etc/resolv.conf
; Created by cloud-init on instance boot automatically, do not edit.
;
# Generated by NetworkManager
nameserver 192.168.122.1
nameserver x.x.120.2 # valid
nameserver x.x.112.2 # valid

In at least one environment, however, the entry is scrubbed and looks correct:

$ ssh centos@10.155.176.31
Warning: Permanently added '10.155.176.31' (ECDSA) to the list of known hosts.
Activate the web console with: systemctl enable --now cockpit.socket

[centos@c8test2 ~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP group default qlen 1000
    link/ether fa:16:3e:5e:8d:65 brd ff:ff:ff:ff:ff:ff
    inet 10.155.176.31/23 brd 10.155.177.255 scope global dynamic noprefixroute eth0
       valid_lft 86300sec preferred_lft 86300sec
    inet6 fe80::f816:3eff:fe5e:8d65/64 scope link
       valid_lft forever preferred_lft forever
[centos@c8test2 ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
search openstacklocal novalocal
nameserver x.x.120.2 # valid
nameserver x.x.112.2 # valid

The only obvious difference I can find at the moment is that the problematic environment is in the same /16 (192.168.0.0/16) as the nameserver IP address that was left behind in the image, but I don't know if that is relevant or not.
Steps To ReproduceSee description.
TagsNo tags attached.

Activities

jguldmyr

jguldmyr

2020-02-13 07:22

reporter   ~0036281

I have never contributed to centos builds before but here's a PR, happy to test it further but I would need some guidance to figure out how to run the build locally with the tools that centos is using.

https://git.centos.org/centos/kickstarts/pull-request/12
giezi

giezi

2020-02-27 07:46

reporter   ~0036394

Hi there,

We've exactly the same issue with "CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2" and OpenStack.
A new machine has the following DNS entries:

[root@centos8 centos]# cat /etc/resolv.conf
; Created by cloud-init on instance boot automatically, do not edit.
;
# Generated by NetworkManager
nameserver 192.168.122.1
nameserver 8.8.8.8

Our network is 192.168.3.0/24 and we have just specified 8.8.8.8 during the deployment.
DNS lookups are now really slow.

Best regards
Reto
giezi

giezi

2020-02-27 07:51

reporter   ~0036395

The same behaviour in a non 192.168.x network:

[centos@juhu ~]$ cat /etc/resolv.conf
; Created by cloud-init on instance boot automatically, do not edit.
;
# Generated by NetworkManager
nameserver 192.168.122.1
nameserver 8.8.8.8
[centos@juhu ~]$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel state UP group default qlen 1000
    link/ether fa:16:3e:1b:c7:8d brd ff:ff:ff:ff:ff:ff
    inet 172.31.0.244/20 brd 172.31.15.255 scope global dynamic noprefixroute eth0
       valid_lft 86353sec preferred_lft 86353sec
    inet6 fe80::f816:3eff:fe1b:c78d/64 scope link
       valid_lft forever preferred_lft forever
eugenevdm

eugenevdm

2021-09-17 06:56

reporter   ~0038628

I used Proxmox to deploy CentOS images to my clients. Any ideas how to fix this manually (in new to Cloud-Init)

So far in Proxmox Cloud-Init UI I added a space delimited list of preferred DNS servers:

1.1.1.1
8.8.4.4

Yet I get this on deployment:

```
$ cat /etc/resolv.conf
; Created by cloud-init on instance boot automatically, do not edit.
;
# Generated by NetworkManager
nameserver 192.168.122.1
nameserver 1.1.1.1
nameserver 8.8.4.4
...
```

My goal would be to update the CentOS cloud image and remove that line, but I don't know where to start!
rpardini

rpardini

2021-11-07 19:23

reporter   ~0038718

Hello, I opened https://git.centos.org/centos/kickstarts/pull-request/15 which is exactly like https://git.centos.org/centos/kickstarts/pull-request/12 but for CentOS 7 cloud-images.
I realize this is very, very late in the game for CentOS 7, but some folks are just now considering getting off 7 and into 8 Stream; moving infra first to cloud-images still running on CentOS 7 makes sense for a more streamlined migration experience.

Issue History

Date Modified Username Field Change
2020-01-17 16:55 uwktower New Issue
2020-02-13 07:22 jguldmyr Note Added: 0036281
2020-02-27 07:46 giezi Note Added: 0036394
2020-02-27 07:51 giezi Note Added: 0036395
2021-09-17 06:56 eugenevdm Note Added: 0038628
2021-11-07 19:23 rpardini Note Added: 0038718