net/renderer/sysconfig: also use dns information from interface config

[ani-sinha]

sysconfig renderer currently only uses global dns and search domain
configuration in order to populate /etc/resolv.conf. This means it ignores
interface specific dns configuration completely. This means, when global dns
information is absent and only interface specific dns configuration is present,
/etc/resolv.conf will not have complete dns information. Fix this so that
per interface dns information is also taken into account along with global dns
configuration in order to populate /etc/resolv.conf.

Fixes: GH-5400

tox results looks good

  py3: OK (76.88=setup[0.03]+cmd[76.85] seconds)
  black: OK (0.51=setup[0.00]+cmd[0.51] seconds)
  ruff: OK (0.03=setup[0.00]+cmd[0.02] seconds)
  isort: OK (0.79=setup[0.00]+cmd[0.79] seconds)
  mypy: OK (9.27=setup[0.00]+cmd[9.27] seconds)
  pylint: OK (14.00=setup[0.01]+cmd[13.99] seconds)
  congratulations :) (101.54 seconds)

[catmsred]

Thanks for finding and quickly fixing this issue! I'm wondering if we should check the other renderers to see if this problem persists across them. Is it worth adding a unit test to capture this edge case?

[ani-sinha]

Thanks for finding and quickly fixing this issue! I'm wondering if we should check the other renderers to see if this problem persists across them. Is it worth adding a unit test to capture this edge case?

yes I got lazy and did not add the unit test changes. I did now. It should check most combinations if not all.
As for other renderers, I do not know much about them. Red Hat only cares about sysconfig and network manager.

[TheRealFalcon]

Thanks for addressing this!

Network ifcfg files support DNS and search, correct? For DNS defined at the interface level, shouldn't we store DNS there instead?

E.g., if I use network v2:

network:
  version: 2
  ethernets:
    eth0:
      nameservers:
        search: [lab, home]
        addresses: [8.8.8.8, FEDC::1]
      addresses:
        - 192.168.1.20/16
        - 2001:bc8:1210:232:dc00:ff:fe20:185/64

I get a config file like:

# Created by cloud-init automatically, do not edit.
#
BOOTPROTO=none
DEVICE=eth0
DNS1=8.8.8.8
DNS2=FEDC::1
DOMAIN="lab home"
IPADDR=192.168.1.20
IPV6ADDR=2001:bc8:1210:232:dc00:ff:fe20:185/64
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6_FORCE_ACCEPT_RA=no
NETMASK=255.255.0.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

and nothing in resolv.conf.

The code to do it is here, though it looks like it's only limited static addresses. If that restriction was removed, I believe it should also work for v1.

Also, do you know how much usage the sysconfig renderer gets these days? I was under the assumption that the network-manager renderer is used on RHEL and RHEL-derived systems these days and that the sysconfig renderer is more-or-less legacy. Is that not true?

[ani-sinha]

Thanks for addressing this!

Network ifcfg files support DNS and search, correct? For DNS defined at the interface level, shouldn't we store DNS there instead?

Yes we are doing that already.

E.g., if I use network v2:

network:
  version: 2
  ethernets:
    eth0:
      nameservers:
        search: [lab, home]
        addresses: [8.8.8.8, FEDC::1]
      addresses:
        - 192.168.1.20/16
        - 2001:bc8:1210:232:dc00:ff:fe20:185/64

I get a config file like:

# Created by cloud-init automatically, do not edit.
#
BOOTPROTO=none
DEVICE=eth0
DNS1=8.8.8.8
DNS2=FEDC::1
DOMAIN="lab home"

Yes so here the search domain is added.

IPADDR=192.168.1.20
IPV6ADDR=2001:bc8:1210:232:dc00:ff:fe20:185/64
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6_FORCE_ACCEPT_RA=no
NETMASK=255.255.0.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

and nothing in resolv.conf.

Indeed and this is where the problem lies. It should be added to resolv.conf as well. At least that is what the spec also says. See my description in #5400 .

The code to do it is here, though it looks like it's only limited static addresses. If that restriction was removed, I believe it should also work for v1.

Also, do you know how much usage the sysconfig renderer gets these days?

sysconfig renderer in RHEL9 is the default and is widely used. network manager renderer in RHEL 9 is "opt in".

I was under the assumption that the network-manager renderer is used on RHEL and RHEL-derived systems these days and that the sysconfig renderer is more-or-less legacy. Is that not true?

No. For RHEL9, sysconfig is default and network manager is opt in. For RHEL10, we plan to make network manager the default. sysconfig renderer probably won't work since support for ifcfg files with use of network manager will be dropped.
So for widely used RHEL9 releases, we do need to support sysconfig for the forseeable future.

[TheRealFalcon]

At least that is what the spec also says.

Just to be clear, this is documentation and not a spec. In this case, the documentation is incorrect because sysconfig is the only renderer that modifies resolv.conf at all, and so it really isn't valid for any other renderers.

While I still think using interface-specific ifcfg options is preferable, this does solve the problem and will improve things when using sysconfig, so +1 from me.