CentOS 7 Support

[MattMencel]

Opening this for discussion as I'm not sure what needs to be done yet. This is only related to the pdns-recursor.

Install

I think the deployment model for this cookbook currently conflicts with how CentOS 7 installs and configures pdns-recursor.

I used only the install LWRP:

pdns_recursor_install 'pdns-recursor' do
  action :install
end

It successfully sets up the repo and installs the latest version:

  * pdns_recursor_install_rhel[pdns-recursor] action install
    * yum_package[epel-release] action install (skipped due to only_if)
    * yum_repository[powerdns-rec-40] action create
      * template[/etc/yum.repos.d/powerdns-rec-40.repo] action create (up to date)
      * execute[yum clean metadata powerdns-rec-40] action nothing (skipped due to action :nothing)
      * execute[yum-makecache-powerdns-rec-40] action nothing (skipped due to action :nothing)
      * ruby_block[yum-cache-reload-powerdns-rec-40] action nothing (skipped due to action :nothing)
       (up to date)
    * yum_repository[powerdns-rec-40-debuginfo] action create
      * template[/etc/yum.repos.d/powerdns-rec-40-debuginfo.repo] action create (up to date)
      * execute[yum clean metadata powerdns-rec-40-debuginfo] action nothing (skipped due to action :nothing)
      * execute[yum-makecache-powerdns-rec-40-debuginfo] action nothing (skipped due to action :nothing)
      * ruby_block[yum-cache-reload-powerdns-rec-40-debuginfo] action nothing (skipped due to action :nothing)
       (up to date)
    * yum_package[pdns-recursor] action install
      - install version 4.0.4-1pdns.el7 of package pdns-recursor

By default the installer puts the config in /etc/pdns-recursor:

# ls -l /etc/pdns-recursor/
total 12
-rw-r--r-- 1 root root 12089 Jan 13 03:41 recursor.conf

By default the installer sets up a systemd service that expects to find the config in the default location:

# systemctl cat pdns-recursor.service
# /usr/lib/systemd/system/pdns-recursor.service
[Unit]
Description=PowerDNS Recursor
Documentation=man:pdns_recursor(1) man:rec_control(1)
Documentation=https://doc.powerdns.com
Wants=network-online.target nss-lookup.target
Before=nss-lookup.target
After=network-online.target

[Service]
Type=notify
ExecStart=/usr/sbin/pdns_recursor --daemon=no --write-pid=no --disable-syslog
Restart=on-failure
StartLimitInterval=0
PrivateTmp=true
PrivateDevices=true
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID CAP_CHOWN CAP_SYS_CHROOT
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
LimitNOFILE=4200

[Install]
WantedBy=multi-user.target

By default, when the service runs it creates this default socket file:

# ls -l /var/run/p*
srwxr-xr-x 1 root pdns-recursor  0 May 30 10:09 /var/run/pdns_recursor.controlsocket

The pdns_recursor_config LWRP creates a different default config location, adding an instance_dir and instance_name to the path.

In order to support CentOS 7 I think the default systemd service that is setup during the install above needs to be edited to point to the correct path that is created in the config LWRP? Rather than attempting to create a separate SysVInit service which conflicts with the default systemd service that gets created.

Maybe with this resource? https://docs.chef.io/resource_systemd_unit.html

Again....I can possibly help with a PR, but just not sure which direction the developers here want to go.

Current Workaround

Install: I use the pdns-recursor-install LWRP from this cookbook.

Config: I'm currently using a template in my wrapper cookbook to update the default config at /etc/pdns-recursor/recursor.conf.

template '/etc/pdns-recursor/recursor.conf' do
  source 'recursor.conf.erb'
  owner 'root'
  group 'root'
  mode 00644
end

Service: Just using the default systemd service created by the installer.

[therobot]

Hello @MattMencel,

The 3.0.0 release was not really focused on providing proper support systemd for pdns either for the recursor or the authoritative. I even dropped systemd support for this release at some point. But later on I decided to leave it broken and promise to fix it soon.

Work it's already been done in #61 to provide proper systemd/centos 7 support. I'm looking forward to merge & release a new 3.1.0 version of this cookbook with that PR, but we still have to address a few problems there.

[MattMencel]

Ok sounds good. I also noticed that if I had the default pdns-recursor already installed from the main centos repos (version 3.7.4 currently)... the install LWRP here doesn't upgrade to the 4.X version by default.

[therobot]

@MattMencel can you set a separate issue for that?

Thanks.

[martinisoft]

Hi @MattMencel can you re-test your changes against CentOS 7? I may be able to add it to the suite in a future release.

[MattMencel]

Hi @martinisoft,

I tested against the 4.0 version of this cookbook first, without the changes I currently have to do in my wrapper.

The pdns_recursor_install and pdns_recursor_config resources work. The pdns_recursor_service resource is not catching that it should use systemd and it runs the _sysvinit version of the resource instead.

So I reverted back to just using the pdns_recursor_install resource and then overwriting the default /etc/pdns-recursor/recursor.conf with my template and using the default systemd service that the installer package creates.

[martinisoft]

The pdns_recursor_install and pdns_recursor_config resources work. The pdns_recursor_service resource is not catching that it should use systemd and it runs the _sysvinit version of the resource instead.

