Bug 2144521

Thanks for working on this.

I tried this quickly (NetworkManager-1.40.16-4.el8.x86_64.rpm) in a dnsmasq based DNS caching setup on an IPv4-only host with dns=dnsmasq. The no-aaaa option was accepted in the NIC nmconnection ini file (no warnings or errors) but it did not appear in /etc/resolv.conf. Perhaps this is a scenario which has not been considered so far and is now more relevant?

Thanks.

> The no-aaaa option was accepted in the NIC nmconnection ini file (no warnings or errors) but it did not appear in /etc/resolv.conf

The scenario you describe works fine in my test setup.

Please ensure that:

 - you have restarted the service after the package upgrade
 - if you modified the nmconnection file directly, you need to either call "nmcli connection reload" (preferred) or restart the service
 - in any case, you need to reactivate the profile with "nmcli connection up $name" to have the new setting take effect.

If it still doesn't work, please show the output of:

  cat /etc/resolv.conf
  NetworkManager --print-config

and possibly attach a log at trace level.

I even rebooted the system earlier to no avail, here's what I see now after booting up the test VM:

root@rhel-8-server:~# rpm -qa | grep NetworkManager | sort
NetworkManager-1.40.16-4.el8.x86_64
NetworkManager-libnm-1.40.16-4.el8.x86_64
root@rhel-8-server:~# cat /etc/NetworkManager/conf.d/*
[main]
dns=dnsmasq
root@rhel-8-server:~# cat /etc/NetworkManager/dnsmasq.d/*
addn-hosts=/etc/hosts
domain-needed
bogus-priv
local=/example.com/
local-ttl=10
min-cache-ttl=10
neg-ttl=10
root@rhel-8-server:~# cat /etc/resolv.conf 
# Generated by NetworkManager
search example.com
nameserver 127.0.0.1
options edns0 trust-ad
root@rhel-8-server:~# cat /etc/NetworkManager/system-connections/net0.nmconnection 
[connection]
id=net0
uuid=33e2dfe5-649b-21d9-4fc5-2feaad011ccc
type=ethernet
interface-name=net0

[ethernet]

[ipv4]
dns-options=no-aaaa;edns0;trust-ad
method=auto

[ipv6]
addr-gen-mode=eui64
method=disabled

[proxy]
root@rhel-8-server:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: net0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:e7:11:6f brd ff:ff:ff:ff:ff:ff
root@rhel-8-server:~# 

I'll also attach the requested travel level log. Thanks.

Created attachment 1960127 [details]
nm-log-trace.txt

Hi, the problem is:

  <warn>  [1682514298.2879] keyfile: load: "/etc/NetworkManager/system-connections/net0.nmconnection": failed to load connection: File permissions (100644) are insecure

The connection file must only be accessible by root because it can contain secrets. In general the best way to add or modify connections is via nmcli because it takes care of everything. If you create files manually, you need to set the correct permissions or umask. See also:

https://access.redhat.com/documentation/it-it/red_hat_enterprise_linux/8/html-single/configuring_and_managing_networking/index#assembly_manually-creating-networkmanager-profiles-in-keyfile-format_configuring-and-managing-networking

Good catch, thanks for pointing it out, now it works! Earlier on this VM I did manually a one-time migration from RHEL 8 default ifcfg files to connection files and that caused this hiccup.

Wrt the link, with connection files it looks like from RHEL 9 onwards using the network system role is a good choice when doing configurations with Ansible in scale.

Thanks.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (NetworkManager bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:7118