systemd-resolved cannot be fully disabled because /etc/resolv.conf is managed

[jcbollinger]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: all
• Ruby: all
• Distribution: Ubuntu 20.04 (client)
• Module version: 3.0.0, 3.1.0

How to reproduce (e.g Puppet code you use)

class demo {
  class { 'systemd':
    manage_resolved => true,
    resolved_ensure => 'stopped',
  }

  file { '/etc/resolv.conf':
    ensure => 'file',
  }
}

What are you seeing

Catalog compilation fails with with a duplicate resource declaration error.

What behaviour did you expect instead

File[/etc/resolv.conf] should not be managed when systemd-resolved is managed to the stopped state.

Output log

Duplicate declaration: File[/etc/resolv.conf] is already declared at (.../modules/systemd/manifests/resolved.pp, line: 77); cannot redeclare (.../modules/demo/manifests/init.pp, line: 7) (file: .../modules/demo/spec/fixtures/modules/demo/manifests/init.pp, line: 7, column: 3) on node ...

Any additional information you'd like to impart

Just stopping systemd-resolved on a system that has had it configured completely breaks name resolution. Something else needs to manage /etc/resolv.conf afterward, or at least to update it once, but the module interferes with that.

For context, on domain-joined Ubuntu 20.04, systemd-resolved needs to be disabled in order for sssd to authenticate users against Active Directory.

Here is the RSpec test used to demonstrate the issue:

# frozen_string_literal: true

require 'spec_helper'

describe 'demo' do
  on_supported_os.each do |os, os_facts|
    context "on #{os}" do
      let(:facts) { os_facts.merge(systemd_internal_services: { 'systemd-resolved.service' => 'enabled' }) }

      it { is_expected.to compile }
    end
  end
end

[traylenator]

Agree it would be nice to get this or someway of safely exiting systemd-resolved once it is deployed

Background is that if you stop

systemd  stop systemd-resolved

Then both of the possible targets of /etc/resolv.conf are left behind i.e

• /run/systemd/resolve/stub-resolv.conf
• /run/systemd/resolve/resolv.conf

so setting use_stuf_file => false at the same time to restore symlink to /run/systemd/resolve/resolv.conf
may seem like a good idea until you reboot and /run/systemd/resolve is not there.

In a non puppet world it would be

rm -f /etc/resolv.conf
systemctl restart NetworkManager

but that is very OS dependent of course.

How about something like

exec{'install_working_resolve_conf':
     command  => `cp /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf`
     onlyif         => `resolv.conf  is a symlink one of  /run/systemd/resolve/stub-resolv.conf or  /run/systemd/resolve/resolv.conf`
}

all a bit fiddly.

[traylenator]

On the very fine point I agree when the service is stopped /etc/resolv.conf should not be managed as that is only going to end badly.

[ekohl]

It feels to me like we should document that resolv.conf gets left behind and it's up to the user of this module to find some other content. As @traylenator correctly states: the replacement is not always the same. Some may end up with a static resolv.conf file, others may use NetworkManagers and there are probably a few more options out there. Trying to solve it here will just end poorly.