That is really strange since we defer to Chef's built-in detection method for systemd. Which Chef Client version are you running?

[MattMencel]

So... systemd doesn't detect correctly on kitchen-docker maybe.... My first tests I was using the docker driver and that's where I saw it pick up _sysvinit.

Running it with chef-client 13.2.20 with the test-kitchen vagrant driver detects the _systemd resource just fine.

So with vagrant and a CentOS 7.3 box, it installs the package and deploys a new config for my_recursor to /etc/pdns-recursor.

$ ls -l /etc/pdns-recursor/
total 20
-rw-r--r--. 1 root root 12513 Jul  4 15:58 recursor.conf
-rw-r-----. 1 root root   540 Aug  7 19:28 recursor-my_recursor.conf

By default, the service created by the installer is going to look at that original recursor.conf file. So I use the systemd_service_drop_in resource from the systemd cookbook to add an override.

systemd_service_drop_in 'my_recursor' do
  override 'pdns-recursor.service'
  precursor 'Service' => {'ExecStart' => nil}
  service do
    exec_start '/usr/sbin/pdns_recursor --daemon=no --write-pid=no --disable-syslog --config-name=my_recursor'
  end
end

[vagrant@default-centos-73 ~]$ sudo systemctl start pdns-recursor
[vagrant@default-centos-73 ~]$ systemctl status pdns-recursor
● pdns-recursor.service - PowerDNS Recursor
Loaded: loaded (/usr/lib/systemd/system/pdns-recursor.service; disabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/pdns-recursor.service.d
└─my_recursor.conf
Active: active (running) since Mon 2017-08-07 20:17:36 UTC; 2s ago
Docs: man:pdns_recursor(1)
man:rec_control(1)
https://doc.powerdns.com
Main PID: 19939 (pdns_recursor)
CGroup: /system.slice/pdns-recursor.service
└─19939 /usr/sbin/pdns_recursor --daemon=no --write-pid=no --disable-syslog --config-name=my_recursor

So maybe that could be added to your _systemd resource?

Or you could deploy a completely separate instance of the pdns-recursor.service?

[jmauro]

Hello @MattMencel,

Have you setup docker to start systemd as init? Because that could explain this behaviour, on dokken you have to set something like that: https://github.com/dnsimple/chef-pdns/blob/master/.kitchen.dokken.yml#L47

The normal behaviour on CentOS 7, which supports systemd, all PowerDNS service (Authoritative and recursor) should use the instance feature available in the software package.

[MattMencel]

Set it up to use the dokken driver as @jmauro suggested and now test-kitchen with the dokken driver works great. Here's what I have in my working wrapper cookbook.

pdns_recursor_install 'my_recursor' do
  action :install
end

pdns_recursor_config 'my_recursor' do
  action :create
  variables(
    'allow_from' => ['127.0.0.0/8', '10.0.0.0/8'],
    'local_address' => ['127.0.0.1', node['ipaddress']],
    'forward_zones_recurse' => '.=10.50.3.111',
    'carbon-server' => '10.50.2.17',
    'logging-facility' => '0',
    'quiet' => 'no'
  )
end

systemd_service_drop_in 'my_recursor' do
  override 'pdns-recursor.service'
  precursor 'Service' => { 'ExecStart' => nil }
  service do
    exec_start '/usr/sbin/pdns_recursor --daemon=no --write-pid=no --disable-syslog --config-name=my_recursor'
  end
end

pdns_recursor_service '' do
  supports restart: true
  action [:enable, :start]
end

[jmauro]

Hello @MattMencel ,

I really don't understand why you should specify a systemd_service_drop_in resource the pdns resources should handle this for you.

Regards,
JM

[MattMencel]

Hi @jmauro ,

In the pdns_recursor_config resource, the helper creates a pdns-recursor.conf file if you don't specify one...or it creates one with the name given.

https://github.com/dnsimple/chef-pdns/blob/master/libraries/helpers.rb

def recursor_instance_config(name = '')
      if name.empty?
        'pdns-recursor.conf'
      else
        "recursor-#{name}.conf"
      end
    end

The default CentOS package creates /etc/pdns-recursor/recursor.conf and the default systemd service (/usr/lib/systemd/system/pdns-recursor.service) expects to use that config file.

That's why I think I need to do the override. I realized I don't necessarily need to use the systemd_service_drop_in ....and could just use the default Chef systemd resource.... but I'm pretty sure I still need to do the override.

May just need to update that helper to this?

def recursor_instance_config(name = '')
  case node['platform_family']
    when 'debian'
      if name.empty?
        'pdns-recursor.conf'
      else
        "recursor-#{name}.conf"
      end
    when 'rhel'
      if name.empty?
        'recursor.conf'
      else
        "recursor-#{name}.conf"
      end
    end
  end

But an override would still be needed if a custom name was used.

[jmauro]

Hello @MattMencel, this behaviors seems related to #86, doesn't it?

[martinisoft]

I've got a preposed resolution to this in #86 as it also affected us as well. Once @onlyhavecans can give it a look over it'll go out in the next minor release.

[martinisoft]

I've just released 4.3.0 which ships #86 so can you please re-check and let me know if this resolves your issue @MattMencel?

[martinisoft]

Hi again @MattMencel

Since we haven't heard from you we'll be closing this issue. If you have feedback for us please feel free to re-open the issue and update us.