Hi,
I'm running CentOS 7 on all my servers, in three different contexts :
1. simple local server 2. public facing server 3. router/gateway/firewall
I'm currently in the process of moving my KISS-style network-scripts-style configurations to something more orthodox based on NetworkManager.
Scenarios (1) and (2) caused no problems, but (3) is giving me some headache. Let me take an example.
The router in my office is a PC Engines routerboard running CentOS 7. It has three NICs, and I use two of these.
WAN-facing NIC :
# /etc/sysconfig/network-scripts/ifcfg-enp1s0 DEVICE=enp1s0 TYPE=Ethernet ONBOOT=yes BOOTPROTO=static IPADDR=192.168.1.1 NETMASK=255.255.255.0
LAN-facing NIC :
DEVICE=enp2s0 TYPE=Ethernet ONBOOT=yes BOOTPROTO=static IPADDR=192.168.2.1 NETMASK=255.255.255.0
Third NIC is disabled :
# /etc/sysconfig/network-scripts/ifcfg-enp3s0 DEVICE=enp3s0 TYPE=Ethernet ONBOOT=no
Gateway information :
# /etc/sysconfig/network GATEWAY=192.168.1.254
The router is running Dnsmasq :
# /etc/resolv.conf nameserver 127.0.0.1
Packet forwarding is enabled and handled through the firewall script. No need to go into the details for that.
This setup works perfectly as is. Now I'd like to move it to a NetworkManager-based configuration, and I have a couple questions about that.
I'm using NetworkManager TUI (nmtui) to configure my connections. I'm defining two profiles WAN (enp1s0) and LAN (enp2s0). With NetworkManager I have to configure gateway and DNS information on a per-interface basis.
1. Which interface should have the gateway information ?
2. In a similar manner, which interface should have the DNS server information ?
Cheers from the sunny South of France,
Niki
On 18/02/2020 12:00, Nicolas Kovacs wrote:
Hi Nicolas,
I'm using NetworkManager TUI (nmtui) to configure my connections. I'm defining two profiles WAN (enp1s0) and LAN (enp2s0). With NetworkManager I have to configure gateway and DNS information on a per-interface basis.
- Which interface should have the gateway information ?
The WAN interface.
- In a similar manner, which interface should have the DNS server
information ?
Neither. The DNS configuration should not normally be bound to a specific interface, so don't configure it with any interface. If you do, and that interface goes down, your DNS config also disappears.
Regards, Anand
Le 18/02/2020 à 12:28, Anand Buddhdev a écrit :
Neither. The DNS configuration should not normally be bound to a specific interface, so don't configure it with any interface. If you do, and that interface goes down, your DNS config also disappears.
I would like to do that very much, only NetworkManager makes you jump through burning loops to do so.
With network-scripts, it was just a matter of editing resolv.conf with nameserver and search domain directives.
I can't do that anymore, because /etc/resolv.conf gets squashed by NetworkManager. If I don't fill in DNS information for the interfaces, then all I get is an empty "#Generated by NetworkManager" line.
On the other hand, using nmtui, the only place where I can actually fill in DNS information is in the interface-specific dialogs.
After googling around for this problem, it looks like I'm not the only one scratching my head.
Any suggestions ?
Niki
On 18/02/2020 16:37, Nicolas Kovacs wrote:
I can't do that anymore, because /etc/resolv.conf gets squashed by NetworkManager. If I don't fill in DNS information for the interfaces, then all I get is an empty "#Generated by NetworkManager" line.
Oh yes. Are you still sure you want to use NetworkManager? It's a pain!
On the other hand, using nmtui, the only place where I can actually fill in DNS information is in the interface-specific dialogs.
After googling around for this problem, it looks like I'm not the only one scratching my head.
Any suggestions ?
Yes. Do this:
# cat >/etc/NetworkManager/conf.d/dns.conf <<EOF [main] rc-manager=unmanaged EOF
# systemctl reload NetworkManager
This tells NetworkManager to leave /etc/resolv.conf alone. Now you can put whatever you like in /etc/resolv.conf, and it will be left untouched.
Regards, Anand
Le 18/02/2020 à 16:51, Anand Buddhdev a écrit :
This tells NetworkManager to leave /etc/resolv.conf alone. Now you can put whatever you like in /etc/resolv.conf, and it will be left untouched.
I just found the answer after some more experimenting.
1. If you put some DNS information in any of your ifcfg-* interfaces, then NetworkManager will overwrite /etc/resolv.conf with whatever it find in there.
BUT...
2. If there is no DNS information in any of the ifcfg-* files, then NetworkManager will leave your manually edited /etc/resolv.conf configuration untouched. And this is the default behavior, no need to configure it specifically.
Problem solved. :o)
Thanks very much to everybody in this thread for your contribution.
Niki
Le 18/02/2020 à 16:51, Anand Buddhdev a écrit :
Oh yes. Are you still sure you want to use NetworkManager? It's a pain!
As much as I'm a firm believer in the KISS principle, I don't like to "swim against the current". As someone on this list said it earlier, Red Hat provides a certain set of tools meant to be used. And since the official guide "Considerations in adopting RHEL 8" explicitly states that network scripts are considered obsolete, I thought I'd do my best to wrap my head around this new way of doing things, like I did before with systemd.
Cheers,
Niki
On 2/18/20 9:37 AM, Nicolas Kovacs wrote:
Le 18/02/2020 à 12:28, Anand Buddhdev a écrit :
Neither. The DNS configuration should not normally be bound to a specific interface, so don't configure it with any interface. If you do, and that interface goes down, your DNS config also disappears.
I would like to do that very much, only NetworkManager makes you jump through burning loops to do so.
With network-scripts, it was just a matter of editing resolv.conf with nameserver and search domain directives.
I can't do that anymore, because /etc/resolv.conf gets squashed by NetworkManager. If I don't fill in DNS information for the interfaces, then all I get is an empty "#Generated by NetworkManager" line.
On the other hand, using nmtui, the only place where I can actually fill in DNS information is in the interface-specific dialogs.
Or use 'nmcli con mod <interface_name> ipv4.dns "8.8.8.8"'
or edit:
/etc/sysconfig/network-scripts/ifcfg-<interface-name>
After googling around for this problem, it looks like I'm not the only one scratching my head.
Any suggestions ?
Niki
On Tue, Feb 18, 2020 at 04:37:29PM +0100, Nicolas Kovacs wrote:
Le 18/02/2020 à 12:28, Anand Buddhdev a écrit :
Neither. The DNS configuration should not normally be bound to a specific interface, so don't configure it with any interface. If you do, and that interface goes down, your DNS config also disappears.
I would like to do that very much, only NetworkManager makes you jump through burning loops to do so.
With network-scripts, it was just a matter of editing resolv.conf with nameserver and search domain directives.
I can't do that anymore, because /etc/resolv.conf gets squashed by NetworkManager. If I don't fill in DNS information for the interfaces, then all I get is an empty "#Generated by NetworkManager" line.
On the other hand, using nmtui, the only place where I can actually fill in DNS information is in the interface-specific dialogs.
After googling around for this problem, it looks like I'm not the only one scratching my head.
According to 'man nm-settings-ifcfg-rh', PEERDNS=no is the old network-services services mechanism for not changing /etc/resolv.conf, while in NM it just means never add automatic nameservers to resolv.conf from DHCP, PPP, VPN, etc. Turning off all DNS updates means adding:
[main] dns=none
... to the NetworkManager.conf (or preferably in an /etc/NetworkManager/conf.d/ file) is probably going to be the most effective way. I've seen PEERDNS=no make NetworkManager not overwrite my resolv.conf but maybe I should be extra careful and drop in a config file that turns off all dns updating features of NetworkManager.
Le 18/02/2020 à 17:43, Jonathan Billings a écrit :
According to 'man nm-settings-ifcfg-rh', PEERDNS=no is the old network-services services mechanism for not changing /etc/resolv.conf, while in NM it just means never add automatic nameservers to resolv.conf from DHCP, PPP, VPN, etc. Turning off all DNS updates means adding:
[main] dns=none
... to the NetworkManager.conf (or preferably in an /etc/NetworkManager/conf.d/ file) is probably going to be the most effective way. I've seen PEERDNS=no make NetworkManager not overwrite my resolv.conf but maybe I should be extra careful and drop in a config file that turns off all dns updating features of NetworkManager.
See my previous mail on that subject.
tl;dr : as long as you don't provide any DNS information for any of the interfaces, /etc/resolv.conf does *not* get overwritten.
On 18/02/2020 16:56, Nicolas Kovacs wrote:
Le 18/02/2020 à 17:43, Jonathan Billings a écrit :
According to 'man nm-settings-ifcfg-rh', PEERDNS=no is the old network-services services mechanism for not changing /etc/resolv.conf, while in NM it just means never add automatic nameservers to resolv.conf from DHCP, PPP, VPN, etc. Turning off all DNS updates means adding:
[main] dns=none
... to the NetworkManager.conf (or preferably in an /etc/NetworkManager/conf.d/ file) is probably going to be the most effective way. I've seen PEERDNS=no make NetworkManager not overwrite my resolv.conf but maybe I should be extra careful and drop in a config file that turns off all dns updating features of NetworkManager.
See my previous mail on that subject.
tl;dr : as long as you don't provide any DNS information for any of the interfaces, /etc/resolv.conf does *not* get overwritten.
I had a fight with getting resolv.conf sorted out across several VMs. There are a few notes in the enclosed file.
On 18/02/2020 11:00, Nicolas Kovacs wrote:
Hi,
I'm running CentOS 7 on all my servers, in three different contexts :
1. simple local server 2. public facing server 3. router/gateway/firewall
I'm currently in the process of moving my KISS-style network-scripts-style configurations to something more orthodox based on NetworkManager.
Scenarios (1) and (2) caused no problems, but (3) is giving me some headache. Let me take an example.
The router in my office is a PC Engines routerboard running CentOS 7. It has three NICs, and I use two of these.
WAN-facing NIC :
# /etc/sysconfig/network-scripts/ifcfg-enp1s0 DEVICE=enp1s0 TYPE=Ethernet ONBOOT=yes BOOTPROTO=static IPADDR=192.168.1.1 NETMASK=255.255.255.0
LAN-facing NIC :
DEVICE=enp2s0 TYPE=Ethernet ONBOOT=yes BOOTPROTO=static IPADDR=192.168.2.1 NETMASK=255.255.255.0
Third NIC is disabled :
# /etc/sysconfig/network-scripts/ifcfg-enp3s0 DEVICE=enp3s0 TYPE=Ethernet ONBOOT=no
Gateway information :
# /etc/sysconfig/network GATEWAY=192.168.1.254
The router is running Dnsmasq :
# /etc/resolv.conf nameserver 127.0.0.1
Packet forwarding is enabled and handled through the firewall script. No need to go into the details for that.
This setup works perfectly as is. Now I'd like to move it to a NetworkManager-based configuration, and I have a couple questions about that.
I'm using NetworkManager TUI (nmtui) to configure my connections. I'm defining two profiles WAN (enp1s0) and LAN (enp2s0). With NetworkManager I have to configure gateway and DNS information on a per-interface basis.
Which interface should have the gateway information ?
In a similar manner, which interface should have the DNS server
information ?
Cheers from the sunny South of France,
Niki
NM is actually pretty cool, to me it made all the stuff much easier. NM also cover & takes care of source/policy based routing. Also, if you go back to devel guys they listen and are happy to enhance NM including some suggestions. Development of NM is well active & solid in my option and it'll keep getting better I believe.
With a system with many ifaces note NM has something called "priorities" with which you have controll over things like resolv.conf.
connection.autoconnect-priority; ipv4.dns-priority
Moving from what you had over to NM should be simple.
enp1s0 should have ipv4.gateway value enp2s0 should have it empty.
If you use firewalld then it also plays a role in linux router, with more complex setup you might need --direct but.. if you have been using it already with "network" then it will need no extra changes with NM. Kernel params also is good to have sussed out.
-
Anand Buddhdev -
J Martin Rushton -
Johnny Hughes -
Jonathan Billings -
lejeczek -
Nicolas Kovacs