unbound_version not set on first run causing unexpected config file setting

[mergwyn]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.25.0
• Ruby: 2.5.9
• Distribution: Ubuntu 20.04
• Module version: 4.0.1

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

class { 'unbound':
  interface              => $interface_list,
  interface_automatic    => false,
  access                 => [ "${lookup('defaults::cidr')}", '127.0.0.0/8' ],
  do_not_query_localhost => false,
  val_permissive_mode    => true,
  ip_transparent         => true,
}

What are you seeing

The initial run of the puppet agent fails to start unbound as the ip-transparent setting is not applied to the configuration file. As I am trying to bind to a failover IP address which may not exist at the time unbound is started unbound fails. The second run of puppet does add the setting and unbound starts correctly.

What behaviour did you expect instead

The configuration file for unbound should contain all of the parameters specified such that unbound starts on the first run.

Output log

Can be provided if required.

Any additional information you'd like to impart

The unbound.conf.erb template contains code to make parameters in the configuration specific to the version of unbound installed based on the fact unbound_version. This is not set on the first run of unbound as the package is not yet installed. All of the version dependent settings eg

    <%= print_config('so-reuseport', @so_reuseport, '1.4.22') -%>
    <%= print_config('ip-transparent', @ip_transparent, '1.5.4') -%>
    <%= print_config('ip-freebind', @ip_freebind, '1.5.9') -%>

Do not get applied as the versioncmp at the top of the template defaults to 0.a and decides the version of unbound is lower than the minimum requirement for that setting.

A potential fix could be to use a different variable in the template which is set after the package has been installed by running unbound -V at that point. I'd be happy to have a go at creating a PR for this or an alternative solution.

[b4ldr]

A potential fix could be to use a different variable in the template which is set after the package has been installed by running unbound -V at that point

We can not do this due to the way puppet works*. Facts are calculated before any of the puppet catalog is applied as such we have the the following flow

• facts collected (unbound not installed so no way to get version)
• first puppet run and we install unbound
• next puppet run unbound_version is available
  This unfortunately is a known issue. either we install all config items and break unbound for anyone not running the most recent version of ubound we support. or we configure things like this and we need to puppet runs to get a correct unbound.conf file.

Definitely open to suggestion to improve this as its a common pattern

for this specific config we can probably write it always. ill have a check of metadata.json and update the minimum version of unbound we support

*we could possibly used some type of deferred function but im only on puppet 5 so havn't had a chance to play with them