#7900 dns and search not fixed for dns enabled deployments
Closed: fixed by cheimes. Opened by twoerner.

Request for enhancement

Deploying a primary or replica with dns support results in changes to resolv.conf. But these changes might get reverted by NetworkManager , the network service. This especially happens if the network is configured using dhcp.

Issue

[description of the issue]

Steps to Reproduce

  1. Use NetworkManger with dhcp connection
  2. Deploy ipaserver with dns enabled
  3. Reboot machine or wait for dhcp timeout
  4. resolv.conf is modified by NetworkManager and the dns server setting is reverted, maybe also search - depending on network configuration

Actual behavior

dns and search reverted in resolv.conf

Expected behavior

dns and search not reverted in resolv.conf

Version/Release/Distribution

$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server
freeipa-server-4.7.2-1.1.fc29.x86_64
freeipa-client-4.7.2-1.1.fc29.x86_64
389-ds-base-1.4.0.21-1.fc29.x86_64
pki-ca-10.6.9-1.fc29.noarch
krb5-server-1.16.1-25.fc29.x86_64


I propose to add two methods to the ipaplatform tasks: configure_dns(dns_servers: list, search_domains: list) -> None and unconfigure_dns() -> None.

For Network Manager enabled systems, we can use a drop in file and then reload Network Manager service. Network Manager will then create a /etc/resolv.conf with our settings. The `zzz prefix ensures that we are the last file. The last file in the conf.d directory wins and overrides all previous settings.

# cat /etc/NetworkManager/conf.d/zzz-ipa.conf 
[main]
dns=default
[global-dns]
searches=$DOMAIN
[global-dns-domain-*]
servers=127.0.0.1

I verified that systemctl --system reload NetworkManager.service is sufficient to pick up creation and removal of zzz-ipa.conf.

Metadata Update from @cheimes:
- Custom field on_review adjusted to https://github.com/freeipa/freeipa/pull/2996
- Issue assigned to cheimes
- Issue priority set to: normal
- Issue set to the milestone: FreeIPA 4.7.3

The proposed NM solution failed in containers because the TravisCI container doesn't use NM. I implemented a fallback to /etc/resolv.conf when NM is not enabled.

master:

  • 80928ba6f5872aab47a3dd5eb361336568dfcc60 Use Network Manager to configure resolv.conf

ipa-4-7:

  • adc79cebae15fb6c7652572dd1bf854fa807752d Use Network Manager to configure resolv.conf

Metadata Update from @cheimes:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

Metadata